Résumé

  • L’émetteur remplace le contenu en clair des éléments divulgables par des condensés dans la charge utile signée et remet séparément des Disclosures au détenteur. Celui-ci choisit les Disclosures valides à présenter; le vérificateur recalcule les condensés et reconstruit la charge utile traitée.
  • Une Disclosure de propriété d’objet contient un sel, le nom de la revendication et sa valeur. Une Disclosure d’élément de tableau contient un sel et une valeur. Les sels doivent être aléatoires, indépendants et uniques par revendication, puis rester cachés jusqu’à la divulgation; la RFC recommande au moins 128 bits aléatoires.
  • _sd_alg, au niveau supérieur, choisit le condensé. L’usage imbriqué est interdit, l’absence signifie sha-256 et les implémentations doivent prendre en charge sha-256. Le JWT signé de l’émetteur doit être signé, ne jamais utiliser none, et être contrôlé avant chaque Disclosure présentée.

La RFC 9901 est une spécification Standards Track, pas un mécanisme de chiffrement. Elle ne permet pas de retrouver les revendications non divulguées, ne remplace pas un transport confidentiel et ne transforme pas une présentation en preuve à divulgation nulle de connaissance ni en justificatif anonyme. Le contrôle se déplace le long d’une chaîne: conception des divulgations par l’émetteur, choix du détenteur, politique du vérificateur et, si nécessaire, preuve de possession d’une clé.

La structure peut être récursive. Un enfant caché peut dépendre de la divulgation de son parent; une présentation qui omet cette dépendance est donc invalide, même si la Disclosure de l’enfant est individuellement bien formée. Des condensés leurres peuvent masquer le nombre ou l’existence initiale de revendications cachées, au prix d’un jeton plus volumineux. Ils atténuent un canal auxiliaire; ils n’empêchent pas la corrélation et ne garantissent pas l’absence de lien.

La liaison de clé est optionnelle, sauf si un profil ou un cas d’usage l’exige. Lorsqu’elle est utilisée, le SD-JWT contient la clé publique du détenteur ou une référence, et celui-ci signe un KB-JWT avec typ kb+jwt, iat, aud, nonce et sd_hash. sd_hash lie le KB-JWT au JWT exact de l’émetteur et aux Disclosures sélectionnées. Le vérificateur qui l’exige contrôle la clé, la signature, l’algorithme, le type, la fenêtre temporelle, l’audience, le nonce et cette liaison.

Le vérificateur doit rejeter une signature d’émetteur invalide, none, une déclaration de condensé incorrecte ou mal placée, un condensé de Disclosure qui échoue, une reconstruction malformée, une dépendance récursive absente ou une revendication requise manquante. Les profils doivent préciser les revendications indispensables: rendre exp divulgable, par exemple, peut priver le vérificateur d’une donnée nécessaire au rejet. Le transport reste confidentiel lorsque les risques de vie privée ou de corrélation passive le justifient; la RFC 9901 ne définit aucun mécanisme de chiffrement et s’en remet au protocole de transport. Le stockage doit rester limité, car sels, Disclosures et éléments stables du justificatif peuvent accroître la corrélation.

Analyse de Theo March — pas une exigence de la RFC. Les émetteurs devraient définir un schéma de divulgation minimale; les vérificateurs ne demander que les preuves imposées par leur politique; les interfaces de consentement rendre chaque Disclosure compréhensible; les journaux éviter le clair inutile; l’application définir les rappels de révocation; et le cycle de vie des clés traiter rotation, perte et récupération. Une émission par lots avec des sels et des clés de détenteur nouveaux peut améliorer certaines possibilités de non-corrélation entre vérificateurs et présentations. Rien de tout cela n’est automatique, et l’adoption, les performances, le statut juridique et le comportement des portefeuilles restent inconnus ici.

La limite est nette: un justificatif stable signé par l’émetteur peut permettre à des émetteurs et vérificateurs qui coopèrent de reconnaître le même justificatif. L’émission par lots peut améliorer certaines formes de non-corrélation entre vérificateurs, mais ne fournit pas de non-corrélation émetteur-vérificateur face à une collusion. La divulgation sélective redistribue la confiance; elle ne la supprime pas.

Contrôles de conformité

  1. Confirmer que la RFC 9901 gouverne le SD-JWT et que les RFC 7515/7519 ne servent que de base JWS/JWT.
  2. Pour chaque propriété d’objet et élément de tableau, vérifier un sel aléatoire, indépendant et unique d’au moins 128 bits.
  3. Contrôler _sd_alg au niveau supérieur, le défaut sha-256, l’absence d’imbrication et le support de l’algorithme.
  4. Vérifier la signature, refuser none, recalculer chaque condensé et imposer la fermeture des dépendances récursives.
  5. Si la liaison de clé est requise, contrôler kb+jwt, iat, aud, nonce, sd_hash, la clé et la fenêtre temporelle.
  6. Tester les revendications requises absentes, les présentations malformées, la relecture, le transport confidentiel et la rétention limitée.

Parcours de décision opérateur

Commencer par les preuves minimales exigées. Si une donnée n’a pas besoin d’être vue, la rendre divulgable et remettre sa Disclosure séparément. Pour un élément de tableau sensible, construire indépendamment la Disclosure sel-valeur; pour une propriété, construire sel-nom-valeur. Ajouter des leurres seulement si le gain contre le canal auxiliaire justifie la taille. Exiger la liaison de clé uniquement si le profil demande la possession par le présentateur, puis appliquer toute la liste KB-JWT.

Sinon, vérifier signature et chaîne de Disclosures, refuser les revendications de politique manquantes, utiliser un transport confidentiel, limiter le stockage et documenter les limites de corrélation.

Sources