Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)

Remarque

Spécification de l'IETF qui décrit comment déclarer dans un jeton JWT que son présentateur possède une clé de preuve de possession et comment le destinataire le confirme.

Résumé

Objet

La RFC 7800 de l’IETF (avril 2016) explique comment déclarer, dans un jeton JWT, que celui qui le présente possède une clé donnée, et comment le destinataire peut le vérifier :

Elle sert à prouver la possession d’une clé (proof of possession) ; on parle aussi de présentateur « détenteur de la clé » (holder-of-key) RFC 7800, Abstract. Le règlement d’exécution 2024/2977 s’en sert pour la PID au format SD-JWT VC.

À qui ça s’applique

La RFC elle-même n’impose rien au titre d’eIDAS. Elle s’applique par renvoi aux fournisseurs de données d’identification personnelle (PID) :

• ils veillent à ce que les PID délivrées soient conformes à l’annexe du règlement d’exécution 2024/2977 Art. 3 §3 ;
• ils veillent à ce que les PID soient liées de manière cryptographique à l’unité de portefeuille à laquelle elles sont délivrées Art. 3 §5.

Au format SD-JWT VC, l’annexe exige que la PID comprenne la revendication cnf définie dans la RFC 7800 Annexe.

Points clés

• Une clé publique du portefeuille. Selon l’annexe, la revendication cnf de la PID doit être une clé publique générée à partir d’une clé privée stockée dans le dispositif cryptographique sécurisé (WSCD) de l’unité de portefeuille de l’utilisateur Annexe. Le WSCD est un dispositif inviolable qui protège les actifs critiques et fournit des fonctions cryptographiques Art. 2 §8.
• Le rôle de cnf. Dans la RFC, cette revendication contient les éléments qui identifient la clé de preuve de possession RFC 7800, § 3.1. Confirmation Claim.
• Une seule clé. La valeur de cnf ne doit représenter qu’une seule clé de preuve de possession RFC 7800, § 3.1. Confirmation Claim.
• Clé asymétrique. Quand le présentateur détient une clé privée asymétrique, le membre jwk donne la clé publique correspondante, sous forme de clé web JSON (JWK) RFC 7800, § 3.2. Representation of an Asymmetric Proof-of-Possession Key.
• Ce que la RFC laisse aux protocoles. La preuve se fait en général par la signature d’une valeur fixée par le destinataire (un « nonce ») ; la manière de transmettre ce nonce et sa signature n’est pas décrite par la RFC RFC 7800, § 3.6. Specifics Intentionally Not Specified.
• L’équivalent au format mdoc. Pour la PID au format ISO/IEC-mdoc, l’annexe prévoit un mécanisme parallèle : une clé publique dans le membre deviceKey de l’objet de sécurité, correspondant à une clé privée stockée dans le WSCD Annexe.

Clauses visées par l’acte

• L’annexe du règlement d’exécution 2024/2977 renvoie à la définition de la revendication cnf dans la RFC, sans numéro de clause, et ajoute une exigence propre : la clé publique provient d’une clé privée stockée dans le WSCD Annexe.
• L’annexe du règlement d’exécution 2024/2977 a été remplacée par le règlement d’exécution 2026/1731 Règlement d'exécution (UE) 2026/1731 ; ce résumé cite la version consolidée qui l’intègre.

Liens

• Acte qui la rend applicable : règlement d’exécution 2024/2977 Règlement d'exécution (UE) 2024/2977 — version consolidée au 11/08/2026.
• Normes liées : RFC 7519, jeton JWT RFC 7519 ; SD-JWT VC, projet de l’IETF draft-ietf-oauth-sd-jwt-vc-22.
• Parcours : étape 3, le portefeuille européen.

Rédaction Asphalia.