Règlement d’exécution (UE) 2024/2982 de la Commission du 28 novembre 2024 portant modalités d’application du règlement (UE) no 910/2014 du Parlement européen et du Conseil en ce qui concerne les protocoles et les interfaces que doit prendre en charge le cadre européen relatif à une identité numérique

Article 1

Objet et champ d’application

Le présent règlement fixe des règles relatives aux protocoles et aux interfaces des solutions de portefeuille concernant:

1) la délivrance de données d’identification personnelle et d’attestations électroniques d’attributs aux unités de portefeuille;

2) la présentation des attributs des données d’identification personnelle et des attestations électroniques d’attributs aux parties utilisatrices de portefeuille;

3) la communication des demandes d’effacement de données aux parties utilisatrices de portefeuille;

4) le signalement des parties utilisatrices de portefeuille aux autorités de contrôle instituées en vertu de l’article 51 du règlement (UE) 2016/679.

Le présent règlement est mis à jour régulièrement pour tenir compte de l’évolution des technologies et des normes ainsi que des travaux réalisés sur la base de la recommandation (UE) 2021/946, et en particulier sur l’architecture et le cadre de référence.

Article 2

Définitions

Aux fins du présent règlement, on entend par:

1) «partie utilisatrice de portefeuille»: une partie utilisatrice qui a l’intention de se fier à des unités de portefeuille pour la fourniture de services publics ou privés au moyen d’une interaction numérique;

2) «utilisateur de portefeuille»: un utilisateur qui contrôle l’unité de portefeuille;

3) «solution de portefeuille»: une combinaison de logiciels, de matériel, de services, de paramètres et de configurations, y compris des instances de portefeuille, une ou plusieurs applications cryptographiques sécurisées de portefeuille et un ou plusieurs dispositifs cryptographiques sécurisés de portefeuille;

4) «unité de portefeuille»: une configuration unique d’une solution de portefeuille comprenant des instances de portefeuille, des applications cryptographiques sécurisées de portefeuille et des dispositifs cryptographiques sécurisés de portefeuille, fournie par un fournisseur de portefeuille à un utilisateur de portefeuille donné;

5) «fournisseur de portefeuille»: une personne physique ou morale qui fournit des solutions de portefeuille;

6) «instance de portefeuille»: l’application installée et configurée sur l’appareil ou dans l’environnement d’un utilisateur de portefeuille, qui fait partie d’une unité de portefeuille et dont l’utilisateur de portefeuille se sert pour interagir avec l’unité de portefeuille;

7) «application cryptographique sécurisée de portefeuille»: une application qui gère des actifs critiques en étant liée aux fonctions cryptographiques et non cryptographiques fournies par le dispositif cryptographique sécurisé de portefeuille et en utilisant ces fonctions;

8) «dispositif cryptographique sécurisé de portefeuille»: un dispositif inviolable qui fournit un environnement lié à l’application cryptographique sécurisée de portefeuille et utilisé par celle-ci pour protéger les actifs critiques et fournir des fonctions cryptographiques pour l’exécution sécurisée d’opérations critiques;

9) «actifs critiques»: les actifs se trouvant à l’intérieur d’une unité de portefeuille ou en rapport avec celle-ci et dont l’importance est tellement exceptionnelle que la capacité de se fier à l’unité de portefeuille serait très sérieusement affaiblie si leur disponibilité, leur confidentialité ou leur intégrité étaient compromises;

10) «certificat d’accès de partie utilisatrice de portefeuille»: un certificat de cachet électronique ou de signature électronique qui authentifie et valide la partie utilisatrice de portefeuille et qui est délivré par un fournisseur de certificats d’accès de partie utilisatrice de portefeuille;

11) «fournisseur de certificats d’accès de partie utilisatrice de portefeuille»: une personne physique ou morale mandatée par un État membre pour délivrer des certificats d’accès de partie utilisatrice aux parties utilisatrices de portefeuille enregistrées dans cet État membre;

12) «attestation d’unité de portefeuille»: un objet de données qui décrit les composants de l’unité de portefeuille ou permet l’authentification et la validation de ces composants;

13) «politique de divulgation intégrée»: un ensemble de règles, intégrées dans une attestation électronique d’attributs par son fournisseur, qui indique les conditions qu’une partie utilisatrice de portefeuille doit remplir pour accéder à l’attestation électronique d’attributs;

14) «certificat d’enregistrement de partie utilisatrice de portefeuille»: un objet de données qui indique les attributs pour lesquels la partie utilisatrice a enregistré son intention de les demander aux utilisateurs;

15) «fournisseur de données d’identification personnelle»: une personne physique ou morale chargée de délivrer et de révoquer les données d’identification personnelle et de veiller à ce que les données d’identification personnelle d’un utilisateur soient liées de manière cryptographique à une unité de portefeuille;

16) «liaison cryptographique»: la méthode permettant de lier les données d’identification personnelle ou les attestations électroniques d’attributs aux unités de portefeuille à l’aide de moyens cryptographiques.

Article 3

Dispositions générales

Concernant les protocoles et les interfaces visés aux articles 4 et 5, les fournisseurs de portefeuille veillent à ce que les unités de portefeuille:

1) authentifient et valident les certificats d’accès de partie utilisatrice de portefeuille lors d’interactions avec des parties utilisatrices de portefeuille sans déléguer l’exécution de ces processus à un navigateur du système d’exploitation ou à une autre application intermédiaire;

3) authentifient et valident les demandes introduites au moyen de certificats d’accès de partie utilisatrice de portefeuille;

4) authentifient et valident le certificat d’enregistrement de partie utilisatrice de portefeuille;

5) affichent aux utilisateurs de portefeuille les informations contenues dans les certificats d’accès de partie utilisatrice de portefeuille;

6) affichent aux utilisateurs de portefeuille, le cas échéant, les attributs que ceux-ci sont tenus de présenter;

7) affichent aux utilisateurs de portefeuille, le cas échéant, les informations contenues dans le certificat d’enregistrement de partie utilisatrice de portefeuille;

9) ne présentent aucun attribut demandé aux parties utilisatrices de portefeuille tant que les conditions suivantes ne sont pas remplies:

a) il a été vérifié que les politiques de divulgation intégrées ont été traitées au sein de l’unité de portefeuille conformément à l’article 10 du règlement d’exécution (UE) 2024/2979;

b) il a été vérifié que les utilisateurs de portefeuille ont approuvé partiellement ou intégralement la présentation;

10) permettent des techniques de protection de la vie privée qui garantissent la non-associabilité lorsque les attestations électroniques d’attributs n’exigent pas l’identification de l’utilisateur de portefeuille au moment de la présentation d’attestations ou de données d’identification personnelle entre différentes parties utilisatrices de portefeuille.

Article 4

Délivrance de données d’identification personnelle et d’attestations électroniques d’attributs aux unités de portefeuille

1. Les fournisseurs de portefeuille veillent à ce que les solutions de portefeuille prennent en charge les protocoles et les interfaces figurant à l’annexe I pour la délivrance de données d’identification personnelle et d’attestations électroniques d’attributs aux unités de portefeuille.

2. Les fournisseurs de portefeuille veillent à ce que les unités de portefeuille ne demandent la délivrance de données d’identification personnelle et d’attestations électroniques d’attributs qu’à des parties disposant d’un certificat d’accès de partie utilisatrice de portefeuille authentique et valide attestant qu’elles sont:

a) un fournisseur de données d’identification personnelle;

b) un fournisseur d’une attestation électronique d’attributs qualifiée;

c) un fournisseur d’une attestation électronique d’attributs délivrée par un organisme du secteur public responsable d’une source authentique ou pour son compte; ou

d) un fournisseur d’attestations électroniques d’attributs non qualifiées.

3. En ce qui concerne la délivrance de données d’identification personnelle et d’attestations électroniques d’attributs à une unité de portefeuille, les fournisseurs de portefeuille veillent à ce que les exigences suivantes soient respectées:

a) lorsque les utilisateurs de portefeuille se servent de leur unité de portefeuille pour demander la délivrance de données d’identification personnelle ou d’attestations électroniques d’attributs à des fournisseurs de données d’identification personnelle ou à des fournisseurs d’attestations électroniques d’attributs qui permettent la délivrance de données d’identification personnelle ou d’attestations électroniques dans plusieurs formats, l’unité de portefeuille en fait la demande dans tous les formats visés à l’article 8 du règlement d’exécution (UE) 2024/2979 portant modalités d’application du règlement (UE) no 910/2014 en ce qui concerne l’intégrité et les fonctionnalités essentielles des portefeuilles européens d’identité numérique;

b) lorsque les utilisateurs de portefeuille se servent de leur unité de portefeuille pour interagir avec des fournisseurs de données d’identification personnelle ou des fournisseurs d’attestations électroniques d’attributs, les unités de portefeuille permettent l’authentification et la validation des composants de l’unité de portefeuille en présentant les attestations d’unité de portefeuille à ces fournisseurs à leur demande;

c) les solutions de portefeuille prennent en charge les mécanismes qui permettent aux fournisseurs de données d’identification personnelle de vérifier la délivrance, la mise à disposition et l’activation conformément aux exigences en matière de niveau de garantie élevé énoncées dans le règlement d’exécution (UE) 2015/1502 de la Commission;

d) les unités de portefeuille vérifient l’authenticité et la validité des données d’identification personnelle et des attestations électroniques d’attributs.

Article 5

Présentation d’attributs aux parties utilisatrices de portefeuille

1. Les fournisseurs de portefeuille veillent à ce que les solutions de portefeuille prennent en charge les protocoles et les interfaces permettant la présentation d’attributs aux parties utilisatrices de portefeuille, à distance et, le cas échéant, à proximité, conformément aux spécifications techniques figurant à l’annexe II.

2. Les fournisseurs de portefeuille veillent à ce que, à la demande des utilisateurs, les unités de portefeuille répondent aux demandes dûment authentifiées et validées des parties utilisatrices de portefeuille mentionnées à l’article 3, conformément aux spécifications techniques figurant à l’annexe II.

3. Les fournisseurs de portefeuille veillent à ce que les unités de portefeuille permettent d’apporter la preuve qu’elles détiennent les clés privées correspondant aux clés publiques utilisées dans les liaisons cryptographiques.

4. Les fournisseurs de portefeuille veillent à ce que les solutions de portefeuille prennent en charge la divulgation sélective d’attributs de données d’identification personnelle et d’attestations électroniques d’attributs.

Article 6

Communication des demandes d’effacement de données

1. Les fournisseurs de portefeuille veillent à ce que les unités de portefeuille prennent en charge les protocoles et les interfaces permettant aux utilisateurs de portefeuille de demander aux parties utilisatrices de portefeuille avec lesquelles ils ont interagi au moyen de ces unités de portefeuille d’effacer leurs données à caractère personnel fournies par l’intermédiaire de ces unités de portefeuille, conformément à l’article 17 du règlement (UE) 2016/679.

2. Les protocoles et les interfaces visés au paragraphe 1 permettent aux utilisateurs de portefeuille de sélectionner les parties utilisatrices de portefeuille à qui doivent être présentées les demandes d’effacement de données.

3. Les unités de portefeuille permettent à l’utilisateur de portefeuille de visualiser les demandes d’effacement de données précédemment soumises par leur intermédiaire.

Article 7

Signalement des parties utilisatrices de portefeuille aux autorités de contrôle instituées en vertu de l’article 51 du règlement (UE) 2016/679

1. Les fournisseurs de portefeuille veillent à ce que les unités de portefeuille permettent aux utilisateurs de portefeuille de signaler facilement des parties utilisatrices de portefeuille aux autorités de contrôle instituées en vertu de l’article 51 du règlement (UE) 2016/679.

2. Les fournisseurs de portefeuille mettent en œuvre les protocoles et les interfaces de signalement des parties utilisatrices de portefeuille conformément au droit procédural national des États membres.

3. Les fournisseurs de portefeuille veillent à ce que les unités de portefeuille permettent aux utilisateurs de portefeuille d’étayer leurs signalements, notamment en joignant des informations pertinentes permettant d’identifier les parties utilisatrices de portefeuille, et les propres déclarations dans un format lisible par la machine.

Article 8

Entrée en vigueur

Le présent règlement entre en vigueur le vingtième jour suivant celui de sa publication au Journal officiel de l’Union européenne.

L’article 3, paragraphe 4, s’applique à compter du 11 août 2028.

Le présent règlement est obligatoire dans tous ses éléments et directement applicable dans tout État membre.

Annexe I

ANNEXE I — Protocoles et interfaces visés à l’article 4

La spécification technique ETSI TS 119 472-3 V1.1.1 (2026-03) s’applique moyennant les adaptations suivantes:

1) 4.1. General requirements

— GEN-REQ-4.1-05: vide.

— REMARQUE: vide.

2) 4.2.3. Provision of registration certificates of PID/EAA Provider to EUDI Wallet

— ISS-MDATA-REG_CERT-4.2.3-04: L’un des éléments du paramètre de tableau issuer_info contient le certificat d’enregistrement du fournisseur de PID/EAA.

— ISS-MDATA-REG_CERT-4.2.3-07: vide.

— ISS-MDATA-REG_CERT-4.2.3-08: vide.

— ISS-MDATA-REG_CERT-4.2.3-09: vide.

— ISS-MDATA-REG_CERT-4.2.3-10: vide.

— ISS-MDATA-REG_CERT-4.2.3-11: vide.

— ISS-MDATA-REG_CERT-4.2.3-12: vide.

— ISS-MDATA-REG_CERT-4.2.3-13: vide.

3) 4.2.4.2 ARF pre-defined PID/EAA reuse policy

— ISS-MDATA-EAA-REUSE-POL-4.2.4.2-09: lorsque le membre id a la valeur 'arf_annex_ii' et que le tableau associé à l’étiquette 'details' contient la valeur 'once_only' ou la valeur 'per relying-party', l’objet JSON qui contient ce tableau associé à l’étiquette 'details' doit aussi contenir un numéro JSON associé à l’étiquette 'reissue_trigger_unused'.

4) L’annexe A ne s’applique pas.

Annexe II

ANNEXE II — Spécifications techniques visées à l’article 5

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].