Le wallet européen ne reposera pas sur un format unique de justificatif numérique. Il combinera plusieurs standards, dont mdoc et SD-JWT VC, pour couvrir deux réalités très différentes : le contrôle en face à face et les parcours en ligne. Ce choix technique conditionne l’interopérabilité, la simplicité d’usage et la confiance dans l’identité numérique.
Le wallet européen doit gérer des situations très différentes. Dans un cas, la personne est physiquement devant un agent, un commerçant ou un terminal. Dans l’autre, la preuve circule à distance dans un parcours web ou mobile. Le cadre EUDI sépare d’ailleurs ces deux flux. Il associe les présentations de proximité au standard ISO/IEC 18013-5 et les présentations à distance à OpenID4VP.
Le wallet n’est donc pas un simple coffre-fort de cartes numériques. C’est un outil d’échange de preuves qui doit rester lisible pour les administrations, les entreprises et les systèmes web modernes.
mdoc, le format pensé comme un document officiel mobile
Le format mdoc vient du monde du permis de conduire mobile. La norme ISO/IEC 18013-5 a été conçue à l’origine pour ce cas d’usage. Elle décrit les échanges entre le document mobile, le lecteur et l’infrastructure de l’autorité émettrice. L’ISO le dit clairement dans le résumé de la norme.
Dans le cadre EUDI, ce format est repris pour bien plus que le permis. Le texte précise que la norme 18013-5 a été conçue pour le mDL (mobile driving licence), mais que les mécanismes sont génériques et peuvent être utilisés pour d’autres attestations, y compris des preuves d’identité. Le format de données repose sur le CBOR, un encodage binaire compact, et il inclut un mécanisme de preuve qui permet déjà la divulgation sélective.
Concrètement, mdoc est très à l’aise dans les usages de proximité. Le cadre EUDI décrit un scénario simple. Le wallet affiche un QR code ou présente un tag NFC. Le vérificateur se connecte ensuite via NFC, BLE ou Wi-Fi Aware pour récupérer la preuve demandée. Ce mode est utile quand il n’y a pas de connexion internet ou quand un échange local est préférable.
SD-JWT VC, le format taillé pour le web et les API
SD-JWT VC part d’une autre logique. Ici, le format est pensé pour le monde web. Il repose sur JSON et JWT, deux briques déjà largement utilisées dans les architectures web. Le draft IETF en cours de finalisation explique que SD-JWT VC définit un format et des règles de validation pour exprimer des justificatifs numériques avec des payloads JSON, avec ou sans divulgation sélective, sur la base de SD-JWT.
La brique de base, SD-JWT, est désormais normalisée dans la RFC 9901. Cette RFC formalise la divulgation sélective des données dans un JWT. Elle décrit aussi le mécanisme de “key binding”, qui permet de lier la présentation à la clé du détenteur. En clair, cela limite le risque de copie et de réutilisation frauduleuse d’un justificatif par un tiers.
Autre point notable, un justificatif SD-JWT VC peut contenir des données sélectivement révélables, mais ce n’est pas une obligation absolue dans tous les cas. Le format permet de couvrir plusieurs profils de preuves. Cette souplesse plaît aux intégrateurs web, mais elle impose aussi des profils d’interopérabilité stricts si chaque acteur veut éviter de parler un dialecte différent. Le cadre EUDI insiste sur ce besoin de profilage pour garantir l’interopérabilité.
La vraie différence entre les deux formats
La différence n’est pas seulement technique. Elle est surtout liée au contexte d’usage.
Le format mdoc se comporte comme un document officiel mobile. Il est très naturel dans une interaction de proximité. Il a été construit pour des scénarios de contrôle sur place et il reste très fort dans cette logique.
Le format SD-JWT VC se comporte comme un justificatif web. Il s’intègre plus facilement dans un parcours en ligne, dans une application ou dans un site qui dialogue avec un wallet via des standards web.
Le cadre EUDI le reflète très bien. Il associe ISO/IEC 18013-5 aux flux de proximité et OpenID4VP aux flux distants. Il précise aussi que les attestations SD-JWT VC sont demandées et présentées via OpenID4VP dans l’écosystème EUDI.
OpenID4VP, le protocole qui fait circuler les preuves
Quant à OpenID4VP, il ne s’agit pas d’un format de justificatif. C’est le protocole de présentation. Il sert à demander une preuve au wallet et à recevoir la réponse.
La spécification OpenID4VP 1.0 explique qu’un vp_token peut contenir une ou plusieurs présentations, et même des présentations de formats différents dans une même transaction. La spec cite explicitement plusieurs formats possibles, dont mdoc et SD-JWT VC. Cela permet donc à un même wallet de parler plusieurs formats sans changer d’expérience utilisateur.
Pour les équipes produit et les équipes techniques, cela change la lecture du sujet. Le débat ne doit pas porter sur un format unique “gagnant”. La vraie question porte sur l’orchestration des bons formats selon les cas d’usage.
Un exemple simple qui parle à tout le monde
Prenez un hôtel. Lors d’un check-in en ligne, le site de réservation peut demander une preuve d’identité à distance. Le wallet répond dans un flux web, typiquement via OpenID4VP, avec un justificatif SD-JWT VC qui ne révèle que les données nécessaires.
À l’arrivée sur place, le réceptionniste peut contrôler une preuve en proximité. Le wallet peut alors utiliser un flux de type mdoc via QR code ou NFC. Le besoin métier reste le même. La mécanique technique change parce que le contexte change. C’est précisément pour cela que l’EUDI Wallet embarque plusieurs formats.
Ce que cela implique pour les acteurs français
Le sujet n’est pas théorique. Il touche déjà les choix d’architecture des banques, assureurs, opérateurs télécoms, plateformes de services et acteurs publics. Ceux qui pensent encore en termes de “document PDF signé” passent à côté du virage. Le wallet européen impose une logique de preuves vérifiables, de divulgation minimale et de protocoles standardisés.
Le vrai risque n’est pas la complexité des standards. Le vrai risque est de sous-estimer le travail d’intégration, de profilage et de gouvernance. Les formats existent. Les protocoles avancent. L’enjeu devient maintenant l’interopérabilité réelle entre wallets, émetteurs et vérificateurs. C’est là que se jouera la confiance.
