Technical

HTTP Signature

HTTP Message Signatures (RFC 9421) — application-level HTTP signature

An IETF standard (RFC 9421, finalized 2024) defining a mechanism for signing HTTP requests and responses. It provides application-level integrity/authenticity on top of TLS, required by PSD2 RTS-SCA for TPPs in the EU (signed with a QSealC).

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

AspectCavage (before 2024)RFC 9421 (2024+)
StatusIETF draftStable RFC
Naming(request-target), (created)@method, @target-uri
Multi-signaturesHardNative (labels)
Structured fieldsNoYes (RFC 8941)
DigestDigest header (RFC 3230)Content-Digest (RFC 9530)
EU PSD2 adoptionCavageMigration to 9421 under way

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 / PSR: the April 2026 compromise names no signature or certificate format. TPP identification and communication standards are left to the EBA's RTS (art. 89, provisional numbering).

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.

See also: STET handbook

Sources

Go deeper

From the blog

Longer reads to go beyond the definition.

August 24, 2026
security

QWAC vs QSealC: who does what, and why you've got the wrong layer — Read more

The QWAC is read by the TLS layer, once, at the handshake. The QSealC is read by the application layer, on every request. Where each private key lives, what STET requires, and how to read a 'certificate error'.

April 7, 2026
technical

Technical architecture of a PSD2 API: what to know before writing the first line of code — Read more

A technical overview of PSD2 for CTOs, developers and technical PMs: API standards, security (mTLS, eIDAS certificates), OAuth2, SCA flows, consent management, implementation pitfalls.

April 6, 2026
regulation

Understanding PSD2: what it changes for your customers and your business — Read more

Everything an executive, a product manager or a business team needs to understand about PSD2. Players, consent, opportunities, without technical jargon.