RFC 9421

The document describes a mechanism for creating, encoding and verifying digital signatures or message authentication codes over components of an HTTP message. It is written for the case where the signer does not hold the whole message and where intermediaries may change it in transit, which is why the signature covers named components rather than raw bytes.

Two header fields carry it. Signature-Input names the covered components in order together with the signature's metadata, and Signature carries the signature itself; each is keyed by a label so one message can hold more than one. The components and their values are canonicalised into a signature base, and a receiver rebuilds that base from the message it actually got. Its status is Standards Track.

What a signature covers is therefore a decision the signer publishes, and it is the part that matters when a payment field is at stake. Cloudflare's pay per crawl requires its payment header to sit inside the components the request signature covers, so the price a crawler agrees to is signed rather than merely sent.

x402 carries the same standard as a named extension, which establishes the cryptographic identity of the paying agent and says how that identity is associated with a network for billing. Identity and payment are separate questions on this rail, and this is the seam between them.