QSealC

Définition

Le QSealC (Qualified electronic Seal Certificate) est un certificat eIDAS qualifié qui permet à un TPP de signer électroniquement chaque requête HTTP envoyée à une banque.

Contrairement au QWAC, qui s'arrête à la couche TLS, le QSealC opère au niveau applicatif : la signature voyage dans la requête elle-même et constitue une preuve juridique opposable de qui a envoyé quoi, quand et avec quel contenu.

QSealC vs QWAC : signature vs identification

C'est la dualité fondamentale de la sécurité DSP2 :

• QWAC — identification au niveau transport (mTLS) : « je suis bien Bridge ». Disparaît après le handshake.
• QSealC — signature au niveau applicatif (HTTP-signature) : « voici ma requête, scellée, prouvable demain ». Persiste dans les logs et les traces.

En cas de litige (paiement contesté), c'est le QSealC que la banque exhibera, pas le QWAC.

Comment fonctionne la signature

Le standard est HTTP-signature (repris par STET et Berlin Group) :

1. Le TPP calcule un hash du corps de la requête (Digest).
2. Il sélectionne plusieurs en-têtes critiques (request-target, host, date, digest, x-request-id).
3. Il les signe avec la clé privée associée au QSealC.
4. La signature est ajoutée dans l'en-tête Signature.
5. L'ASPSP récupère le QSealC (via keyId), vérifie la signature et rejoue le digest.

Toute altération en route — même un caractère — invalide la signature et rejette la requête.

Ce qu'un QSealC ne fait pas

• Ne sécurise pas la connexion : c'est le rôle du mTLS (avec QWAC).
• Ne remplace pas la SCA : il prouve l'identité du TPP, pas celle du PSU.
• Ne signe pas tout seul : le TPP doit implémenter correctement la chaîne (digest, headers, signature) — l'oubli du x-request-id ou une casse différente sont des erreurs fréquentes.
• Ne se confond pas avec une signature personnelle : c'est un cachet électronique d'une personne morale, pas d'une personne physique.

Dans l'écosystème PSD2

Le QSealC est la brique non-répudiation : sans lui, un TPP pourrait nier avoir envoyé une requête, ou un attaquant pourrait modifier une demande de virement en route sans détection. C'est ce qui donne sa valeur juridique au flux DSP2.

Exemples concrets

• Cas typique : un PISP (Fintecture, Bridge, Trustly) initie un virement de 12 500 €. Le QSealC scelle le montant, l'IBAN bénéficiaire et le timestamp ; en cas de contestation, la banque prouve à la milliseconde ce que le PISP a demandé.
• Émetteurs : les mêmes que pour le QWAC (Certigna, Certinomis, D-Trust, InfoCert), souvent vendus en bundle QWAC + QSealC.
• Erreurs classiques : casse des headers (Digest vs digest), espace ajouté après sérialisation JSON qui change le digest, horloge désynchronisée rejetée par l'ASPSP.
• Outils : les sandboxes de Bridge et STET offrent des outils de dump de requête ; côté open-source, la lib http-message-signatures (Node, Python, Java) couvre la plupart des cas.
• Côté ASPSP : l'absence de QSealC valide est la première cause de rejet en sandbox — à vérifier en priorité.