HTTP Message Signatures Explained — RFC 9421 | Identity Expert

This video describes security mechanisms as defined in published standards. It is not a substitute for a professional security review of your own implementation.

TLS gives you a secure tunnel from client to server — but that tunnel terminates at your first load balancer, API gateway, or reverse proxy. Everything beyond that point is unprotected plaintext from TLS's perspective. A compromised proxy, a malicious CDN edge node, or a microservice mesh hop can add, remove, or modify HTTP headers and body without any cryptographic evidence. For financial APIs, government identity systems, and OAuth flows carrying sensitive grants, that's an unacceptable gap.

HTTP Message Signatures, defined in RFC 9421 (published February 2024), closes it. A signer selects the HTTP components they want to protect — method, path, headers, body digest, even specific query parameters — and creates a cryptographic signature over them. The signature and its input metadata travel in two new header fields: Signature-Input and Signature. Any downstream service with the signer's public key can independently verify that the covered components are exactly what the signer sent.

This video walks through why TLS alone isn't enough for high-assurance APIs, the component identifier system that lets you pick exactly what to sign, the Signature-Input header that encodes what's covered and which key/algorithm was used, the four-step signature base construction, and the threat classes RFC 9421 neutralises. It also covers where the spec stands today: GNAP (RFC 9635) uses it for client proof-of-possession, RFC 9530 (HTTP Digest Fields) provides the body-integrity companion, and financial API frameworks are actively adopting it.
Identity Expert is an independent educational channel. No vendor affiliation or sponsorship.

---

0:00 Introduction
0:24 Why TLS alone isn't enough
0:47 The analogy — notary stamp vs envelope seal
1:19 Component identifiers — what you can sign
1:54 On the wire — Signature-Input and Signature
2:57 Threat model — replay, stripping, body swap
3:32 GNAP, RFC 9530, and financial API adoption
4:22 Sources
---

Sources & References
• RFC 9421 — HTTP Message Signatures: https://datatracker.ietf.org/doc/html/rfc9421
• RFC 9530 — HTTP Digest Fields: https://datatracker.ietf.org/doc/html/rfc9530
• RFC 9635 — GNAP Core Protocol: https://datatracker.ietf.org/doc/html/rfc9635
• RFC 9449 — OAuth 2.0 Demonstrating Proof of Possession (DPoP): https://datatracker.ietf.org/doc/html/rfc9449

#httpsignatures #apisecurity #rfc9421 #identityexpert #webdev
---
Sources cited above are IETF RFCs — all freely reproducible for educational use.
For educational purposes only. Specs evolve — always check the latest version of the standard.

Видео HTTP Message Signatures Explained — RFC 9421 | Identity Expert канала Identity Expert