Les spécifications techniques de l’annexe C de la norme ISO/IEC 18013-7: 2025 s’appliquent.
Les spécifications techniques des paragraphes 4.1, 4.2, 5 et 6 de la norme ETSI TS 119 472-2 V1.2.1 (2026-03) s’appliquent moyennant les adaptations suivantes, notamment l’insertion d’un nouveau paragraphe 4.3:
1) 1. Champ d’application
— Le présent document spécifie deux profils de protocoles permettant aux parties utilisatrices (RP) de demander des EAAP ou des données d’identification personnelle (PID) au portefeuille européen d’identité numérique, et au portefeuille européen d’identité numérique d’envoyer à la RP les EAAP/PID demandées. Chacun de ces profils prend en charge deux mécanismes de transmission, à savoir: avec médiation d’API et sans médiation d’API, comme suit:
a) Un profil se fonde sur:
— ISO/IEC 18013-5 [10] pour le mécanisme de transmission sans médiation d’API uniquement, et
— sur l’annexe C de la norme ISO/IEC 18013-7 [16] pour le mécanisme de transmission avec médiation d’API.
Ce profil est appelé profil ISO/IEC-mdoc et il est défini au paragraphe 5 du présent document.
b) Un profil se fonde sur:
OpenID4VC-HAIP [11] à la fois pour les mécanismes de transmission avec médiation d’API et sans médiation d’API, comme suit:
— les sections 5, 5.1, 5.3, 7 et 8 de [11] pour la transmission via Redirects ou un mécanisme de transmission sans médiation d’API, et
— les sections 5, 5.2, 5.3, 7 et 8 de [11] pour la transmission par un mécanisme de transmission avec médiation d’API.
Ce profil est appelé profil OpenID4VC-HAIP et il est défini au paragraphe 6 du présent document.
2) 2.1. Références normatives
— [15] ISO 639: 'Language code'
— [16] ISO/IEC 18013-7: 2025 'Personal identification – ISO – compliant driving licence – Part 7: Mobile driving licence (mDL) add-on functions' (Identification des personnes – Permis de conduire conforme à l’ISO – Partie 7: Fonctionnalités supplémentaires pour permis de conduire sur téléphone mobile).
3) 4.1. EAAP implementation based on SD-JWT VC
— EAAP-SD-JWT VC-04: vide.
4) 4.2. EAAP implementation based on ISO/IEC-mdoc
— EAAP-ISO/IEC-mdoc-01: vide.
— Remarque 2: vide.
— EAAP-ISO/IEC-mdoc-02: vide.
5) 4.3. EAAP implementation with mediating API
— EAAP-API-GEN-01: le portefeuille européen d’identité numérique prend en charge une API de médiation qui accepte les deux protocoles définis au paragraphe 5.2 du [11] et à l’annexe C du [16].
— REMARQUE: lorsque l’appareil sur lequel le portefeuille européen d’identité numérique est installé ne prend pas en charge les deux protocoles, cette exigence ne peut pas être satisfaite, ce qui entraîne une non-conformité due au fait que les systèmes d’exploitation et navigateurs sous-jacents ne mettent pas en œuvre les caractéristiques d’interopérabilité nécessaires.
— EAAP-API-GEN-02: le portefeuille européen d’identité numérique prend en charge une API de médiation au moins pour les types de PID et d’EAA enregistrés dans le catalogue de programmes tel que défini dans le règlement d’exécution (UE) 2025/1569, et au moins pour tous les formats définis à l’annexe II du règlement d’exécution (UE) 2024/2979.
— REMARQUE 1: lorsque le système d’exploitation, le navigateur ou les API de médiation sous-jacents, ou toute autre couche technique échappant au contrôle du portefeuille européen d’identité numérique restreint, filtre, présélectionne ou limite d’une autre manière les formats de justificatifs d’identité, ainsi que les types de PID et d’EAA enregistrés dans le catalogue des de programmes, cette exigence ne peut être satisfaite. Lorsqu’une telle restriction empêche le portefeuille européen d’identité numérique de prendre en charge un type ou un format de justificatif d’identité enregistré, la non-conformité qui en résulte est imputable au fait que ces systèmes d’exploitation, navigateurs, API de médiation ou autres couches techniques pertinentes sous-jacents ne fournissent pas les caractéristiques d’interopérabilité nécessaires.
6) 4.4. Wallet-relying party validation and overasking checks
— WRP-VALIDATION-01: le portefeuille européen d’identité numérique doit valider le certificat d’enregistrement de partie utilisatrice de portefeuille reçu dans la demande avant de présenter toute PID ou attestation électronique d’attributs demandée à l’utilisateur de portefeuille pour approbation.
— WRP-VALIDATION-02: en cas d’échec de la validation du certificat d’enregistrement de partie utilisatrice de portefeuille, y compris lorsque le certificat a expiré, a été révoqué, n’a pas été délivré par un fournisseur de confiance valide de certificats d’enregistrement de partie utilisatrice de portefeuille, n’a pas été correctement formé ou ne peut pas être vérifié par des moyens cryptographiques, le portefeuille européen d’identité numérique doit avertir l’utilisateur de portefeuille que la partie utilisatrice de portefeuille n’a pas pu être validée et ne doit pas indiquer que la validation de la demande a réussi. L’utilisateur de portefeuille doit approuver explicitement la demande de la partie utilisatrice. Ni l’absence de réponse ni des cases cochées par défaut n’ont valeur d’approbation explicite.
— WRP-VALIDATION-03: le fournisseur de portefeuille doit déterminer, sur la base de son analyse des risques et de sa politique de sécurité, si et dans quelles conditions l’utilisateur de portefeuille peut contourner des contrôles de validation spécifiques ayant échoué.
— WRP-OVERASKING-01: le portefeuille européen d’identité numérique doit comparer les attestations et attributs demandés par la partie utilisatrice de portefeuille avec les attestations et attributs enregistrés dans le certificat d’enregistrement de partie utilisatrice de portefeuille.
— WRP-OVERASKING-02: lorsque la partie utilisatrice de portefeuille demande des PID ou des attestations électroniques d’attributs ou des revendications qui ne sont pas couvertes par le certificat d’enregistrement de partie utilisatrice de portefeuille, le portefeuille européen d’identité numérique doit émettre un avertissement clair à l’intention de l’utilisateur de portefeuille avant toute divulgation. L’avertissement doit indiquer que la partie utilisatrice de portefeuille demande davantage d’informations que celles qui ont été enregistrées. L’utilisateur de portefeuille doit approuver explicitement la demande de la partie utilisatrice. Ni l’absence de réponse ni des cases cochées par défaut n’ont valeur d’approbation explicite.
— WRP-OVERASKING-03: le fournisseur de portefeuille doit déterminer, sur la base de son analyse des risques, de sa politique de sécurité et du droit applicable, si l’utilisateur de portefeuille peut continuer malgré cet avertissement, si seul le sous-ensemble de données demandées couvert par le certificat d’enregistrement peut être divulgué ou si la demande doit être rejetée.
7) 5.1. Introduction
— Le paragraphe 5 et ses sous-paragraphes définissent un profil pour un protocole permettant à une RP de demander des EAAP ou des PID au portefeuille européen d’identité numérique, et à ce portefeuille d’envoyer les EAAP/PID demandées à la RP au moyen soit d’un mécanisme de transmission sans médiation d’API, fondé sur la norme ISO/IEC 18013-5 [10], soit d’un mécanisme de transmission avec médiation d’API fondé sur l’annexe C de la norme ISO/IEC 18013-7 [16] pour le transfert des structures de données définies dans la norme ISO/IEC 18013-5 [10] convenablement encapsulées.
— Le reste du paragraphe 5 est organisé comme suit:
— le paragraphe 5.2 définit les exigences relatives à la prise en charge du profil et des mécanismes de transmission par les RP et le portefeuille européen d’identité numérique;
— le paragraphe 5.3 précise les exigences spécifiquement applicables au mécanisme de transmission sans médiation d’API;
— le paragraphe 5.4 et ses sous-paragraphes précisent les exigences spécifiquement applicables au mécanisme de transmission avec médiation d’API.
8) 5.2. Requirements on EUDI Wallet and RP support
— ISO/IEC 18013-SUPPORT-01: les unités de portefeuille, les fournisseurs de PID, les fournisseurs d’attestations, les fournisseurs de portefeuille et les parties utilisatrices ne prennent pas en charge la récupération sur serveur telle que spécifiée dans la norme ISO/IEC 18013-5 [10] pour demander et présenter des PID ou des attributs d’attestations.
— ISO/IEC 18013-SUPPORT-02: le portefeuille européen d’identité numérique doit être conforme aux exigences définies aux paragraphes 5.3 et 5.4 du présent document.
— ISO/IEC 18013-SUPPORT-04: il convient qu’une partie utilisatrice mette en œuvre le profil défini au paragraphe 5.4 du présent document.
9) 5.3.2 ISO/IEC-mdoc EAAP Request contents
— ISO/IEC 18013-5-REQ-04: les demandes envoyées par l’appareil au portefeuille européen d’identité numérique doivent contenir la paire clé-valeur 'requestInfo' spécifiée au paragraphe 8.3.2.1.2.1 de [10]. La valeur de cette paire doit être du type RequestInfo.
— ISO/IEC 18013-5-REQ-05: le type RequestInfo doit correspondre à la définition CDDL ci-dessous:
RequestInfo = {
'euWrprc': bstr ; contient un certificat d’enregistrement (voir les exigences ci-dessous)
}
— ISO/IEC 18013-5-REQ-06: le membre requestInfo mentionné doit comporter un membre muni de l’étiquette 'euWrprc'.
— ISO/IEC 18013-5-REQ-07: la valeur de la paire 'euWrprc' doit être un certificat d’enregistrement encodé au format CBOR.
— ISO/IEC 18013-5-REQ-08: vide.
— REMARQUE 3: vide.
— ISO/IEC 18013-5-REQ-09: vide.
— ISO/IEC 18013-5-REQ-10: vide.
— ISO/IEC 18013-5-REQ-11: vide.
10) 5.3.3. ISO/IEC-mdoc EAAP Response profile
— Le présent paragraphe définit les exigences applicables au type de message DeviceResponse, commun aux deux types de mécanismes de transmission (avec et sans médiation d’API).
— REMARQUE 1: lorsqu’un mécanisme sans médiation d’API fondé sur la norme ISO/IEC 18013-5 [10] est utilisé, une réponse EAAP est exactement une instance de DeviceResponse telle que décrite dans le présent paragraphe. Lorsqu’un mécanisme avec médiation d’API fondé sur l’annexe C de la norme ISO/IEC 18013-7 [16] est utilisé, l’instance de DeviceRequest est encapsulée comme spécifié à l’annexe C du [16].
— ISO/IEC 18013-5-RESP-02: le fournisseur de données d’identification personnelle et d’attestations électroniques d’attributs n’inclut aucun élément de données de la table associative KeyAuthorizations de l’objet de sécurité mobile des données d’identification personnelle et des attestations électroniques d’attributs qu’il délivre, à l’exception des éléments de données qui sont fournis par la partie utilisatrice de portefeuille dans les données transactionnelles de la demande mdoc, qui doit être signée ou cachetée par l’unité de portefeuille à l’aide de la clé privée des données d’identification personnelle ou des attestations électroniques d’attributs.
— REMARQUE 2: par conséquent, les unités de portefeuille ne peuvent pas présenter aux parties utilisatrices de portefeuille d’éléments de données signés par le dispositif, à l’exception des données que la partie utilisatrice de portefeuille a fournies, par exemple pour une authentification sécurisée de l’utilisateur.
— REMARQUE 3: la norme ISO/IEC 18013-5: 2021 ne précise pas comment les parties utilisatrices de portefeuille peuvent inclure des données transactionnelles dans une demande mdoc. L’inclusion de données transactionnelles dans une demande mdoc nécessite des spécifications techniques supplémentaires.
— ISO/IEC 18013-5-RESP-03: les fournisseurs de données d’identification personnelle n’autorisent pas la clé privée des données d’identification personnelle à signer les éléments de données qui sont fournis par la partie utilisatrice de portefeuille dans les données transactionnelles figurant dans la demande mdoc.
11) 5.4. Requirements for API mediated mechanism
5. 4.1. ISO/IEC 18013-7-related requirements
Le présent paragraphe définit les exigences applicables au mécanisme de transmission avec médiation d’API en rapport avec les exigences définies à l’annexe C du [16].
— ISO/IEC 18013-7-API-01: le profil prenant en charge les présentations avec médiation d’API doit être conforme aux exigences de l’annexe C de la norme ISO/IEC 18013-7 [16] telles que précisées dans les paragraphes 5.3 et 5.4 du présent document.
— ISO/IEC 18013-7-API-02: toutes les exigences obligatoires définies à l’annexe C du [16] sont applicables, telles que précisées dans les paragraphes 5.3 et 5.4 du présent document.
— ISO/IEC 18013-7-API-03: toutes les exigences facultatives définies à l’annexe C du [16] doivent rester facultatives, sauf indication contraire dans le présent document.
12) 5.4.2. Additional requirements
— Le présent paragraphe spécifie des exigences supplémentaires pour le mécanisme de transmission avec médiation d’API.
— ISO/IEC 18013-ADD-API-01: le portefeuille européen d’identité numérique doit divulguer par défaut la présence de tous les types d’attestations électroniques d’attributs stockés à l’API de médiation qui fonctionne conformément à l’annexe C du [16], mais il ne doit pas divulguer les attributs et leurs valeurs dans ces attestations électroniques d’attributs.
— REMARQUE 1: la restriction concernant la valeur des attributs s’applique même si cette divulgation aurait pour effet d’améliorer les services fournis par le système d’exploitation au portefeuille, par exemple la sélection de l’attestation dans le cadre de l’API assurant la médiation.
— Certaines considérations relatives aux systèmes d’exploitation et aux navigateurs échappent au contrôle des responsables de la mise en œuvre et peuvent être prises en compte comme indiqué dans les remarques 2 à 4 suivantes:
— REMARQUE 2: une demande de présentation émanant d’une partie utilisatrice prenant en charge l’annexe C du [16] peut être traitée par le navigateur et/ou le système d’exploitation pour rechercher des EAA disponibles, pour prévenir une fraude ciblant l’utilisateur ou à des fins de dépannage.
— REMARQUE 3: une demande de présentation émanant d’une partie utilisatrice prenant en charge l’annexe C du [16] est censée être traitée par le navigateur et/ou le système d’exploitation pour la sécurité de l’utilisateur.
— REMARQUE 4: une demande de présentation émanant d’une partie utilisatrice prenant en charge l’annexe C de [16] ne devrait pas être traitée par le navigateur et/ou le système d’exploitation à des fins d’analyse de marché (y compris à titre secondaire) ou à des fins internes du navigateur et/ou du système d’exploitation.
— ISO/IEC 18013-ADD-API-02: lorsqu’un portefeuille européen d’identité numérique supprime, à la demande de l’utilisateur, des PID ou une EAA précédemment divulguées à l’API assurant la médiation qui fonctionne conformément à l’annexe C du [16], le portefeuille indique à l’API assurant la médiation qu’il ne stocke plus ces PID ou cette EAA.
— ISO/IEC 18013-ADD-API-03: si l’utilisateur désinstalle son portefeuille européen d’identité numérique, le portefeuille divulgue le fait qu’il ne stocke plus aucun des PID ou EAA précédemment divulgués à l’API de médiation qui fonctionne conformément à l’annexe C du [16].
— ISO/IEC 18013-ADD-API-04: le portefeuille européen d’identité numérique comporte un paramètre utilisateur global permettant de désactiver la divulgation des EAA stockées via une API de médiation qui fonctionne conformément aux spécifications de la norme ISO/IEC 18013-ADD-API-01. Lorsque ce paramètre est désactivé, le portefeuille ne fait pas d’annonce ou ne répond pas aux demandes de présentation ou d’émission transmises par l’API.
— ISO/IEC 18013-ADD-API-05: les portefeuilles européens d’identité numérique vérifient dans les flux multi-appareils, à l’aide de l’API de médiation, que l’appareil qui interagit se trouve à proximité physique immédiate du portefeuille européen d’identité numérique, au moyen d’un canal de communication local sécurisé, direct et nécessitant une action de l’utilisateur, tel qu’une technologie de communication sans fil à courte portée, pour effectuer la vérification de proximité physique.
— REMARQUE: le protocole CTAP 2.3 permet d’utiliser le BLE pour effectuer la vérification de proximité physique immédiate et, lorsqu’il est mis en œuvre par les deux appareils, permet également de transporter les données d’un appareil à l’autre au moyen de technologies de transmission à courte portée. Les systèmes d’exploitation, navigateurs, API de médiation sous-jacents ou toute autre couche technique échappant au contrôle du portefeuille européen d’identité numérique devraient utiliser, pour réaliser tant la vérification de proximité physique que le transfert de données entre les deux appareils, un canal de communication local comme prévu par le CTAP 2.3 plutôt que de recourir aux services de transport hybride CTAP.
13) 6.2 Requirements on EUDI Wallet and RP support
— OIDFVP-HAIP-SUPPORT-02: le portefeuille européen d’identité numérique doit être conforme aux exigences définies au paragraphe 6.5 de la présente annexe.
— OIDFVP-HAIP-SUPPORT-03: le portefeuille européen d’identité numérique ne devrait pas prendre en charge le mécanisme fondé sur les redirections spécifié au paragraphe 6.4 pour les flux de présentation multi-appareils.
— REMARQUE 3: ce mécanisme est vulnérable aux attaques, notamment par fixation des sessions. Il appartient aux parties utilisatrices d’atténuer ces attaques. La mise en œuvre de ce mécanisme ne devrait pas entraîner de non-conformité.
— OIDFVP-HAIP-SUPPORT-05: une partie utilisatrice doit être conforme aux exigences définies au paragraphe 6.5 de la présente annexe.
— REMARQUE 5: vide.
14) 6.3.1. General requirements
— OIDFVP-HAIP-GEN-01: toutes les exigences obligatoires énoncées aux paragraphes 5, 5.3, 7 et 8 de HAIP [11] s’appliquent.
— REMARQUE 1: «Section 5 de HAIP [11]» renvoie uniquement aux exigences énoncées directement sous l’intitulé «Section 5». Cela n’inclut pas les sections 5.1, 5.2 et 5.3.
— OIDFVP-HAIP-GEN-03: si la présente annexe modifie une exigence dans OpenID4VC-HAIP [11], l’exigence modifiée spécifiée par la présente annexe prévaut.
— REMARQUE 2: cela permettrait, par exemple, de rendre obligatoire une exigence facultative de OpenID4VC-HAIP [11] ou d’étendre des exigences obligatoires.
— OIDFVP-HAIP-GEN-04: lorsque le format de l’attestation demandée est conforme à [10], les parties utilisatrices et les portefeuilles européens d’identité numérique doivent être conformes au profil 'ISO mdocs' figurant à la section 6 de [11].
— REMARQUE 3: éclaircissement: le profil 'ISO mdocs' dans HAIP implique que les parties utilisatrices et les portefeuilles européens d’identité numérique doivent être conformes aux exigences applicables figurant à la section [7] de l’annexe B.2.
— OIDFVP-HAIP-GEN-05: lorsque le format de l’attestation demandée est conforme à [2], les parties utilisatrices et les portefeuilles européens d’identité numérique doivent être conformes au profil 'IETF SD-JWT VCs' figurant à la section 6 de [11].
— REMARQUE 4: éclaircissement: le profil 'IETF SD-JWT VCs' implique que les parties utilisatrices et les portefeuilles européens d’identité numérique doivent être conformes aux exigences figurant à la section [7] de l’annexe B.3, ainsi qu’aux exigences figurant à la section 6.1 de [11].
15) 6.3.2.1 General requirements
— OIDFVP-HAIP-COMMON-REQ-01: vide.
16) 6.3.2.2 Requirements for the Request Object
— OIDFVP-HAIP-COMMON-REQ-RO-02: vide.
— OIDFVP-HAIP-COMMON-REQ-RO-03: vide.
— OIDFVP-HAIP-COMMON-REQ-RO-04: vide.
— OIDFVP-HAIP-COMMON-REQ-RO-05: vide.
— OIDFVP-HAIP-COMMON-REQ-RO-06: vide.
— OIDFVP-HAIP-COMMON-REQ-RO-07: vide.
— OIDFVP-HAIP-COMMON-REQ-RO-08: vide.
— OIDFVP-HAIP-COMMON-REQ-RO-09: vide.
— OIDFVP-HAIP-COMMON-REQ-RO-10: vide.
— OIDFVP-HAIP-COMMON-REQ-RO-11: vide.
— OIDFVP-HAIP-COMMON-REQ-RO-12: vide.
— Remarque 2: vide.
— OIDFVP-HAIP-COMMON-REQ-RO-13: l’un des éléments du paramètre verifier_info comprend le certificat d’enregistrement.
— OIDFVP-HAIP-COMMON-REQ-RO-23: le certificat d’entité finale mentionné dans la section 5.9.3 d’OpenID4VP, à utiliser avec le x509_hash Client Identifier Prefix est un certificat d’accès de RP tel que spécifié dans ETSI TS 119 475 [14].
17) 6.3.3 Authorization Response (EAAP response) profile
— OIDFVP-HAIP-COMMON-RESP-01: vide.
18) 6.4.1 General requirements
— OIDFVP-HAIP-REDIRECTS-04: vide.
— REMARQUE: vide.
19) 6.5.2 General requirements
— OIDFVP-HAIP-ADD-API-01: le portefeuille européen d’identité numérique doit divulguer par défaut la présence de tous les types d’EAA stockées à l’API assurant la médiation qui fonctionne conformément au paragraphe 5.2 de [11], mais il ne doit pas divulguer les attributs et leurs valeurs dans ces EAA.
— OIDFVP-HAIP-ADD-API-04: si le portefeuille européen d’identité numérique prend en charge une API de médiation qui fonctionne comme indiqué dans OIDFVP-HAIP-ADD-API-01, il doit comporter un paramètre utilisateur global permettant de désactiver la divulgation des EAA stockées par l’intermédiaire de l’API de médiation. Lorsque ce paramètre est configuré en divulgation désactivée, le portefeuille européen d’identité numérique devrait ensuite permettre à l’utilisateur de sélectionner individuellement les attestations à divulguer à l’API de médiation.
— OIDFVP-HAIP-ADD-API-05: les portefeuilles européens d’identité numérique doivent utiliser, dans les flux multi-appareils, l’API de médiation pour vérifier que l’appareil qui interagit se trouve à proximité physique immédiate du portefeuille européen d’identité numérique, au moyen d’un canal de communication local sécurisé, direct et nécessitant une action de l’utilisateur, tel qu’une technologie de communication sans fil à courte portée, pour effectuer la vérification de proximité physique.
— REMARQUE 5: le protocole CTAP 2.3 permet d’utiliser le BLE pour effectuer la vérification de proximité physique immédiate et, lorsqu’il est mis en œuvre par les deux appareils, permet également de transporter les données d’un appareil à l’autre au moyen de technologies de transmission à courte portée. Les systèmes d’exploitation, navigateurs, API de médiation sous-jacents ou toute autre couche technique échappant au contrôle du portefeuille européen d’identité numérique devraient utiliser, pour réaliser tant la vérification de proximité physique que le transfert de données entre les deux appareils, un canal de communication local comme prévu par le CTAP 2.3 plutôt que de recourir aux services de transport hybride CTAP.
20) 6.5.3 Specific requirements when requesting ISO/IEC 18013-5 EAAP
— OIDFVP-HAIP-ISO/IEC_18013_5_REQ-02: toutes les exigences énoncées dans le présent document applicables aux structures Device Request et Device Response précisées dans ISO/IEC 18013-5 sont également applicables lorsque le portefeuille européen d’identité numérique reçoit une demande de présentation ISO/IEC mdoc via un mécanisme transmis par API figurant dans le paragraphe C.1 de [16].