1.6K VUES
Pinterest LinkedIn LINE

1. Naissance de la RFC 9901

19 novembre 2025, « Divulgation sélective pour les jetons Web JSON », alias SD-JWT Les spécifications qui définissent (SDJOT) RFC 9901 Il a été publié sous le nom de.

Les auteurs sont les trois personnes suivantes.

Jeton Web JSON (JWT) [RFC 7519]Et Signature Web JSON (JWS) [RFC 7515]は,Jeton d'identificationやJeton d'accès JWT [RFC 9068]Il s'agit d'une norme Internet qui a été largement utilisée dans
SD-JWT nous offre la nouvelle possibilité d'extraire et d'afficher uniquement les parties dont nous aurons besoin ultérieurement.

Dans la lignée de la famille JOSE (JWS / JWT / JWE),
On peut considérer cela comme l'ajout d'un nouveau pilier appelé « divulgation sélective » en tant que RFC officielle.

2. À quoi sert la spécification SD-JWT ?

2-1. Problèmes liés aux JWT conventionnels : « émis à la demande » ou « tout compris »

Les JWT traditionnels étaient basés sur un modèle dans lequel un « bloc de JSON signé » était transmis directement au service.

  • L'émetteur (IdP ou serveur d'authentification) compile les informations de l'utilisateur dans un JWT.
  • Le service destinataire (partie utilisatrice) peut lire l'intégralité du contenu

Cela signifie que si vous utilisez un modèle comme OpenID Connect, où les certificats sont émis dynamiquement selon les besoins, il est possible d'obtenir une divulgation sélective, une minimisation des données et une absence de lien entre les fournisseurs de services (RP+RP'-U) (généralement grâce à l'utilisation d'un identifiant pseudonyme par paire). En revanche, si vous souhaitez « émettre un certificat à l'avance sans en connaître la finalité, puis l'utiliser ultérieurement », aucune de ces possibilités n'est offerte.

Par exemple, si un seul JWT contient « âge », « adresse », « nom » et « adresse e-mail », le serveur n'aura peut-être besoin de savoir que si l'utilisateur a plus de 20 ans, mais s'il utilise un JWT qui a été émis et enregistré à l'avance, il pourra tout voir, y compris l'adresse et le nom de l'utilisateur.

Cette structure « tout-en-un » est simple à mettre en œuvre, mais si vous souhaitez économiser et utiliser,

  • La divulgation sélective étant impossible, le principe de minimisation de la collecte de données ne peut être respecté.
  • La non-liaison RP+RP'-U n'est pas non plus satisfaite.

Telles étaient les limitations (même si cela impliquait un compromis avec la simplicité de la mise en œuvre).

2-2. Compatibilité avec les modèles de portefeuille

D'un autre côté, il existe certainement des cas d'utilisation où l'on souhaite réutiliser des données enregistrées. Par exemple, dans des endroits sans réseau ou pour présenter un certificat de fin d'études après la fermeture d'un établissement scolaire. On pourrait se demander : « Est-ce vraiment si fréquent de ne pas avoir de réseau ? », mais c'est parce que le Japon bénéficie d'un environnement favorable. En Europe, la qualité du signal est médiocre, surtout à l'intérieur des bâtiments en pierre, et même en s'éloignant légèrement de la station, on peut perdre le signal à l'extérieur, même dans de grandes villes comme Mannheim. C'est également le cas aux États-Unis. C'est peut-être pour cette raison qu'en Europe… Portefeuille EUDI Les portefeuilles d'identité récents comprennent :

  • Un seul portefeuille (application pour smartphone) peut gérer plusieurs transactions Identifiants vérifiables (VC) Économisez le
  • L'utilisateur sélectionne « Afficher uniquement cet élément pour ce service » et le présente.

Ce modèle constitue le postulat de base. Dans ce cas, le portefeuille et l'émetteur n'ont besoin d'être connectés en ligne que lors de l'émission.

Ce dont on a besoin ici, c'est

« Un format qui vous permet de sélectionner et d'afficher ultérieurement en toute sécurité une partie d'un fichier de données signé et stocké. »

Ceci est défini par RFC 9901 Ceci est SD-JWT.

3. SD-JWT en bref

En résumé, le fonctionnement de SD-JWT est le suivant :

  1. La base est la même qu'avant Signé JWT (JWS)
  2. Cependant, certaines affirmations sontSeule la valeur de hachage" dans le JWT
  3. En combinant la valeur initiale et le sel Divulgation Conservez-le séparément et ne le transmettez au vérificateur que lorsque cela est nécessaire.
  4. Le vérificateur est
    • Recalculez le hachage à partir de la divulgation
    • En vérifiant qu'il correspond au hachage du JWT signé
    • Vous pouvez confirmer que « cela fait bien partie des données signées par l'émetteur ».

De plus, afin d'empêcher le transfert non autorisé de jetons, Un mécanisme permettant d'associer une paire de touches à un utilisateur (liaison de touches) sont également disponibles.
La structure combinée SD-JWT+KB と 呼 び ま す.

4. Trois caractères et le flux du SD-JWT

Les personnages principaux de SD-JWT sont les mêmes que dans l'univers de VC.

  • Émetteur
    Bureaux gouvernementaux, banques, universités, etc. Organisations responsables des faits.
  • Titulaire
    L'utilisateur conserve lui-même les identifiants dans l'application portefeuille sur son smartphone.
  • Vérificateur
    Prestataires de services, tels que l'ouverture de comptes bancaires, la vérification de l'âge et le contrôle d'accès.

Le déroulement typique est le suivant :

  1. Émission
    • L'émetteur compile les informations d'attributs de l'utilisateur (adresse, date de naissance, etc.) au format JSON.
    • Concernant les « éléments que vous souhaiteriez divulguer sélectivement ultérieurement »,
      Calculez un hachage à partir de la valeur et d'un sel aléatoire, puis intégrez uniquement ce hachage dans le JWT.
    • La valeur initiale + le sel sont préparés séparément à titre de divulgation.
    • Le JWT signé et les multiples informations divulguées sont regroupés et transmis au titulaire sous la forme d'un « SD-JWT ».
  2. Présentation
    • Un utilisateur tente d'utiliser un service
    • Le portefeuille sélectionne uniquement les informations qu'il souhaite montrer au vérificateur à partir du SD-JWT.
    • Envoyez le JWT signé + la divulgation sélectionnée + (et le JWT de liaison de clé, le cas échéant) au vérificateur.
  3. Vérification
    • Le vérificateur est
      • Vérifiez la signature JWT avec la clé publique de l'émetteur.
      • Utilisez Disclosure pour recalculer le hachage de chaque élément et vérifiez qu'il correspond à celui du JWT.
    • Cela garantit que les données font partie des données signées par l'émetteur, tout en protégeant les éléments non divulgués.

5. Un peu de jargon technique : Sel et divulgation

5-1. Divulgation sélective utilisant le hachage salé

Chaque demande (adresse, date de naissance, etc.)

  • Sel + Valeur + (nom de la revendication éventuelle)

Calculez le hachage à partir du JWT et intégrez la valeur de hachage dans le JWT.

Lors de la divulgation proprement dite, il convient de l'indiquer comme « Divulgation ».

  • "Sel, Nom de la réclamation, Valeur"

au vérificateur.

Le vérificateur recalcule le hachage en utilisant la même procédure et vérifie s'il correspond au hachage du JWT pour voir s'il a été falsifié.
La présence de sel rend difficile l'estimation de la valeur des créances non divulguées.

5-2. Divulgation

La RFC définit une divulgation comme un tableau JSON encodé en Base64url, par exemple :

  • Élément 0 : Sel
  • Élément 1 : Nom de la revendication (peut être omis pour les éléments de tableau)
  • Élément 2 : Valeur de la réclamation

À l'intérieur du portefeuille,

«Conservez un seul document d'identification important regroupant plusieurs petites informations à divulguer, et n'envoyez que ce dont vous avez besoin.»

Je pense que c'est plus facile à comprendre si on y réfléchit de cette façon.

5-3. Association de touches et SD-JWT+KB

Avec le seul SD-JWT, il subsiste le risque d'une attaque (attaque par rejeu) dans laquelle un jeton est copié et présenté par quelqu'un d'autre.
Par conséquent, la RFC 9901 spécifie un mécanisme pour lier un SD-JWT à une paire de clés du détenteur. Raccourci clavier définit :

  • Incluez la clé publique du détenteur (ou une référence à celle-ci) dans le SD-JWT.
  • Le détenteur signe avec cette clé lors de sa présentation. Liaison de touches JWT (KB-JWT) Envoyer ensemble
  • Le vérificateur est
    • SD-JWT et KB-JWT sont liés à la même clé
    • Vérifiez que le détenteur possède bien la clé privée.

L'attribution des touches est désormais requise. SD-JWT+KB Cela augmentera la résistance à la copie de VC.

注La liaison de titulaire peut se faire par liaison de clé, liaison de revendication ou liaison biométrique. +KB utilise la liaison de clé. Cependant, avec ce type de liaison, si l'appareil ou tout autre support contenant la clé est transféré, une personne mal intentionnée peut usurper votre identité (attaque dite « Alice-à-Bob »). L'achat et la vente d'un compte bancaire en sont un parfait exemple. Pour éviter ce type d'usurpation d'identité, la liaison biométrique est généralement requise.

5-4. Prise en charge des structures et tableaux JSON

La RFC 9901 va au-delà du simple JSON plat.

  • Objets imbriqués
  • Divulgation élément par élément des tableaux
  • Dissimulation de motifs à l'aide de « dummy hashes (deuseds) »

Il définit également la manière de gérer de tels cas.

Cette

  • Empêcher les gens de supposer que « tout le monde a les mêmes qualifications ».
  • Réduisez le risque d'être suivi uniquement par le nombre d'éléments divulgués.

Cela permet de proposer des idées telles que :

6. Portefeuilles d'identité SD-JWT et VC

6-1. SD-JWT VC : Positionnement en tant que format VC

L'IETF utilise SD-JWT dans la RFC 9901. Spécification pour l'expression des justificatifs d'identité vérifiables として
"Identifiants vérifiables basés sur SD-JWT (SD-JWT VC)" Un projet de loi est en cours d'élaboration.

こ れ は,

  • VC au format JSON
  • SD-JWT permet la divulgation sélective
  • Déterminer la méthode de vérification

Il s'agit d'une spécification qui a le rôle suivant. Actuellement, le groupe de travail est en phase de révision avant de passer à la phase finale d'examen, et je suis également relecteur.Environ 28 améliorations éditoriales(Certaines suggestions peuvent être considérées comme techniques.) (Ces suggestions consistent notamment à simplifier les phrases longues et difficiles à lire lorsqu'elles sont écrites par des Américains ou des Allemands, à clarifier le rôle de l'exécuteur d'obligations en raison de l'utilisation excessive de la voix passive, et à prendre en compte les aspects liés à la sécurité, à la confidentialité et à l'équité.) De plus, afin de vérifier les exemples inclus dans le projet de spécification, nous avons créé une page HTML/JavaScript statique.décodeur SD-JWT" a également été créé.Il est également disponible sur GitHub(Il s'agit simplement d'une page HTML unique, elle peut donc être facilement exécutée en local - j'en avais besoin pour vérifier le brouillon dans un avion), donc si vous trouvez des bugs, veuillez soumettre une demande de fusion.

6-2. À utiliser avec le portefeuille EUDI

Commission européenne Cadre de référence d'architecture EUDI (ARF) La norme à utiliser dans les portefeuilles d'identité numérique européens est donc la suivante :

  • OpenID pour les informations d'identification vérifiables (OpenID4VCI / OpenID4VP)
  • SD-JWT / SD-JWT VC
  • Permis de conduire mobile ISO/IEC 18013-5 (mDL)

Il a été démontré qu'une combinaison des éléments suivants peut être utilisée.

Dans ce contexte, la RFC 9901 stipule :

« Les VC stockés dans des portefeuilles d'identité tels que les portefeuilles EUDI »
Format de base pour l'implémentation basée sur JWT/JOSE

Elle est positionnée comme suit.

6-3. Avantages du point de vue des utilisateurs de portefeuilles électroniques

L'expérience utilisateur générale ressemblera à ceci :

  • Confirmation d'âge
    Dans les supérettes, il vous suffit de dire que vous avez plus de 20 ans, pas votre date de naissance.
  • Vérification d'adresse
    Indiquez uniquement l'adresse de livraison au site de vente en ligne et masquez les autres informations.
  • Connaissez votre client (KYC)
    Ne présentez aux banques et aux sociétés de courtage que les attributs nécessaires, et réutilisez le même VC pour d'autres services.

Tout ceci est rendu possible par la nature du SD-JWT, qui permet de décomposer une seule donnée signée en morceaux plus petits et d'en extraire uniquement les parties nécessaires.

7. Expansion de l'écosystème (aperçu)

Plusieurs solutions OSS et commerciales intègrent déjà SD-JWT/SD-JWT VC dans leurs implémentations.

  • Prise en charge de SD-JWT dans divers frameworks de portefeuilles :Fondation Siros L'un d'eux est wwWallet, développé par .
  • Fourniture de points de terminaison d'émission SD-JWT VC par Authlete et d'autres organisations
  • Adoption dans le cadre du projet EUDI Wallet et de l'initiative SPRIND
  • La Fondation OpenID a développé un profil de haute sécurité (HAIP) qui combine OpenID4VC et SD-JWT VC.

Le RFC 9901 est positionné comme une « pièce maîtresse » au-dessus de ce mouvement.

8. Résumé

  • RFC 9901 est une norme Internet qui donne à JWT/JWS la possibilité de « divulguer de manière sélective ».
  • SD-JWT est
    • Le JWT signé ne contient que le hachage.
    • La valeur d'origine et la teneur en sel ne sont mentionnées à titre d'information que lorsque cela est nécessaire.
    • Toutefois, la signature de l'émetteur garantit toujours l'authenticité.
      Il définit le format.
  • Ajout d'une liaison de touche SD-JWT+KB Cela permet une présentation sécurisée liée au propriétaire du portefeuille.
  • Combiné avec le brouillon SD-JWT VC, l'EUDI ARF et le profil OpenID4VC,
    L'un des formats de base pour les VC stockés dans les portefeuilles d'identité Il sera utilisé comme.

Ce nouvel élément a été ajouté à la famille de technologies JOSE/JWT, et l'on peut dire qu'un modèle de mise en œuvre réaliste pour une infrastructure d'identité numérique basée sur un portefeuille numérique est désormais clair.