HTTP Message Signatures

HTTP Message Signatures, standardized as RFC 9421, defines a way to create, encode, and verify digital signatures over the individual components of an HTTP message — a chosen set of headers, the request target, the method, and optionally the body. Unlike transport-layer protection such as TLS, which secures the connection, message signatures travel with the request itself and survive proxies, gateways, and stored-and-forwarded messages, giving true end-to-end integrity and authenticity.

• Component-based signing - The signer explicitly lists which parts of the message are covered, so verifiers know exactly what was authenticated.
• Signature and Signature-Input headers - A structured-fields format carries the signature and the metadata needed to reconstruct and check it.
• Algorithm agility - The spec supports multiple signing algorithms rather than hard-coding one, so implementations can evolve their cryptography.
• End-to-end, not point-to-point - Signatures remain valid across intermediaries, unlike HTTP over TLS which only protects a single hop.

In real API operations, HTTP Message Signatures is the standard I point to when a provider needs to prove who made a request and that nothing was tampered with in transit, independent of the gateway in front of them. It is becoming especially relevant in the agentic turn, where autonomous clients need a verifiable, non-repudiable way to authenticate calls — a natural complement to identity systems and a stronger primitive than shared secrets alone. It pairs closely with IAM practices for machine-to-machine trust.