SD-JWT VC vs mdoc (ISO/IEC 18013-5) : formats du portefeuille EUDI comparés

Dernière révision : 5 octobre 2026 · Ne constitue pas un conseil juridique

Un SD-JWT VC est une attestation vérifiable encapsulée dans un JSON Web Token signé dont les revendications peuvent être divulguées une par une. Un mdoc est un document mobile au format ISO/IEC 18013-5, la norme rédigée à l'origine pour les permis de conduire mobiles. L'Architecture and Reference Framework (ARF) du portefeuille EUDI impose les deux formats aux portefeuilles. Il prévoit un troisième format, le W3C Verifiable Credentials Data Model 2.0, à titre optionnel et « destiné uniquement aux EAA non qualifiées ».^[1]

Ce guide compare les deux formats pour les développeurs qui construisent un vérificateur. Il s'appuie sur l'ARF v3.0.0, le texte d'OpenID for Verifiable Presentations (OpenID4VP) 1.0 et le Journal officiel. PID signifie person identification data, soit les données d'identification de la personne.

Ce qu'est un SD-JWT VC

L'ARF décrit les « SD-JWT-based Verifiable Credentials » comme un format de données et des règles de traitement servant à exprimer des attestations vérifiables, où SD-JWT « signifie "Selectively Disclosable JSON Web Token" ».^[1] Il couvre l'encodage JSON, un mécanisme de preuve avec divulgation sélective et un lien optionnel avec l'appareil.^[1]

Dans OpenID4VP, l'identifiant de format est dc+sd-jwt, et une requête désigne le type d'attestation via vct_values.^[4] Voici l'exemple de charge utile émise donné par la spécification, réduit à deux de ses huit empreintes :^[4]

{ "_sd": [ "jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4", "TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo" ], "vct": "https://credentials.example.com/identity_credential", "_sd_alg": "sha-256", "cnf": { "jwk": { "kty": "EC", "crv": "P-256" } } }

Ce qu'est un mdoc (ISO/IEC 18013-5)

ISO/IEC 18013-5 définit les attributs du permis, leur encodage en Concise Binary Object Representation (CBOR), des espaces de noms qui évitent les collisions d'identifiants, un mécanisme de preuve avec divulgation sélective, un lien obligatoire avec l'appareil et l'échange en proximité.^[1]

Seul le modèle de données du permis est propre à la conduite. L'ARF note que tous les autres aspects « sont génériques et peuvent être utilisés pour tout autre type d'attestation, y compris les PID ».^[1]

OpenID4VP décrit ces attestations comme « encodées en CBOR et sécurisées au moyen de COSE_Sign1 » et leur attribue l'identifiant de format mso_mdoc. Une requête désigne le type de document via doctype_value.^[4]

Fonctionnement de la divulgation sélective dans chaque format

La divulgation sélective permet à l'utilisateur de partager certains attributs et de masquer les autres, tandis que le vérificateur contrôle toujours la signature de l'émetteur. eIDAS 2 impose aux portefeuilles de la rendre possible.^[6] L'ARF qualifie le mécanisme SD-JWT d'« empreintes salées » et indique qu'il « est conceptuellement identique au mécanisme utilisé dans le même but dans [ISO/IEC 18013-5] ».^[1]

Un seul mécanisme, deux encodages.^[1][4]

Dans l'exemple ci-dessus, le tableau _sd contient des condensats SHA-256. Chaque divulgation est un tableau composé d'une valeur aléatoire, du nom de la déclaration et de la valeur de la déclaration. Pour le prénom, il s'agit de ["2GLC42sKQveCfGfryNRN9w", "given_name", "John"], et son hachage est le premier condensat de la liste. Le vérificateur hache chaque divulgation qu'il reçoit et recherche le condensat dans la charge utile signée.^[4]

Les déclarations sont adressées différemment. Pour un justificatif JSON, un chemin de déclaration est une liste de clés, par exemple ["address", "street_address"]. Pour un mdoc, le chemin « contient deux éléments de type chaîne » : l'espace de noms et l'identifiant de l'élément de données, par exemple ["org.iso.18013.5.1", "first_name"].^[4]

Liaison de clé et engagement de l'appareil

La liaison à l'appareil rattache un justificatif à des clés détenues dans le portefeuille de l'utilisateur, de sorte qu'il ne peut pas être cloné. Le vérificateur la contrôle en demandant au portefeuille de signer des données aléatoires fraîches avec la clé privée qui correspond à la clé publique contenue dans le justificatif.^[1] Les noms diffèrent : « Dans [ISO/IEC 18013-5], on parle de "mdoc authentication". Dans [SD-JWT VC], on parle de "key binding". »^[1]

La liaison à l'appareil est obligatoire pour les PID dans les deux formats.^[1][4]

Pour SD-JWT VC, la règle d'OpenID4VP est stricte. Lorsque require_cryptographic_holder_binding vaut true, la valeur par défaut, le portefeuille « DOIT renvoyer un SD-JWT » accompagné d'un Key Binding JWT. La revendication nonce doit être égale au nonce de votre requête, et aud doit être égale à votre identifiant client (Client Identifier), sauf via la Digital Credentials API, où elle doit être égale à votre origine préfixée par origin:.^[4]

L'engagement de l'appareil (device engagement) est propre à mdoc. Dans un flux de proximité, l'utilisateur affiche un code QR ou présente une balise NFC. Cet engagement contient ce dont le lecteur a besoin pour ouvrir une connexion NFC, Bluetooth Low Energy ou Wi-Fi Aware et y établir un canal authentifié et chiffré, sans liaison internet entre les deux.^[1]

Une présentation de proximité avec mdoc (ISO/IEC 18013-5), version simplifiée.^[1]

Ce que voit l'utilisateur :

Protocoles de présentation : OpenID4VP, ISO/IEC 18013-7 et proximité

L'ARF liste ce que gère un portefeuille : ISO/IEC 18013-5 en proximité, et OpenID4VP ou ISO/IEC 18013-7 à distance.^[1]

Quel protocole transporte quel format, selon l'ARF.^[1]

Les attestations SD-JWT VC « ne peuvent pas être utilisées dans les présentations de proximité ». ISO/IEC 18013-7 « ne peut être utilisée que pour demander et présenter des attestations au format conforme à [ISO/IEC 18013-5] ». OpenID4VP « ne convient qu'aux flux de transaction de présentation à distance » et transporte les deux formats.^[1] OpenID4VP 1.0 est devenue une Final Specification le 10 juillet 2025.^[5]

L'ARF ne recommande pas les schémas d'URI personnalisés entre appareils, car ces flux « sont vulnérables aux attaques par hameçonnage et par relais ». Il désigne la Digital Credentials API comme alternative.^[1] Cette API est encore un projet du W3C, et Chrome 141 l'active par défaut.^[9][10] L'ISO indique que la spécification technique de 2024 de la norme 18013-7 est annulée et remplacée, et qu'une troisième édition est en cours d'élaboration. Vérifiez donc quelle édition votre code cible.^[7][8] Les détails des requêtes figurent dans le guide du vérificateur OpenID4VP.

Ce que le règlement d'exécution (UE) 2026/1731 exige pour le PID

La première règle sur les formats du PID, le règlement d'exécution (UE) 2024/2977, disposait que le PID « est délivré dans deux formats » : ISO/IEC 18013-5:2021 et le Verifiable Credentials Data Model 1.1.^[2][3] L'acte modificatif de juillet 2026 a remplacé cette phrase. Désormais, le PID « est délivré conformément aux normes énoncées à l'annexe II du règlement d'exécution (UE) 2024/2979, points 5 (format SD-JWT VC) et 6 (format ISO/IEC-mdoc) ».^[2]

1. 4 décembre 2024Première règle2024/2977 : 18013-5 et VCDM 1.1.
2. 22 juillet 2026Modification2026/1731 : SD-JWT VC et mdoc.
3. 23 juillet 2026ARF v3.0.0Aligné sur les actes modificatifs.
4. 24 décembre 2026Échéance des portefeuillesUn portefeuille par État membre.
5. 11 août 2028PortraitL'exigence relative au portrait s'applique, sauf refus explicite de l'utilisateur, le cas échéant.

Comment le droit sur les formats des PID a évolué.^[1][2][3][6]

Le même acte fixe deux profils de présentation dans son annexe au règlement d'exécution (UE) 2024/2982 : un « profil ISO/IEC-mdoc » et un « profil OpenID4VC-HAIP ».^[2]

• Transmettez votre certificat d'enregistrement : un élément de verifier_info « inclut le certificat d'enregistrement ».^[2]
• Utilisez votre certificat d'accès comme certificat feuille avec le préfixe d'identifiant client x509_hash.^[2]
• Suivez « l'annexe C de la norme ISO/IEC 18013-7:2025 » pour mdoc via la Digital Credentials API.^[2]

L'enregistrement est traité dans le guide de la partie utilisatrice du portefeuille EUDI, et le calendrier dans Échéances du portefeuille EUDI pour 2026 et 2027.

SD-JWT VC ou mdoc (ISO/IEC 18013-5) : tableau comparatif

Source : l'ARF, sauf la ligne PID (règlement d'exécution 2026/1731) et les deux dernières lignes (OpenID4VP 1.0).^[1][2][4]

Aux États-Unis, les permis de conduire mobiles reposent sur ISO/IEC 18013-5 pour la proximité.^[7][8] La solution européenne de vérification de l'âge désigne la preuve à divulgation nulle de connaissance comme mécanisme de présentation obligatoire, « avec la présentation mDoc simple comme solution de repli ».^[13] L'EVO Wallet de la Moldavie documente OpenID4VP 1.0 avec un mdoc ISO/IEC 18013-5, profilé selon HAIP 1.0.^[11]

Quel format une partie utilisatrice doit prendre en charge

Les instances de portefeuille gèrent les deux formats, et le PID est délivré dans les deux.^[1][2] Les textes consultés pour ce guide ne contiennent aucune ligne qui oblige une partie utilisatrice à demander les deux. La lecture pratique : un vérificateur à distance peut demander l'un ou l'autre, et un lecteur sans connexion internet a besoin de mdoc, le seul format qui fonctionne en proximité.^[1]

Le Digital Credentials Query Language (DCQL) d'OpenID4VP permet à une même requête de contenir une requête dc+sd-jwt et une requête mso_mdoc côte à côte. La spécification donne un exemple d'une telle requête.^[4] Selon l'ARF, la partie utilisatrice vérifie la signature de l'émetteur à l'aide d'une ancre de confiance issue d'une liste de confiance ou d'une liste des entités de confiance, contrôle la révocation au moyen d'une liste de statuts ou d'une liste de révocation, et vérifie la liaison à l'appareil.^[1]

Au titre d'eIDAS 2, règlement (UE) 2024/1183, chaque État membre doit fournir au moins un portefeuille d'ici le 24 décembre 2026. Les parties utilisatrices privées tenues de recourir à l'authentification forte de l'utilisateur doivent l'accepter à la demande de l'utilisateur d'ici le 24 décembre 2027, les micro et petites entreprises étant exemptées.^[6] Le statut par pays figure dans le suivi du lancement du portefeuille EUDI.

Bibliothèques et outils de test

Les sources de ce guide ne citent aucune bibliothèque open source, cette section n'en cite donc aucune. Elles indiquent en revanche où tester et quoi vérifier dans la bibliothèque que vous choisissez.

• Exécutez les tests de conformité sur conformance.eudi.dev, cités dans les notes de version de l'ARF v3.0.0.^[1]
• Lisez la documentation de l'implémentation de référence sur docs.eudi.dev.^[1]
• Étudiez un vérificateur publié : la Banque nationale de Moldavie a mis à disposition des institutions financières un vérificateur de démonstration avec son code source.^[12]
• Vérifiez que la bibliothèque suit HAIP, et pas seulement les spécifications de base.^[1]
• Vérifiez quelle édition de la norme ISO/IEC 18013-7 elle implémente.^[2][8]

Comment Didit vous aide pour la vérification par portefeuille EUDI

L'acceptation du portefeuille EUDI arrive bientôt sur Didit : elle figure dans notre feuille de route, alignée sur le calendrier du portefeuille EUDI, dans le même workflow que celui que vous utilisez aujourd'hui. Vous pouvez dès maintenant vérifier des personnes à distance.

• Cinq eID nationales fonctionnent aujourd'hui dans Didit via les portefeuilles d'identité numérique : MitID, BankID Sweden, Finnish Trust Network, Smart-ID et Mobile-ID. Voir vérification eID.
• Pour tous les autres, c'est la vérification de documents avec lecture de la puce NFC, détection du vivant et comparaison faciale. Un contrôle KYC complet coûte $0.33.
• Le filtrage AML s'exécute dans le même parcours pour $0.20.

La documentation des portefeuilles explique comment les eID sont activées pays par pays.

Questions fréquentes

Sources

1. Architecture and Reference Framework v3.0.0, eu-digital-identity-wallet sur GitHub, version publiée le 23 juillet 2026.
2. Règlement d'exécution (UE) 2026/1731 de la Commission, EUR-Lex, Journal officiel du 22 juillet 2026.
3. Règlement d'exécution (UE) 2024/2977 de la Commission relatif aux données d'identification personnelle, EUR-Lex, Journal officiel du 4 décembre 2024.
4. OpenID for Verifiable Presentations 1.0, OpenID Foundation, spécification finale.
5. OpenID for Verifiable Presentations 1.0 Final Specification Approved, OpenID Foundation, 10 juillet 2025.
6. Règlement (UE) 2024/1183 (eIDAS 2), EUR-Lex, Journal officiel du 30 avril 2024.
7. Série ISO/IEC 18013, permis de conduire mobile, page de la norme sur le site de l'ISO.
8. ISO/IEC 18013-7, page de la norme sur le site de l'ISO.
9. Digital Credentials, projet du W3C.
10. Digital Credentials API shipped, Chrome for Developers.
11. Guide développeur EVO Wallet, Gouvernement de Moldavie, egov4dev.
12. Vérificateur de démonstration de la BNM, Gouvernement de Moldavie, egov4dev.
13. Solution européenne de vérification de l'âge, portail technique, ageverification.dev.

SD-JWT VC et mdoc (ISO/IEC 18013-5) sont deux encodages d'une même promesse : des attributs signés que l'utilisateur contrôle. Découvrez l'approche de Didit pour l'acceptation des portefeuilles sur la page de la solution portefeuille EUDI, et l'ensemble des schémas nationaux dans Schémas eID par pays.