Glossary · Protocols and standards
HTTP Message Signatures (RFC 9421)
The IETF standard for signing selected parts of an HTTP request or response and carrying the result in Signature and Signature-Input headers.
HTTP Message Signatures is the IETF standard, RFC 9421 (February 2024), for creating and verifying digital signatures or MACs over selected components of an HTTP message, even when intermediaries change other parts of the message in transit.
How it works. The signer chooses covered components. These can be derived components such as @method, @authority, @path or @target-uri, header fields such as content-type, or a content-digest of the body. It then builds a signature base: one line per component, ending with the @signature-params line. The signature is computed over that base and sent in two headers:
Signature-Inputlists the covered components and the signature parameters:created,expires,nonce,alg,keyidandtag.Signatureholds the signature bytes.
Each signature has a label, such as sig1, so one message can carry several. The verifier rebuilds the base from the message it received and checks the signature with the key named by keyid. How the verifier finds that key is left to the application. A server can also ask for a signature with the Accept-Signature header. Algorithms come from an IANA registry that includes rsa-pss-sha512, ecdsa-p256-sha256, hmac-sha256 and ed25519.
Illustrative request headers:
Signature-Input: sig1=("@method" "@authority" "@path" "content-digest");created=1790445600;keyid="agent-key-1";alg="ed25519"
Signature: sig1=:dGhpcyBpcyBub3QgYSByZWFsIHNpZ25hdHVyZQ==:
What it protects. A signature covers only the listed components, and anything left out can change. Section 7.2.2 of the RFC warns that a captured signature can be replayed on a similar message. Covering enough of the message, adding a nonce, and setting created and expires limit that risk. Choosing those rules is the application’s job.
Uses in agent protocols. Web Bot Auth profiles RFC 9421 for bots and agents that visit websites, adding the Signature-Agent header and a JWKS key directory. The Universal Commerce Protocol lists RFC 9421 signatures among its authentication options, with verification keys published in each party’s UCP profile. A2A itself signs Agent Cards with JWS rather than signing HTTP messages.
Neighbouring terms. JWS signs a JSON payload, while HTTP Message Signatures sign parts of an HTTP exchange. A JWKS is a common way to publish the verification keys.