HTTP Signature

Definition

HTTP Message Signatures (or HTTP Signature) is an IETF standard finalized in RFC 9421 (February 2024) for signing HTTP requests and responses.

It adds application-level integrity and authenticity on top of TLS: even though TLS protects the transport, the signature proves that a specific HTTP message was indeed sent by an identified party, without modification. It is the reference standard in PSD2 RTS-SCA, where TPPs sign their API requests with a QSealC (eIDAS), as do the Berlin Group and STET.

Before RFC 9421, the industry used the older Cavage draft (draft-cavage-http-signatures), similar but non-final; RFC 9421 modernizes it (labels, structured fields, Content-Digest).

Why HTTP Signature

TLS protects between the two endpoints, but no further: a request intercepted by a proxy, logged, replayed or modified outside the tunnel no longer carries any guarantee. Application-level signing:

• protects against intermediary modifications;
• ensures non-repudiation (you cannot deny having sent a signed message);
• survives proxies, caches and log dumps;
• enables asynchronous verification (audit, replay, debug).

It is the equivalent of PAdES for PDF, but applied to HTTP APIs.

Structure of a signed request (RFC 9421)

POST /payments HTTP/1.1
Host: api.bank.fr
Content-Type: application/json
Content-Length: 423
Date: Sat, 19 Apr 2026 10:30:00 GMT
Content-Digest: sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:
Signature-Input: sig1=("@method" "@target-uri" "host" "date" "content-digest");\
                  alg="rsa-pss-sha512";\
                  keyid="qsealc-key-1";\
                  created=1714000000
Signature: sig1=:VXYZ12345...base64...:
 
{ "instructed_amount": { "currency": "EUR", "amount": "100.00" }, ... }

The components: Content-Digest (SHA-256 hash of the body), Signature-Input (what is signed: method, URI, headers, plus alg, keyid, timestamp) and Signature (the base64 signature). Recommended algorithms: rsa-pss-sha512 (FAPI / PSD2), ecdsa-p256-sha256 (mobile), ed25519.

The PSD2 + QSealC flow

The QSealC (Qualified Seal Certificate, eIDAS) is used to sign a message on behalf of a legal entity (the TPP). The TPP signs with its private key, and the ASPSP verifies the signature and the chain of trust (QSealC → qualified TSP → EU LOTL), then checks the EBA register to confirm that the TPP indeed holds the required role.

RFC 9421 vs the Cavage draft

Use cases

• PSD2 / Open Banking: signing TPP → ASPSP requests (PIS, AIS, CBPII), and sometimes responses.
• eHealth: signing between healthcare parties (DMP, Mon espace santé).
• Webhooks: Stripe, GitHub and Slack sign their webhooks (HMAC or an RFC 9421-like approach).
• B2B API marketplaces: Apigee and Kong support HTTP Signature for strong authentication.

What HTTP Signature is not

• Not a replacement for TLS: it is an application-level complement; TLS remains mandatory.
• Not encryption: it is a signature (integrity + authenticity); for confidentiality, see JWE.
• Not mandatory for OAuth: access tokens work without it, but FAPI 2.0 combines them.
• Not mTLS: mTLS authenticates the channel, HTTP Signature the message — they are complementary.
• Not a universal format: the Cavage variant remains very common.

In the PSD2 / Open Finance ecosystem

HTTP Signature + QSealC is the European approach to PSD2 API security:

• Berlin Group: requires the Signature + Digest headers, often in Cavage style.
• STET: signature + digest + X-Request-ID.
• OBIE UK: uses a JWT detached signature (different, same spirit).
• PSD3 / FIDA: should standardize on RFC 9421 with QSealC, and converge toward FAPI 2.0.

Concrete examples

• Bridge: signs its requests to FR banks with a QSealC (Cavage style, migrating to RFC 9421).
• Fintecture: signs its PIS requests to BNP, SG, BPCE.
• Tink: signs in the EU and UK (dual profile).
• Stripe webhooks: Stripe-Signature: t=...,v1=hmac_sha256_hash.
• GitHub webhooks: X-Hub-Signature-256: sha256=... (HMAC).
• Tools: http-message-signatures (Python, Node), plugins for Apigee, Kong, Tyk.
• Migration: European ASPSPs are moving to RFC 9421 over 2025-2027, keeping Cavage in parallel.
• Cost: for a TPP, integration takes a few weeks, but managing QSealC keys (HSM) is the main operational challenge.