HTTP Signature

Définition

HTTP Message Signatures (ou HTTP Signature) est un standard IETF finalisé dans la RFC 9421 (février 2024) pour signer les requêtes et réponses HTTP.

Il apporte une intégrité et une authenticité applicatives en complément de TLS : même si TLS protège le transport, la signature prouve qu'un message HTTP précis a bien été émis par un acteur identifié, sans modification. C'est le standard de référence en DSP2 RTS-CSC, où les TPP signent leurs requêtes API avec un QSealC (eIDAS), de même que côté Berlin Group et STET.

Avant la RFC 9421, l'industrie utilisait l'ancien draft Cavage (draft-cavage-http-signatures), proche mais non final ; la RFC 9421 le modernise (labels, structured fields, Content-Digest).

Pourquoi HTTP Signature

TLS protège entre les deux endpoints, mais pas au-delà : une requête interceptée par un proxy, journalisée, rejouée ou modifiée hors du tunnel n'a plus aucune garantie. La signature applicative :

• protège contre les modifications intermédiaires ;
• assure la non-répudiation (impossible de nier avoir envoyé un message signé) ;
• survit aux proxies, caches et dumps de logs ;
• permet une vérification asynchrone (audit, replay, debug).

C'est l'équivalent de PAdES pour le PDF, mais appliqué aux API HTTP.

Structure d'une requête signée (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" }, ... }

Les composants : Content-Digest (hash SHA-256 du body), Signature-Input (ce qui est signé : méthode, URI, headers, plus alg, keyid, timestamp) et Signature (la signature en base64). Algorithmes recommandés : rsa-pss-sha512 (FAPI / DSP2), ecdsa-p256-sha256 (mobile), ed25519.

Le flow DSP2 + QSealC

Le QSealC (Qualified Seal Certificate, eIDAS) sert à signer un message au nom d'une personne morale (le TPP). Le TPP signe avec sa clé privée, l'ASPSP vérifie la signature et la chaîne de confiance (QSealC → TSP qualifié → EU LOTL), puis confronte au registre EBA pour s'assurer que le TPP a bien le rôle requis.

RFC 9421 vs draft Cavage

Cas d'usage

• DSP2 / Open Banking : signature des requêtes TPP → ASPSP (PIS, AIS, CBPII), et parfois des réponses.
• eHealth : signature inter-acteurs santé (DMP, Mon espace santé).
• Webhooks : Stripe, GitHub et Slack signent leurs webhooks (HMAC ou approche RFC 9421-like).
• API marketplaces B2B : Apigee, Kong supportent HTTP Signature pour une authentification forte.

Ce que HTTP Signature n'est pas

• Pas un remplaçant de TLS : un complément applicatif ; TLS reste obligatoire.
• Pas du chiffrement : c'est de la signature (intégrité + authenticité) ; pour la confidentialité, voir JWE.
• Pas obligatoire pour OAuth : les access tokens fonctionnent sans, mais FAPI 2.0 les combine.
• Pas du mTLS : mTLS authentifie le canal, HTTP Signature le message — complémentaires.
• Pas un format universel : la variante Cavage reste très présente.

Dans l'écosystème PSD2 / Open Finance

HTTP Signature + QSealC est l'approche européenne de la sécurité API DSP2 :

• Berlin Group : impose les headers Signature + Digest, souvent en style Cavage.
• STET : signature + digest + X-Request-ID.
• OBIE UK : utilise une JWT detached signature (différente, même esprit).
• DSP3 / FIDA : devraient standardiser sur RFC 9421 avec QSealC, et converger vers FAPI 2.0.

Exemples concrets

• Bridge : signe ses requêtes vers les banques FR avec QSealC (style Cavage, en migration RFC 9421).
• Fintecture : signe ses requêtes PIS vers BNP, SG, BPCE.
• Tink : signe en EU et UK (double profil).
• Stripe webhooks : Stripe-Signature: t=...,v1=hmac_sha256_hash.
• GitHub webhooks : X-Hub-Signature-256: sha256=... (HMAC).
• Outils : http-message-signatures (Python, Node), plugins Apigee, Kong, Tyk.
• Migration : les ASPSP européens basculent vers RFC 9421 sur 2025-2027, en maintenant Cavage en parallèle.
• Coût : pour un TPP, l'intégration prend quelques semaines, mais la gestion des clés QSealC (HSM) est l'enjeu opérationnel majeur.