SD-JWT VC et OpenID4VP : les protocoles derrière l'EUDI Wallet

On parle beaucoup de l’EUDI Wallet au niveau politique et organisationnel : mise à disposition par les États membres d’ici fin 2026, obligations d’enregistrement, délais d’acceptation. Mais quiconque veut effectivement accepter le wallet se trouve tôt ou tard face à une question technique : comment vérifier concrètement qu’un attribut présenté est authentique, valide et suffisant pour mon usage ? Cet article se penche sur le versant de la vérification et sur les briques qui s’y assemblent.

Trois formats, une interaction

L’Architecture and Reference Framework (ARF), désormais en version 2.x, fixe les standards techniques. Pour les parties utilisatrices, trois d’entre eux sont centraux.

SD-JWT VC (Selective Disclosure JWT Verifiable Credential) est un format d’attestation qui permet la divulgation sélective. L’émetteur signe un faisceau d’attributs, mais de telle façon que la personne utilisatrice puisse en divulguer certains sans révéler les autres. Techniquement, cela passe par des condensats salés (salted hashes) : chaque attribut est haché individuellement, et la signature porte sur les condensats. Qui montre un attribut fournit le texte en clair et le sel correspondants, le reste demeure caché, la signature reste vérifiable.

ISO/IEC 18013-5 (mdoc) est le format issu du permis de conduire mobile, utilisé en parallèle pour certaines attestations dans le contexte EUDI. Une partie utilisatrice devrait pouvoir traiter les deux formats, car les États membres ne procèdent pas partout de manière identique.

OpenID for Verifiable Presentations (OpenID4VP) est le protocole par lequel se déroule la présentation. Il définit comment une partie utilisatrice formule une requête (quels attributs, à quelle fin) et comment le wallet renvoie la réponse signée.

Ce que la divulgation sélective change en pratique

L’exemple courant est la vérification de l’âge. Au lieu de transmettre la date de naissance complète, le wallet peut ne divulguer que l’attribut dérivé « plus de 18 ans ». Pour la partie utilisatrice, cela veut dire formuler ses requêtes de sorte qu’elle obtienne exactement le prédicat dont elle a besoin, et non le jeu de données complet qui se trouve derrière. La minimisation des données n’est pas ici une idée de protection ajoutée après coup, mais intégrée au protocole.

La partie difficile : la confiance, pas la validité

Vérifier une signature est la tâche facile. La difficile est la question qui se cache derrière : l’émetteur qui a signé cet attribut est-il seulement habilité et authentique ? C’est là qu’interviennent les listes de confiance. L’UE et les États membres tiennent des registres au moyen desquels une partie utilisatrice établit de manière fiable si un wallet et ses émetteurs sont authentiques et agréés. Sans ce raccordement, on vérifie certes une signature correcte, mais on ne sait pas si l’identité qui se trouve derrière est digne de confiance.

Le sens inverse compte tout autant : la partie utilisatrice elle-même doit s’enregistrer auprès d’un registre national avant la première utilisation, en indiquant quels attributs elle demande et à quelle fin. Seul cet enregistrement constitue la base juridique permettant de demander des données.

Pourquoi miser sur les standards en vaut la peine

Miser sur les formats et protocoles ouverts plutôt que sur des adaptateurs propriétaires maintient à portée les wallets des différents États membres, sans devoir réintégrer pays par pays. Dans notre module Datargo ID, ce rôle de partie utilisatrice est le fil rouge, de l’authentification unique (SSO) au parcours EUDI. Le cœur technique vaut cependant indépendamment de l’outil : qui sait traiter SD-JWT VC, mdoc et OpenID4VP et raccorde correctement les listes de confiance est armé pour la vérification, quel que soit l’État membre dont provient le wallet.

La mise à disposition du wallet est une échéance politique. Mettre en place proprement la vérification est une tâche technique, et elle commence par la compréhension de ces trois briques.