Guide du vérificateur OpenID4VP : accepter le portefeuille EUDI

Dernière révision : 5 octobre 2026 · Ceci n'est pas un avis juridique

OpenID4VP permet à un site web ou à une application de demander à un portefeuille de prouver un élément concernant une personne, comme un nom ou une date de naissance. Le vérificateur indique les attestations et les attributs qu'il souhaite. L'utilisateur donne son accord dans le portefeuille, puis le portefeuille renvoie une présentation que le vérificateur contrôle de manière cryptographique. Selon les termes mêmes de la spécification, elle « définit un protocole pour demander et présenter des Credentials ».^[1]

Ce guide s'adresse aux développeurs qui construisent un vérificateur OpenID4VP pour le portefeuille EUDI : l'objet de requête, DCQL, les modes de réponse, les flux selon l'appareil, les contrôles SD-JWT VC et mdoc, les règles HAIP dans le droit de l'UE, les erreurs courantes et les environnements de test.

OpenID4VP en termes simples

OpenID4VP reprend la forme d'une requête d'autorisation OAuth 2.0. Le vérificateur demande le type de réponse vp_token, et une réponse réussie doit inclure un paramètre vp_token contenant les présentations.^[1] Il n'y a ni code ni jeton d'accès à échanger : les données arrivent dans la réponse.

Le portefeuille authentifie la partie utilisatrice, vérifie qu'elle ne demande pas plus que ce qu'elle a enregistré, recueille l'accord de l'utilisateur et signe la présentation. La partie utilisatrice vérifie ensuite la signature de l'émetteur, le statut de révocation et la liaison à l'appareil.^[3] Les données d'identification personnelle (PID) sont émises dans deux formats, SD-JWT VC et ISO/IEC mdoc. Les deux utilisent des empreintes salées, ce qui permet à l'utilisateur de partager certains attributs et de masquer les autres.^[5][3]

1. 10 juillet 2025Spécification finaleOpenID4VP 1.0 approuvé.
2. 22 juillet 2026PublicationCIR 2026/1731 (adopté le 15 juillet 2026) au Journal officiel.
3. 23 juillet 2026ARF v3.0.0Version actuelle de l'architecture.
4. 24 décembre 2026PortefeuillesAu moins un par État membre.
5. 24 décembre 2027AcceptationParties utilisatrices privées réglementées.

De la spécification finale à la date d'acceptation par le secteur privé.^[2][3][4][5]

Fonctionnement d'un échange avec un vérificateur OpenID4VP

OpenID4VP publie une conception de référence pour le mode de réponse direct_post. Dans ce mode, le portefeuille envoie la réponse par POST à un point de terminaison serveur au lieu de la faire transiter par le navigateur.^[1]

La conception de référence direct_post d'OpenID4VP 1.0, section 13.3, simplifiée.^[1]

• Générez un nonce d'« au moins 16 octets nouveaux et aléatoires au sens cryptographique » pour chaque requête.
• Envoyez au portefeuille le request-id issu du point de terminaison de réponse, en tant que state.
• Renvoyez une URI de redirection avec un nouveau response_code une fois que le portefeuille a effectué son envoi.
• Récupérez le VP Token avec le transaction-id et ce code, puis vérifiez le nonce.

Le response_code empêche la fixation de session, où un attaquant relaie votre requête vers le portefeuille d'une victime. La spécification précise qu'il n'aide pas entre appareils et recommande des mécanismes supplémentaires dans ce cas.^[1]

L'objet de requête OpenID4VP et les identifiants client

Le client_id commence par un préfixe d'identifiant client (Client Identifier Prefix) qui indique au portefeuille comment authentifier le vérificateur.^[1] Les requêtes volumineuses sont transmises par référence : le portefeuille récupère l'objet de requête signé depuis une request_uri. Pour les codes QR, la spécification recommande direct_post avec request_uri, car la requête « pourrait ne pas tenir dans un code QR ».^[1]

Préfixes d'identifiant client, OpenID4VP 1.0, section 5.9.^[1]

Pour les vérificateurs EUDI, le droit de l'Union impose le préfixe : le certificat feuille « destiné à être utilisé avec le préfixe d'identifiant client x509_hash est un certificat d'accès de partie utilisatrice tel que spécifié dans ETSI TS 119 475 », et un élément de verifier_info « comprend le certificat d'enregistrement ».^[5]

Requêtes DCQL : demandez ce que vous avez enregistré

Le Digital Credentials Query Language (DCQL) est la requête JSON qui désigne les attestations et les attributs que vous demandez. Elle contient un tableau credentials obligatoire et un tableau credential_sets facultatif. Chaque requête d'attestation exige un id, un format et un objet meta.^[1] L'exemple SD-JWT VC de la spécification :^[1]

{ "credentials": [ { "id": "my_credential", "format": "dc+sd-jwt", "meta": { "vct_values": [ "https://credentials.example.com/identity_credential" ] }, "claims": [ {"path": ["last_name"]}, {"path": ["first_name"]}, {"path": ["address", "street_address"]} ] } ] }

Pour un mdoc, le format est mso_mdoc et meta contient un doctype_value.^[1] Pour le PID, remplacez par son type et ses noms d'attributs. Les attributs obligatoires du PID sont le nom de famille, le prénom, la date de naissance, le lieu de naissance et la nationalité.^[7]

• require_cryptographic_holder_binding vaut true par défaut. Conservez cette valeur : elle oblige le portefeuille à renvoyer une preuve de liaison de clé.^[1]
• trusted_authorities filtre seulement ce que le portefeuille propose. Les vérificateurs « doivent vérifier par eux-mêmes que l'émetteur d'une présentation reçue est de confiance ».^[1]
• Les parties utilisatrices « ne demandent pas aux utilisateurs de fournir des données autres que » celles qu'elles ont enregistrées, et le portefeuille le vérifie.^[4][3]

Modes de réponse OpenID4VP

Le mode de réponse détermine comment le VP Token est renvoyé. La valeur par défaut pour vp_token est fragment, dans le fragment de l'URI de redirection.^[1]

Modes de réponse dans OpenID4VP 1.0.^[1]

Avec direct_post, response_uri est obligatoire et redirect_uri doit être absent, sinon le portefeuille renvoie invalid_request.^[1] L'EVO Wallet de la Moldavie, par exemple, documente OpenID4VP 1.0 avec direct_post.jwt dans un flux sur le même appareil, des mdoc ISO/IEC 18013-5 profilés selon OpenID4VC HAIP 1.0 et une IETF Token Status List pour la révocation.^[11]

Même appareil, inter-appareils et Digital Credentials API

L'ARF énumère les combinaisons à distance prises en charge : OpenID4VP associé à un mécanisme de transmission fondé sur des redirections et des schémas d'URI personnalisés ; OpenID4VP ou ISO/IEC 18013-7 associé à la Digital Credentials API du W3C ; et, de manière facultative, ISO/IEC 18013-7 avec des redirections et des schémas d'URI personnalisés.^[3]

Trois façons dont un portefeuille reçoit une requête OpenID4VP.^[3][1][10]

L'ARF indique que les schémas d'URI personnalisés sont « déconseillés pour les flux inter-appareils » et désigne la Digital Credentials API comme alternative.^[3] Via l'API, le portefeuille obtient l'origine du vérificateur telle qu'authentifiée par le navigateur, « ce qui est important pour la résistance à l'hameçonnage ».^[1] La spécification du W3C est encore à l'état de projet.^[9] Ce que l'utilisateur voit sur un téléphone :

Vérifier une présentation SD-JWT VC étape par étape

Une présentation SD-JWT VC contient le JWT signé par l'émetteur, les divulgations révélées par l'utilisateur et un Key Binding JWT. Le vérificateur « DOIT valider chaque présentation vérifiable individuelle » et rejeter toute présentation dont le nonce est incorrect.^[1]

Les contrôles du vérificateur sur une présentation SD-JWT VC.^[1][3]

Signature de l'émetteur. L'ARF la place en premier parmi les contrôles de la partie utilisatrice. Les ancres de confiance proviennent des listes de confiance (ETSI TS 119 612) et des listes d'entités de confiance (ETSI TS 119 602).^[3]

Divulgations. Le contenu signé contient un tableau _sd de condensés. Chaque divulgation se compose d'un sel, d'un nom d'attribut et d'une valeur, par exemple ["eluV5Og3gSNII8EYnsxA_A", "family_name", "Doe"].^[1] Hachez chacune et retrouvez son condensé. En l'absence de correspondance, l'émetteur ne l'a pas signée.

Key Binding JWT. Lorsque le lien avec le détenteur est exigé, le portefeuille « DOIT renvoyer un SD-JWT avec un Key Binding JWT ». Son nonce doit être égal au nonce de votre requête et son aud à votre Client Identifier, ou, via la Digital Credentials API, à votre origine précédée de origin:.^[1] L'exemple de la spécification :

{ "nonce": "n-0S6_WzA2Mj", "aud": "x509_san_dns:client.example.org", "iat": 1709838604, "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4" }

Révocation. La partie utilisatrice vérifie que le fournisseur « n'a pas révoqué le PID ou l'attestation ».^[3] L'EVO Wallet de la Moldavie, par exemple, documente une IETF Token Status List à cet effet.^[11]

Les présentations mdoc via l'ISO/IEC 18013-7, en bref

Pour un mdoc, le VP Token contient un DeviceResponse de l'ISO/IEC 18013-5 encodé en base64url, qui « contient une signature ou un MAC sur le SessionTranscript », y compris une structure de handover OpenID4VP.^[1] Ce handover lie le mdoc à votre requête, comme le nonce et l'audience lient un SD-JWT VC.

Notre comparatif SD-JWT VC et mdoc explique quand chaque format convient.

Ce que le profil HAIP ajoute pour les vérificateurs EUDI

Le High Assurance Interoperability Profile (HAIP) restreint les options d'OpenID4VP. L'ARF l'impose déjà pour l'émission et précise que son utilisation « est nécessaire pour garantir l'interopérabilité ».^[3] Pour la présentation, le CIR 2026/1731 définit un « profil OpenID4VC-HAIP » et un « profil ISO/IEC-mdoc ».^[5]

Le certificat d'enregistrement « décrit l'utilisation prévue de la partie utilisatrice et indique les attributs » qu'elle a enregistrés. Le règlement sur l'enregistrement s'applique à partir du 24 décembre 2026.^[6] La date du 11 août 2028 ne concerne que le contrôle de ce certificat par le portefeuille, pas l'enregistrement.^[5] L'Allemagne le résume ainsi : une organisation « reçoit un certificat d'accès et d'enregistrement pour l'organisation et le cas d'usage ».^[12] Notre guide de la partie utilisatrice du portefeuille EUDI traite l'enregistrement en détail.

Erreurs courantes lors de la création d'un vérificateur OpenID4VP

Le portefeuille est lui aussi facultatif : l'accès « n'est en aucune manière restreint ou rendu désavantageux » pour les personnes qui ne l'utilisent pas. Votre vérificateur coexiste donc avec un autre parcours.^[4]

Ressources de test

Commencez par les logiciels de référence et les tests de conformité avant de tester avec les portefeuilles nationaux.

• Exécutez les tests de conformité sur conformance.eudi.dev.^[3]
• Consultez la documentation de l'implémentation de référence sur docs.eudi.dev. Il s'agit de documentation, pas de tests.^[3]
• Étudiez le vérificateur de démonstration de la Banque nationale de Moldavie et son code source.^[13]
• Consultez le projet de spécification de l'API Digital Credentials avant de vous appuyer sur le parcours navigateur.^[9]

Pour les dates qui fondent votre plan de test, consultez les échéances du portefeuille EUDI pour 2026 et 2027.

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

L'acceptation du portefeuille EUDI arrive bientôt sur Didit. Elle figure sur notre feuille de route, alignée sur le calendrier du portefeuille EUDI, dans le même parcours que celui que vous utilisez aujourd'hui. En attendant, 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.
• Si une personne n'a pas d'eID, le parcours bascule vers la vérification de documents avec lecture de la puce NFC, détection du vivant et comparaison faciale, configurées par pays. Une vérification KYC complète coûte $0.33.
• Le filtrage AML s'exécute dans le même parcours pour $0.20.

Vous conservez vos obligations de partie utilisatrice. La documentation des portefeuilles montre comment les eID sont activées par pays.

Questions fréquentes

Sources

1. OpenID for Verifiable Presentations 1.0, OpenID Foundation, spécification finale.
2. OpenID for Verifiable Presentations 1.0 Final Specification Approved, OpenID Foundation, 10 juillet 2025.
3. Architecture and Reference Framework v3.0.0, eu-digital-identity-wallet sur GitHub, publication du 23 juillet 2026.
4. Règlement (UE) 2024/1183 (eIDAS 2), EUR-Lex, Journal officiel du 30 avril 2024.
5. Règlement d'exécution (UE) 2026/1731 de la Commission, EUR-Lex, Journal officiel du 22 juillet 2026.
6. Règlement d'exécution (UE) 2025/848 de la Commission relatif à l'enregistrement des parties utilisatrices de portefeuille, EUR-Lex, Journal officiel du 7 mai 2025.
7. 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.
8. ISO/IEC 18013-7, page de la norme ISO.
9. Digital Credentials, projet du W3C.
10. Digital Credentials API shipped, Chrome for Developers.
11. Guide du développeur EVO Wallet, gouvernement de Moldavie, egov4dev.
12. FAQ sur le portefeuille EUDI, eudi-wallet.gov.de.
13. Vérificateur de démonstration BNM, gouvernement de Moldavie, egov4dev.

OpenID4VP est la partie du portefeuille EUDI que les développeurs manipulent le plus, et elle est assez stable pour développer dessus. Découvrez comment Didit aborde l'acceptation des portefeuilles sur la page de la solution portefeuille EUDI, et la vue d'ensemble dans notre présentation d'eIDAS 2.