Résumé
- Le RFC 9901 lie une Disclosure présentée à un digest inclus dans un JWT signé; il garantit l’intégrité de la valeur montrée, non l’exhaustivité des valeurs cachées.
- Le détenteur choisit une partie des revendications, le vérificateur contrôle la cryptographie, puis le système local décide séparément si cette partie suffit à une action.
Un justificatif discret peut produire une erreur très bruyante: une organisation reçoit une affirmation favorable, valide sa signature, puis traite le silence sur le reste comme un verdict favorable. Or le silence est précisément une possibilité que le format préserve.
Le RFC 9901 définit le SD-JWT. L’émetteur signe un JWT qui porte des revendications lisibles et, pour les autres, des digests. Une Disclosure contient un sel aléatoire, un nom de revendication quand il y en a un et une valeur. Le détenteur conserve les Disclosures reçues, puis n’en transmet à chaque vérificateur que la sélection voulue. Le vérificateur recalcule le digest: si le digest figure dans le JWT signé, il sait que cette valeur révélée correspond à l’engagement de l’émetteur.
La conclusion est étroite et utile. Elle ne dit pas que le vérificateur a reçu un dossier complet. Le détenteur peut présenter zéro, une ou toutes les Disclosures. L’émetteur peut laisser certaines revendications en clair et rendre les autres sélectives; il peut aussi ajouter des digests leurres. Une absence visible ne permet donc ni de compter sûrement les éléments cachés, ni de convertir ce qui n’est pas présenté en réponse négative.
Il faut séparer les étapes. L’émetteur a signé une structure. Il a choisi ce qui pouvait être révélé sélectivement. Le détenteur a choisi une sélection pour cette interaction. Le vérificateur a validé les signatures et les digests de cette sélection. Enfin, une application locale a évalué ses propres critères et, peut-être, exécuté une action. Dire « le jeton a prouvé l’éligibilité » fusionne ces cinq propositions.
La signature ne supprime pas ce partage. Elle protège l’intégrité de la structure après émission; elle ne garantit pas la qualité de l’observation qui a motivé une revendication, son actualité ou son sens dans chaque application. RFC 7519 fournit un format de claims. Le registre IANA donne des noms partagés. La règle qui décide qu’un nom précis est indispensable, suffisant ou périmé appartient au profil et au vérificateur qui l’utilise.
Le Key Binding, facultatif, ajoute une preuve située. Si la politique du vérificateur l’exige, le détenteur joint un KB-JWT signé par sa clé privée, portant un hachage du SD-JWT, un nonce et une audience. Le vérificateur peut alors établir la possession de cette clé pour cette présentation. Il ne reçoit pas pour autant la preuve que toutes les revendications pertinentes ont été transmises, que leur contenu est toujours vrai, ou que l’action demandée est autorisée.
Cette distinction doit aussi rester visible dans l’autre sens. Sans Key Binding imposé, toute entité qui possède un SD-JWT peut le transmettre à un tiers qui n’impose pas cette vérification, et peut en retirer des Disclosures. L’objet reçu ne démontre donc pas de lui-même la participation présente du détenteur ni le contexte initial de sa présentation.
Le RFC impose des limites qui empêchent de masquer les contrôles décisifs. L’émetteur ne doit pas rendre sélectivement révélable un contenu critique pour l’authenticité ou la validité; la liste exacte dépend du profil. Le vérificateur doit contrôler la signature de l’émetteur et lier chaque Disclosure à son digest. RFC 8725 recommande en outre un typage explicite lorsque différents usages de JWT pourraient être confondus. Les exigences de preuve ne sont pas créées par une signature générique; elles sont définies par le cas d’usage.
Le journal opérationnel doit donc distinguer l’émetteur et la politique de clé, le type explicite, les revendications requises, celles qui furent effectivement présentées, le résultat du Key Binding, le nonce et l’audience, la version de règle locale, puis l’action finale. Une ligne « justificatif vérifié » masque les informations qui expliquent réellement une décision.
La lecture de Heng Lu sert ici de discipline analytique: une représentation transportable, une interprétation locale et un effet exécuté ne sont pas une seule réalité. Le RFC 9901 rend une affirmation portable tout en préservant le choix de divulgation. Il ne donne à aucun participant le droit de transformer une sélection privée en dossier exhaustif.
Sources
- RFC 9901 — Selective Disclosure for JSON Web Tokens
- RFC 7515 — JSON Web Signature
- RFC 7519 — JSON Web Token
- RFC 7800 — Proof-of-Possession Key Semantics for JWTs
- RFC 8725 — JSON Web Token Best Current Practices
- Registre IANA des revendications JWT
- RFC 8174 — Ambiguïté des mots-clés RFC 2119
- Lu Heng — Running-Code Primacy
- Lu Heng — Minimum Initial Specification, Localized Future Decision
- Lu Heng — Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance

