Règlement d’exécution (UE) 2024/2979 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 l’intégrité et les fonctionnalités essentielles des portefeuilles européens d’identité numérique

Article 1

Objet et champ d’application

Le présent règlement établit les règles relatives à l’intégrité et aux fonctionnalités essentielles des portefeuilles, qui sont mises à 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, dont l’architecture et le cadre de référence.

Article 2

Définitions

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

1) «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;

2) «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/éléments cryptographiques sécurisés de portefeuille fournie à un utilisateur de portefeuille donné par un fournisseur de portefeuilles;

3) «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é à utiliser l’unité de portefeuille serait très sérieusement affaiblie si leur disponibilité, leur confidentialité ou leur intégrité étaient compromises;

4) «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 cryptographiquement liées à une unité de portefeuille;

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

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

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

8) «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;

9) «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;

10) «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 du portefeuille se sert pour interagir avec l’unité de portefeuille;

11) «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;

12) «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;

13) «opération cryptographique de portefeuille»: un mécanisme cryptographique nécessaire dans le cadre de l’authentification de l’utilisateur du portefeuille et de la délivrance ou présentation de données d’identification personnelle ou d’attestations électroniques d’attributs;

14) «certificat d’accès de partie utilisatrice de portefeuille»: un certificat de cachet électronique ou de signature électronique authentifiant et validant la partie utilisatrice de portefeuille, délivré par un fournisseur de certificats d’accès de partie utilisatrice de portefeuille;

15) «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.

Article 3

Intégrité de l’unité de portefeuille

1. Les unités de portefeuille n’exécutent aucune des fonctionnalités énumérées à l’article 5 bis, paragraphe 4, du règlement (UE) no 910/2014, sauf l’authentification de l’utilisateur de portefeuille pour accéder à l’unité de portefeuille, tant que l’unité de portefeuille n’a pas authentifié l’utilisateur du portefeuille.

Article 4

Instances de portefeuille

1. Les instances de portefeuille utilisent au moins un dispositif cryptographique sécurisé de portefeuille pour gérer les actifs critiques.

2. Les fournisseurs de portefeuille garantissent l’intégrité, l’authenticité et la confidentialité de la communication entre les instances de portefeuille et les applications cryptographiques sécurisées de portefeuille.

3. Lorsque des actifs critiques sont liés à l’exécution d’une identification électronique à un niveau de garantie élevé, les opérations cryptographiques de portefeuille ou autres opérations de traitement des actifs critiques sont effectuées conformément aux exigences relatives aux caractéristiques et à la conception des moyens d’identification électronique à un niveau de garantie élevé, telles qu’elles sont énoncées dans le règlement d’exécution (UE) 2015/1502 de la Commission.

Article 5

Applications cryptographiques sécurisées de portefeuille

1. Les fournisseurs de portefeuille veillent à ce que les applications cryptographiques sécurisées de portefeuille:

a) n’effectuent d’opérations cryptographiques de portefeuille impliquant des actifs critiques stockés dans un dispositif cryptographique sécurisé de portefeuille et non requis pour l’authentification de l’utilisateur de portefeuille que dans les cas où lesdites applications ont authentifié avec succès les utilisateurs de portefeuille;

b) lorsqu’elles authentifient des utilisateurs de portefeuille dans le cadre d’une identification électronique à un niveau de garantie élevé, procèdent à l’authentification des utilisateurs de portefeuille conformément aux exigences relatives aux caractéristiques et à la conception des moyens d’identification électronique à un niveau de garantie élevé, telles qu’elles sont énoncées dans le règlement d’exécution (UE) 2015/1502;

c) sont capables de générer de manière sécurisée de nouvelles clés cryptographiques;

d) sont capables de procéder à l’effacement sécurisé d’actifs critiques;

e) sont capables de générer une preuve de la possession de clés privées;

f) protègent les clés privées qu’elles ont générées pendant la durée d’existence des clés;

g) satisfont aux exigences relatives aux caractéristiques et à la conception des moyens d’identification électronique à un niveau de garantie élevé, telles qu’elles sont énoncées dans le règlement d’exécution (UE) 2015/1502;

h) sont les seuls composants capables d’exécuter des opérations cryptographiques de portefeuille et toute autre opération impliquant des actifs critiques dans le cadre d’une identification électronique à un niveau de garantie élevé.

2. Lorsque les fournisseurs de portefeuille décident de fournir une application cryptographique sécurisée de portefeuille à un élément sécurisé intégré, ils fondent leur solution technique sur les spécifications techniques énumérées à l’annexe I ou sur d’autres spécifications techniques équivalentes.

Article 5 bis

Mécanismes cryptographiques

Aux fins de l’article 4, paragraphe 2, les fournisseurs de portefeuille n’utilisent que les mécanismes cryptographiques visés à l’annexe I bis.

Article 6

Authenticité et validité de l’unité de portefeuille

1. Les fournisseurs de portefeuille délivrent des attestations d’unité de portefeuille pour chaque unité de portefeuille. Les fournisseurs de portefeuille apposent une signature ou un cachet sur les attestations d’unité de portefeuille de manière à ce que les signatures ou cachets puissent être validés au moyen d’un certificat énuméré conformément à la section 2, point 1), h), de l’annexe II du règlement d’exécution (UE) 2024/2980.

2. Les fournisseurs de portefeuille veillent à ce que les attestations d’unité de portefeuille visées au paragraphe 1 soient conformes aux spécifications techniques énoncées à l’annexe I ter.

3. Les fournisseurs de portefeuille:

a) informent les utilisateurs de portefeuille de leurs droits et obligations en ce qui concerne leur unité de portefeuille;

b) fournissent aux utilisateurs de portefeuille des mécanismes sécurisés d’identification et d’authentification indépendants des unités de portefeuille;

c) veillent à ce que les utilisateurs de portefeuille aient le droit de demander la révocation de leurs attestations d’unités de portefeuille au moyen des mécanismes d’authentification visés au point b).

Article 7

Révocation des attestations d’unités de portefeuille

1. Les fournisseurs de portefeuille sont les seules entités capables de révoquer les attestations d’unités de portefeuille pour les unités de portefeuille qu’ils ont fournies.

2. Les fournisseurs de portefeuille élaborent et mettent à la disposition du public une politique précisant les conditions et les délais de révocation des attestations d’unités de portefeuille.

3. Lorsque les fournisseurs de portefeuille révoquent des attestations d’unités de portefeuille, ils informent dans les 24 heures les utilisateurs de portefeuille concernés de la révocation de leurs unités de portefeuille, ainsi que de la raison de la révocation et des conséquences qui s’ensuivent pour l’utilisateur du portefeuille. Ces informations sont fournies de manière concise, facilement accessible et dans un langage clair et simple.

4. Lorsque les fournisseurs de portefeuille révoquent des attestations d’unités de portefeuille, ils mettent à la disposition du public le statut de validité de l’attestation d’unité de portefeuille, dans le respect de la vie privée, et décrivent la localisation de ces informations dans l’attestation d’unité de portefeuille.

Article 8

Formats des données d’identification personnelle et des attestations électroniques d’attributs

Les fournisseurs de portefeuille veillent à ce que les solutions de portefeuille prennent en charge l’utilisation des données d’identification personnelle et des attestations électroniques d’attributs délivrées conformément à la liste de normes figurant à l’annexe II.

Article 9

Journaux des transactions

1. Que la transaction soit menée à bien ou non, les instances de portefeuille journalisent toutes les transactions avec les parties utilisatrices de portefeuille et les autres unités de portefeuille, y compris les signatures et cachets électroniques.

2. Les informations journalisées comprennent au moins:

a) la date et le lieu de la transaction;

b) le nom, les coordonnées et l’identifiant unique de la partie utilisatrice de portefeuille correspondante ainsi que l’État membre dans lequel cette dernière est établie;

c) le ou les types de données demandées et présentées dans la transaction;

d) dans le cas d’opérations non achevées, la raison de cet inachèvement.

3. Les fournisseurs de portefeuille garantissent l’intégrité, l’authenticité et la confidentialité des informations journalisées.

4. Les instances de portefeuille journalisent les rapports envoyés par l’utilisateur du portefeuille aux autorités chargées de la protection des données par l’intermédiaire de leur unité de portefeuille.

5. Les éléments journalisés visés aux paragraphes 1 et 2 sont accessibles au fournisseur de portefeuille, lorsqu’ils sont nécessaires à la fourniture de services de portefeuille, sur la base du consentement préalable explicite de l’utilisateur de portefeuille.

6. Les éléments journalisés visés aux paragraphes 1 et 2 restent accessibles aussi longtemps que le requiert le droit de l’Union ou le droit national.

7. Les fournisseurs de portefeuille permettent aux utilisateurs de portefeuille d’exporter les informations journalisées visées au paragraphe 2.

Article 10

Divulgation intégrée

1. Les fournisseurs de portefeuille veillent à ce que les attestations électroniques d’attributs délivrées conformément aux spécifications techniques applicables aux politiques de divulgation intégrées communes au sens de l’annexe III puissent être traitées par les unités de portefeuille qu’ils fournissent.

2. Les instances de portefeuille sont en mesure de traiter et de présenter ces politiques de divulgation intégrées visées au paragraphe 1 en combinaison avec les données reçues de la partie utilisatrice de portefeuille.

3. Les instances de portefeuille vérifient si la partie utilisatrice de portefeuille respecte les exigences de la politique de divulgation intégrée et informent l’utilisateur de portefeuille du résultat.

Article 11

Signatures et cachets électroniques qualifiés

1. Les fournisseurs de portefeuille veillent à ce que les utilisateurs de portefeuille puissent recevoir les certificats qualifiés de signatures ou de cachets électroniques qualifiés qui sont liés à des dispositifs de création de signature ou de cachet qualifiés locaux, extérieurs ou distants par rapport aux instances de portefeuille.

2. Les fournisseurs de portefeuille veillent à ce que les solutions de portefeuille soient capables d’interagir de manière sécurisée avec l’un des types suivants de dispositifs de création de signature ou de cachet qualifiés: dispositifs de création de signature ou de cachet qualifiés locaux, externes ou gérés à distance aux fins de l’utilisation des certificats qualifiés visés au paragraphe 1.

3. Les fournisseurs de portefeuille veillent à ce que les utilisateurs de portefeuille qui sont des personnes physiques disposent, au moins à des fins non professionnelles, d’un accès gratuit aux applications de création de signature permettant la création de signatures électroniques qualifiées gratuites au moyen des certificats visés au paragraphe 1.

Article 12

Applications de création de signature

1. Les applications de création de signature utilisées par les unités de portefeuille peuvent être fournies soit par des fournisseurs de portefeuille, soit par des prestataires de services de confiance, soit par des parties utilisatrices de portefeuille.

2. Les applications de création de signature possèdent les fonctions suivantes:

a) apposer des signatures ou des cachets sur les données fournies par l’utilisateur de portefeuille;

b) apposer des signatures ou des cachets sur les données fournies par la partie utilisatrice;

c) créer des signatures ou des cachets correspondant au moins au format obligatoire de signature ou de cachet visé à l’annexe IV;

d) informer les utilisateurs de portefeuille du résultat du processus de création de signature ou de cachet.

3. Les applications de création de signature peuvent être intégrées aux instances de portefeuille ou extérieures à celles-ci.

4. Les applications de création de signature utilisées par les unités de portefeuille prennent en charge au moins l’interface de programmation d’applications visée à l’annexe IV.

Article 13

Exportation des données et portabilité des données

Les unités de portefeuille permettent d’assurer, en fonction des possibilités techniques et hors actifs critiques, l’exportation et la portabilité sécurisées des données à caractère personnel de l’utilisateur du portefeuille, afin de permettre à celui-ci de migrer vers une unité de portefeuille d’une autre solution de portefeuille dans des conditions offrant un niveau de garantie élevé au sens du règlement d’exécution (UE) 2015/1502.

Article 14

Pseudonymes

2. Les unités de portefeuille permettent de générer, à la demande d’une partie utilisatrice de portefeuille, un pseudonyme spécifique et exclusif pour cette dernière et lui fournissent ce pseudonyme, soit isolément, soit en combinaison avec toute donnée d’identification personnelle ou attestation électronique d’attributs demandée par elle.

Article 14 bis

Label de confiance de l’UE pour le portefeuille d’identité numérique

1. Les fournisseurs de portefeuille veillent à ce que les unités de portefeuille affichent le label de confiance de l’UE pour le portefeuille d’identité numérique. Le label de confiance de l’UE pour le portefeuille d’identité numérique se présente sous la forme prévue aux annexes VI et VII.

2. Les fournisseurs de portefeuille font en sorte que les utilisateurs de portefeuille puissent accéder, via les unités de portefeuille, aux informations leur permettant de vérifier l’état de certification de la solution de portefeuille. À cette fin, les fournisseurs de portefeuille veillent à ce que, après l’enregistrement d’une solution de portefeuille, les unités de portefeuille correspondantes comprennent les URL fournies par la Commission européenne pour cette vérification. Les fournisseurs de portefeuille veillent à ce que leurs unités de portefeuille aient accès aux données du label de confiance de l’UE pour le portefeuille d’identité numérique qui sont conformes aux spécifications techniques énoncées à l’annexe VIII.

3. Les couleurs de référence du label de confiance de l’UE pour le portefeuille d’identité numérique sont les couleurs Pantone no 661 et no 116; ou, lorsque le procédé par quadrichromie est utilisé, le bleu (100 % cyan + 67 % magenta + 0 % jaune + 40 % noir) et le jaune (0 % cyan + 20 % magenta + 100 % jaune + 0 % noir); lorsque les couleurs RGB sont utilisées, les couleurs de référence sont le bleu (0 rouge + 51 vert + 153 bleu) et le jaune (255 rouge + 204 vert + 0 bleu).

4. La version en noir et blanc du label de confiance de l’UE pour le portefeuille d’identité numérique figurant à l’annexe VII peut être utilisée uniquement dans les cas où l’utilisation de la couleur n’est pas possible pour des raisons pratiques.

5. Lorsque le label de confiance de l’UE pour le portefeuille d’identité numérique est placé sur fond foncé, il peut être utilisé en négatif, en reprenant la même couleur de fond. Lorsque la version en couleurs du label de confiance de l’UE pour le portefeuille d’identité numérique est utilisée sur un fond coloré qui rend le label difficile à voir, une ligne de délimitation extérieure peut être tracée autour du label afin de renforcer le contraste avec le fond.

6. Le label de confiance de l’UE pour le portefeuille d’identité numérique a une taille minimale de 64 × 85 pixels à 150 dpi.

7. Les fournisseurs de portefeuille font en sorte que l’utilisation du label de confiance de l’UE pour le portefeuille d’identité numérique permette de déterminer clairement à quelle unité de portefeuille ce label se rapporte. Le label de confiance de l’UE pour le portefeuille d’identité numérique peut être associé à des éléments graphiques ou textuels indiquant clairement pour quelle unité de portefeuille il est utilisé, à condition qu’ils n’affectent ni sa capacité à être reconnu comme label de confiance de l’UE pour le portefeuille d’identité numérique, ni l’association à la liste des portefeuilles européens d’identité numérique certifiés visée à l’article 5 quinquies du règlement (UE) no 910/2014.

8. Lorsque les fournisseurs de portefeuille ont révoqué une attestation d’unité de portefeuille, ils veillent à ce que le label de confiance de l’UE pour le portefeuille d’identité numérique ne soit plus affiché par l’unité de portefeuille correspondante.

Article 15

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.

Annexe I

ANNEXE I — LISTE DES NORMES VISÉES À L’ARTICLE 5

— SAM.01 «Secured Applications for Mobile — Requirements for supporting 3rd party Applets on eSIM and eSE via SAM» v1.1 2023, GSMA.

— GPC_GUI_ 217 «GlobalPlatform SAM Configuration Technical specification for implementation of SAM» v1.0 2024-04.

— GPC_SPE_0 34 «GlobalPlatform Card Specification Technical specification for smart cards» v2.3.1 2018-03.

— GPC_SPE_0 07 «GlobalPlatform Amendment A Confidential Card Content Management» v1.2 2019-07.

— GPC_SPE_0 13 «GlobalPlatform Amendment D Secure Channel Protocol 03» v1.2 2020-04.

— GPC_SPE_0 93 «GlobalPlatform Amendment F Secure Channel Protocol 11» v1.4 2024-03.

— GPD_SPE_0 75 «Open Mobile API Specification OMAPI API for mobile apps to access secure elements on user devices» v3.3 2018-08, GlobalPlatform.

Annexe I (2)

ANNEXE I bis — MÉCANISMES CRYPTOGRAPHIQUES VISÉS À L’ARTICLE 5 bis

Groupe européen de certification de cybersécurité, sous-groupe sur la cryptographie: «Agreed Cryptographic Mechanisms», publié par l’Agence de l’Union européenne pour la cybersécurité (ENISA).

Annexe I (3)

ANNEXE I ter — SPÉCIFICATIONS TECHNIQUES POUR LES ATTESTATIONS D’UNITÉ DE PORTEFEUILLE VISÉES À L’ARTICLE 6, PARAGRAPHE 2 bis

1) Une attestation d’unité de portefeuille doit comprendre une ou plusieurs attestations d’instance de portefeuille et une ou plusieurs attestations de clé.

2) L’attestation d’instance de portefeuille et les attestations de clé doivent satisfaire aux exigences suivantes:

a) Exigences en matière de format

— FR-WIA-1: une attestation d’instance de portefeuille doit être un jeton Web JSON (JWT) tel que défini dans la RFC 7519, sur lequel le fournisseur de portefeuille a apposé sa signature ou son cachet au moyen d’une signature JAdES compacte conforme au niveau de base B.

— FR-WIA-1.1: une attestation d’instance de portefeuille doit être une attestation de portefeuille telle que définie à l’appendice E de la spécification «OpenID for Verifiable Credential Issuance v1.0» ('OID4VCI ') et étendue comme indiqué dans les paragraphes C-WIA-1 et C-WIA-2 ci-dessous.

— FR-KA-1: une attestation de clé doit être un JWT tel que défini dans la RFC 7519, sur lequel le fournisseur de portefeuille a apposé sa signature ou son cachet au moyen d’une signature JAdES compacte conforme au niveau de base B.

— FR_KA_1.1: une attestation de clé doit être une attestation de clé telle que définie à l’appendice D de la spécification OID4VCI, étendue comme indiqué dans les paragraphes C_KA-1 et C_KA-2 ci-dessous.

b) Exigences en matière de transport

— TR-WIA-1: une unité de portefeuille doit utiliser une attestation d’instance de portefeuille lors de la délivrance de données d’identification personnelle, d’attestations électroniques d’attributs qualifiées ou non qualifiées ou d’attestations électroniques d’attributs fournies par un organisme du secteur public responsable d’une source authentique ou pour son compte.

— TR-WIA-2: un fournisseur de portefeuille doit vérifier l’intégrité de l’instance de portefeuille et apposer sa signature ou son cachet sur l’attestation d’instance de portefeuille.

— TR-WIA-2.1: lorsqu’un fournisseur de portefeuille délivre une attestation d’instance de portefeuille, la différence entre l’heure à laquelle le fournisseur de portefeuille a vérifié l’intégrité de l’instance de portefeuille et l’heure qu’il indiquera dans le paramètre d’en-tête 'exp' de l’attestation d’instance de portefeuille délivrée doit être inférieure à 24 heures.

— TR-WIA-2.2: le fournisseur de portefeuille doit veiller à ce qu’une unité de portefeuille contienne les attestations d’instance de portefeuille nécessaires à la délivrance des données d’identification personnelle et des attestations électroniques d’attributs.

— TR-WIA-3: lors de la délivrance, une unité de portefeuille doit envoyer une attestation d’instance de portefeuille au serveur d’autorisation dans la demande d’autorisation poussée et la demande de jeton, comme indiqué dans la spécification OID4VCI.

— TR-WIA-3.1: une unité de portefeuille doit envoyer l’attestation d’instance de portefeuille accompagnée d’une preuve de possession ('PoP'), comme indiqué à l’appendice E de la spécification OID4VCI.

— TR-WIA-3.2: une unité de portefeuille ne doit envoyer la même attestation d’instance de portefeuille qu’à un seul serveur d’autorisation.

— TR-WIA-3.2.1: lorsqu’un fournisseur de portefeuille utilise l’option 'per-issuer reuse' spécifiée dans le paragraphe R_WIA_1 ci-dessous, une unité de portefeuille peut envoyer plusieurs fois une attestation d’instance de portefeuille au même serveur d’autorisation.

— TR-WIA-3.2.2: lorsqu’un fournisseur de portefeuille n’utilise pas l’option 'per-issuer reuse', une unité de portefeuille doit utiliser une attestation d’instance de portefeuille dans un seul processus de délivrance au maximum.

— TR-WIA-4: lorsqu’un serveur d’autorisation reçoit une attestation d’instance de portefeuille, il doit vérifier la signature de l’attestation d’instance de portefeuille en utilisant la clé publique contenue dans le certificat de signature inclus dans le paramètre 'x5c' de l’en-tête JOSE de l’attestation d’instance de portefeuille.

— TR-WIA-4.1: le serveur d’autorisation doit vérifier également que ce certificat de signature peut être vérifié avec une ancre de confiance sur la liste des fournisseurs de portefeuille visée à l’article 5 du règlement d’exécution (UE) 2024/2980, en utilisant éventuellement des certificats intermédiaires inclus dans le paramètre x5c.

— TR-WIA-4.2: le serveur d’autorisation doit vérifier que l’attestation d’instance de portefeuille n’a pas expiré.

— TR-WIA-4.3: le serveur d’autorisation doit vérifier la signature de la PoP en utilisant la clé publique figurant dans la revendication 'cnf'.

— TR_KA-1: une unité de portefeuille doit utiliser une attestation de clé lors de la délivrance de données d’identification personnelle et lors de la délivrance d’attestations électroniques d’attributs qualifiées ou non qualifiées liées à un appareil ou d’attestations électroniques d’attributs fournies par un organisme du secteur public responsable d’une source authentique ou pour son compte.

— TR_KA-1.1: une unité de portefeuille ne doit pas utiliser d’attestation de clé lors de la délivrance d’attestations électroniques d’attributs qualifiées ou non qualifiées liées à un appareil ou d’attestations électroniques d’attributs fournies par un organisme du secteur public responsable d’une source authentique ou pour son compte.

— TR_KA-2: un fournisseur de portefeuille doit fournir à une unité de portefeuille des attestations de clé différentes pour le WSCD de l’unité de portefeuille et pour chacun de ses magasins de clés.

— TR_KA-2.1: le fournisseur de portefeuille doit apposer sa signature ou son cachet sur une attestation de clé après avoir vérifié que les clés attestées dans l’attestation de clé sont stockées dans le WSCD de l’unité de portefeuille ou le magasin de clés décrit dans l’attestation de clé.

— TR_KA-2.2: une attestation de clé doit contenir au moins une clé publique attestée. Le nombre de clés contenues dans l’attestation de clé envoyée à un émetteur de justificatifs d’identité ne devrait pas dépasser la taille de lot maximale définie par ledit émetteur dans ses métadonnées; voir ETSI TS 119 472-3, paramètre 'credential_configurations_supported. credential_metadata.credential_reuse_policy.options.batch_size'.

— TR_KA-2.3: un fournisseur de portefeuille doit inclure une clé publique (correspondant à une clé privée stockée dans le WSCD ou le magasin de clés de l’unité de portefeuille) dans une seule attestation de clé au maximum.

— TR_KA-2.4: une unité de portefeuille doit utiliser une attestation de clé lors d’un seul processus de délivrance ou de redélivrance de justificatif d’identité au maximum.

— TR_KA-2.5: un fournisseur de portefeuille doit veiller à ce qu’une unité de portefeuille soit en possession des attestations de clé nécessaires à la délivrance des données d’identification personnelle et des attestations électroniques d’attributs liées à un appareil.

— TR_KA-3: en cas de nécessité lors de la délivrance, une unité de portefeuille doit contenir une attestation de clé dans le champ 'proofs' d’une demande de justificatif d’identité adressée à l’émetteur de justificatifs d’identité, comme indiqué dans la spécification OID4VCI, dans une preuve de type 'jwt' ou de type 'attestation'.

— TR_KA_3.1: lorsqu’une unité de portefeuille comprend une attestation de clé dans un élément 'jwt', elle doit apposer une signature ou un cachet sur l’attestation de clé en utilisant la clé privée correspondant à la clé publique située à l’index 0 du tableau 'attested_keys' dans l’objet 'key_attestation'.

— TR_KA-4: lorsqu’un émetteur de justificatifs d’identité émet des justificatifs liés à un appareil, il doit indiquer dans le paramètre 'proof_types_supported' de ses métadonnées, comme spécifié à la section 12.2.4 de la spécification OID4VCI, qu’il prend en charge à la fois le type de preuve 'jwt' et le type de preuve 'attestation' pour les attestations de clé qui contiennent l’objet 'key_attestations_required'.

— TR_KA-4.1: lorsqu’un émetteur de justificatifs d’identité délivre des justificatifs non liés à un appareil, il doit omettre les paramètres 'proof_types_supported' et 'cryptographic_binding_methods_supported' dans ses métadonnées d’émetteur de justificatifs d’identité.

— TR_KA-5: lorsqu’un émetteur de justificatifs d’identité reçoit une attestation de clé dans un type de preuve 'jwt' ou 'attestation', il doit vérifier la signature de l’attestation de clé en utilisant la clé publique contenue dans le certificat de signature inclus dans le paramètre 'x5c' de l’en-tête JOSE de l’attestation de clé et s’assurer que ce certificat de signature est relié à une ancre de confiance figurant sur la liste des fournisseurs de portefeuille visée à l’article 5 du règlement d’exécution (UE) 2024/2980, en utilisant éventuellement des certificats intermédiaires inclus dans le paramètre 'x5c'.

— TR_KA-6: lorsqu’un émetteur de justificatifs d’identité reçoit une attestation de clé dans un type de preuve 'jwt', il doit vérifier la signature de l’élément 'jwt' en utilisant la clé située à l’index 0 du tableau 'attested_keys' dans l’objet 'key_attestation' inclus dans l’élément 'jwt'.

— TR_KA-6.1: l’émetteur de justificatifs d’identité doit vérifier que le champ 'nonce' de l’élément 'jwt' comprend un c_nonce valide obtenu depuis son nonce_endpoint, comme indiqué dans la spécification OID4VCI.

— TR_KA-7: lorsqu’un émetteur de justificatifs d’identité reçoit une attestation de clé dans un type de preuve 'attestation', il doit vérifier que l’objet 'key_attestation' contient un c_nonce valide obtenu depuis son nonce_endpoint.

— TR_KA-8: un fournisseur de données d’identification personnelle doit veiller à ce que les données d’identification personnelle soient reliées à une clé publique provenant d’une attestation de clé mentionnant un WSCD.

c) Exigences en matière de contenu

— C_WIA-1: une attestation d’instance de portefeuille doit comprendre les éléments suivants:

— la revendication 'wallet_name' définie à l’appendice E de la spécification OID4VCI, dont la valeur doit être l’identifiant de la solution de portefeuille qui figure sur la liste des fournisseurs de portefeuille visée à l’article 5 du règlement d’exécution (UE) 2024/2980;

— une revendication 'wallet_version', qui doit être une chaîne de caractères dont la valeur doit être la version de la solution de portefeuille;

— une revendication 'wallet_solution_certification_information', qui doit être un objet JSON contenant des informations sur l’organisme d’évaluation de la conformité qui a certifié la solution de portefeuille, le numéro de certification, le cas échéant, et d’autres informations pertinentes concernant la certification;

— une revendication 'client_status', contenant deux sous-champs:

— 'status': une référence à la liste d’états telle que définie à l’appendice E de la spécification OID4VCI, qui représente l’état de révocation de l’instance de portefeuille. Voir la section e) ci-dessous pour plus de détails;

— 'exp': une NumericDate, telle que spécifiée dans la RFC 7519, indiquant jusqu’à quel moment le fournisseur de portefeuille maintiendra l’état de révocation à l’index de la liste d’états référencé dans le champ 'status';

— la revendication 'exp' définie à l’appendice E de la spécification OID4VCI.

— REMARQUE: la revendication 'client_status.status' dans une attestation d’instance de portefeuille représente l’état de révocation de l’instance de portefeuille, et non l’état de révocation de l’attestation elle-même. Comme décrit dans le paragraphe R_WIA-1 ci-dessous, un fournisseur de portefeuille peut décider de limiter la portée de chaque attestation d’instance de portefeuille à un serveur d’autorisation spécifique en se fondant sur le fait que toutes les attestations envoyées à ce serveur contiennent la même valeur d’index dans l’entrée 'client_status.status'.

— REMARQUE: la valeur 'idx' dans la revendication 'status' peut être utilisée comme identifiant unique (pairwise) de l’instance de portefeuille et de l’unité de portefeuille.

— C_WIA-2: une attestation d’instance de portefeuille devrait comprendre également la revendication 'wallet_link' définie à l’appendice E de la spécification OID4VCI, la valeur de cette revendication étant un URI permettant d’obtenir des informations supplémentaires sur la solution de portefeuille.

— C_WIA-3: un serveur d’autorisation ne doit pas interpréter le paramètre 'exp' au niveau le plus élevé d’une attestation d’instance de portefeuille comme étant la fin de la période de maintien de la révocation de l’instance de portefeuille.

— REMARQUE: le paramètre 'exp' au niveau le plus élevé d’une attestation d’instance de portefeuille indique à quel moment l’attestation proprement dite expire.

— C_KA-1: une attestation de clé comprend:

— les revendications 'key_storage' et 'user_authentification' définies à l’appendice D de la spécification OID4VCI.

— Les attributs 'key_storage' et 'user_authentification' doivent avoir la valeur 'iso_18045_high' lorsqu’une attestation de clé mentionne un WSCD;

— la revendication «certification» définie à l’appendice D de la spécification OID4VCI, contenant une URL permettant d’obtenir des informations sur la certification obtenue par le WSCD ou le magasin de clés, à titre indicatif le schéma tel que Common Criteria ou GlobalPlatform, les exigences évaluées telles que le profil de protection applicable et le niveau d’évaluation.

— Ces informations permettent de déterminer si le stockage de la clé est un WSCD;

— une revendication 'key_storage_status', contenant deux sous-champs:

— 'status': une référence à la liste d’états telle que définie à l’appendice D.1 de la spécification OID4VCI. La valeur représente soit l’état de révocation du WSCD ou du type de magasin de clés utilisé pour stocker les clés attestées, soit, dans le cadre de l’option d’index per-key-attestation, l’état de révocation du WSCD ou du magasin de clés d’une unité de portefeuille individuelle. Voir R_KA_1 ci-dessous pour les options d’attribution d’index disponibles;

— 'exp': une NumericDate, telle que spécifiée dans la RFC 7519, indiquant jusqu’à quel moment le fournisseur de portefeuille maintiendra l’état de révocation à l’index de la liste d’états référencé dans le champ 'status';

— la revendication 'exp' définie à l’appendice D de la spécification OID4VCI.

— REMARQUE concernant la valeur 'idx' dans la revendication 'key_storage_status.status' d’une attestation de clé: lorsque le fournisseur de portefeuille utilise l’option 'type-shared index' (voir R_KA_1 ci-dessous), toutes les attestations de clé se rapportant au même type de WSCD ou de magasin de clés partagent le même index de la liste d’états. Par conséquent, la valeur 'idx' n’est pas unique pour chaque unité de portefeuille. À l’inverse, lorsque le fournisseur de portefeuille utilise l’option 'per-key-attestation index', la valeur 'idx' est unique pour chaque unité de portefeuille (ou unique en mode 'pairwise' pour chaque émetteur de justificatifs d’identité). Toutefois, dans tous les cas, un émetteur de justificatifs d’identité ne doit pas utiliser la valeur 'idx' dans une attestation de clé comme identifiant d’unité de portefeuille, mais doit utiliser plutôt la valeur 'idx' dans une attestation d’instance de portefeuille.

— C_KA-2: lorsqu’une attestation de clé est envoyée dans un type de preuve 'attestation', elle doit également comprendre un c_nonce valide, tel que défini à l’appendice F.3 de la spécification OID4VCI.

— C_KA-3: un émetteur de justificatifs d’identité ne doit pas interpréter le paramètre 'exp' au niveau le plus élevé d’une attestation de clé comme étant la fin de la période de maintien de la révocation du WSCD ou du magasin de clés.

— REMARQUE: le paramètre 'exp' au niveau le plus élevé d’une attestation de clé indique à quel moment l’attestation de clé proprement dite expire.

d) Exigences relatives au cycle de vie

— La présente annexe spécifie les paramètres de métadonnées suivants de l’émetteur de justificatifs d’identité:

— 'preferred_client_status_period': FACULTATIF. Un nombre entier indiquant la durée restante préférée de maintien de l’état de l’attestation d’instance de portefeuille à présenter par l’unité de portefeuille lors de la délivrance, en secondes. La durée restante de maintien de l’état est définie comme la valeur de 'client_status.exp' dans l’attestation, moins l’heure de réception de l’attestation.

— 'preferred_key_storage_status_period': FACULTATIF. Un nombre entier indiquant la durée restante préférée de maintien de l’état de l’attestation de clé à présenter par l’unité de portefeuille lors de la délivrance, en secondes. La durée restante de maintien de l’état est définie comme la valeur de 'key_storage_status.exp' dans l’attestation, moins l’heure de réception de l’attestation.

— LC_WIA-1: un serveur d’autorisation peut communiquer ses préférences en ce qui concerne la durée restante de maintien de l’état dans les attestations d’instance de portefeuille en intégrant le paramètre de métadonnées 'preferred_client_status_period' dans son point de terminaison de métadonnées d’émetteur de justificatifs d’identité, comme indiqué à la section 12.2.2 de la spécification OID4VCI.

— LC_WIA-1.1: ce champ doit être placé au niveau le plus élevé des métadonnées de l’émetteur de justificatifs d’identité.

— LC_WIA_2: un serveur d’autorisation ne doit pas interpréter le paramètre 'exp' au niveau le plus élevé d’une attestation d’instance de portefeuille comme étant la fin de la période de maintien de la révocation de l’instance de portefeuille.

— LC_WIA_3: lorsqu’un fournisseur de portefeuille appose sa signature ou son cachet sur une attestation d’instance de portefeuille, il doit maintenir l’état de révocation de l’instance de portefeuille concernée jusqu’à ce que la 'wallet_instance_status.exp' indiquée dans cette attestation d’instance de portefeuille soit écoulée.

— LC_KA-1: si une attestation de clé est nécessaire, un émetteur de justificatifs d’identité peut communiquer ses préférences en ce qui concerne la durée restante de maintien de l’état dans les attestations de clé en intégrant le paramètre de métadonnées spécifié plus haut 'preferred_key_storage_status_period' dans son point de terminaison de métadonnées d’émetteur de justificatifs d’identité, comme indiqué à la section 12.2.2 de la spécification OID4VCI.

— LC_KA-1.1: ce champ doit être placé à l’intérieur de l’objet 'key_attestations_required' comme indiqué à la section 12.2.4 de la spécification OID4VCI.

— LC_KA-2: un fournisseur de portefeuille doit choisir la période de validité technique des attestations de clé qu’il délivre.

— LC_KA-3: lorsqu’un fournisseur de portefeuille appose sa signature ou son cachet sur une attestation de clé, il doit maintenir l’état de révocation du WSCD ou du magasin de clés jusqu’à ce que la 'key_storage_status.exp' indiquée dans cette attestation de clé soit écoulée.

— LC_GEN-1: un fournisseur de portefeuille doit veiller à ce qu’une unité de portefeuille puisse toujours présenter des attestations d’unité de portefeuille et des attestations de clé dont les 'client_status.exp' et 'key_storage_status.exp' (respectivement) sont situées au moins 31 jours plus tard au moment de leur présentation à un serveur d’autorisation ou à un émetteur de justificatifs d’identité.

— REMARQUE: cela garantit que les fournisseurs de données d’identification personnelle peuvent s’appuyer sur un chaînage de révocation sans être contraints de délivrer des données d’identification personnelle à courte durée de vie.

— LC_GEN-2: un fournisseur de portefeuille doit veiller à ce qu’une unité de portefeuille récupère les métadonnées de l’émetteur de justificatifs d’identité lors de la délivrance.

— LC_GEN_2.1: si un champ 'preferred_key_storage_status_period' est inclus dans ces métadonnées, l’unité de portefeuille doit envoyer une attestation de clé pour laquelle la valeur ('key_storage_status.exp' – date actuelle) – 'preferred_key_storage_status_period' est la plus proche possible de zéro sans être négative. Si l’unité de portefeuille ne dispose pas d’une telle attestation de clé, elle doit obtenir du fournisseur de portefeuille une nouvelle attestation de clé qui satisfait à la condition 'key_storage_status.exp' – date actuelle ≥ 'preferred_key_storage_status_period'.

— LC_GEN_2.2: si un champ 'preferred_client_status_period' est inclus dans ces métadonnées, l’unité de portefeuille doit envoyer une attestation d’instance de portefeuille pour laquelle la valeur ('client_status.exp' – date actuelle) – 'preferred_client_status_period' est la plus proche possible de zéro sans être négative. Si l’unité de portefeuille ne dispose pas d’une telle attestation d’instance de portefeuille, elle doit obtenir du fournisseur de portefeuille une nouvelle attestation d’instance de portefeuille qui satisfait à la condition 'client_status.exp' – date actuelle ≥ 'preferred_client_status_period'.

— LC_GEN-3: la période de validité technique des données d’identification personnelle doit prendre fin avant le 'client_status.exp' de l’attestation d’instance de portefeuille et avant le 'key_storage_status.exp' de l’attestation de clé envoyées au fournisseur de données d’identification personnelle lors du processus de délivrance.

— LC_GEN-4: un fournisseur de données d’identification personnelle ayant une période de validité technique de plus de 24 heures doit vérifier l’état de révocation de l’attestation d’instance de portefeuille et de l’attestation de clé reçues lors de la délivrance au moins une fois toutes les 24 heures pendant la période de validité technique des données d’identification personnelle. Lorsque l’une ou l’autre de ces attestations est révoquée, le fournisseur doit révoquer les données d’identification personnelle.

e) Exigences en matière de révocation

— R_GEN-1: un fournisseur de portefeuille doit utiliser des listes d’états des jetons (définies dans la spécification Token Status List de l’IETF) comme mécanisme de révocation tant pour les attestations de clé que pour les attestations d’instance de portefeuille, comme indiqué respectivement dans les appendices D et E de la spécification OID4VCI.

— REMARQUE: pour améliorer la modularité de ses listes d’états, un fournisseur de portefeuille peut recourir aux optimisations suivantes:

— diviser la liste d’états en plusieurs sections, lorsque les fournisseurs de portefeuille comptent un nombre important d’utilisateurs et d’attestations délivrées. Il existe beaucoup de stratégies de sectionnement, fondées par exemple sur une taille fixe ou sur une période donnée. La stratégie de sectionnement est laissée à l’appréciation du fournisseur de portefeuille. Les critères à prendre en considération peuvent comprendre la taille des listes d’états à télécharger et le respect de la vie privée de l’utilisateur;

— prévoir plusieurs listes d’états;

— comprimer les listes d’états pour en réduire la taille.

— R_WIA-1: un fournisseur de portefeuille peut attribuer la même valeur à la revendication 'idx' dans la revendication 'client_status.status' de toutes les attestations d’instance de portefeuille qu’une unité de portefeuille donnée présente au même serveur d’autorisation. Cette option est appelée 'per-issuer reuse'. Si cette option est utilisée, les conditions suivantes s’appliquent:

— R_WIA-1.1: l’unité de portefeuille doit conserver la trace de la valeur d’index qu’elle a utilisée pour chaque serveur d’autorisation avec lequel elle a précédemment interagi et doit demander une attestation d’instance de portefeuille contenant cette même valeur d’index lorsqu’elle interagit à nouveau avec le même serveur d’autorisation.

— R_WIA-1.2: lorsqu’un fournisseur de portefeuille reçoit une demande d’attestation d’instance de portefeuille contenant une valeur d’index spécifique, il doit vérifier que l’unité de portefeuille à l’origine de la demande a reçu cette valeur d’index au préalable avant de délivrer une nouvelle attestation d’instance de portefeuille avec cette valeur d’index.

— R_WIA-1.3: l’unité de portefeuille ne doit pas réutiliser la même valeur d’index pour ses interactions avec d’autres serveurs d’autorisation.

— REMARQUE: si l’option 'per-issuer reuse' est utilisée, le fournisseur de portefeuille sera en mesure de déterminer le nombre de serveurs d’autorisation avec lesquels une unité de portefeuille a interagi et la fréquence à laquelle elle interagit avec chacun d’eux.

— R_WIA-2: dans sa politique relative au respect de la vie privée, le fournisseur de portefeuille doit indiquer s’il utilise l’option 'per-issuer reuse' pour la révocation des instances de portefeuille.

— R_WIA-3: si un fournisseur de portefeuille n’utilise pas l’option 'per-issuer reuse', il doit attribuer une valeur d’index nouvelle et non associable à chaque attestation d’instance de portefeuille qu’il délivre.

— R_WIA-4: si une unité de portefeuille doit être révoquée, le fournisseur de portefeuille doit révoquer les valeurs d’index dans la revendication 'client_status.statu' de toutes les attestations d’instance de portefeuille associées à cette unité de portefeuille.

— R_WIA-5: un fournisseur de portefeuille doit tenir compte de l’échelle de son déploiement et de l’architecture sous-jacente lorsqu’il détermine la taille des listes d’états de ses attestations d’instance de portefeuille, en veillant à ce qu’elles soient suffisamment grandes pour empêcher la corrélation et protéger la vie privée des utilisateurs. Dans la mesure du possible, une liste d’états doit se rapporter au minimum à 10 000 attestations.

— R_KA_1: un fournisseur de portefeuille doit choisir l’une des options d’assignation d’index suivantes pour la revendication 'key_storage_status.status' dans une attestation de clé:

— option 1, appelée 'type-shared index', dans laquelle toutes les attestations de clé attestant des clés stockées dans le même type de WSCD ou de magasin de clés contiennent la même valeur d’index dans 'key_storage_status.status';

— option 2, appelée 'per-key-attestion index', dans laquelle une attestation de clé attestant des clés stockées dans un WSCD donné ou un magasin de clés donné contient une valeur d’index unique (pairwise) dans 'key_storage_status.status'.

— REMARQUE: lorsqu’un fournisseur de portefeuille utilise l’option 1, une action de révocation unique annule toutes les attestations de clés du type concerné pour toutes les unités de portefeuille. En outre, étant donné que toutes les attestations de clé pour un même type de WSCD ou de magasin de clés partagent un index unique de la liste d’états, le nombre d’entrées dans cette liste pour une attestation de clé correspond au nombre de types de WSCD ou de magasins de clés pris en charge par le fournisseur de portefeuille, et non au nombre d’unités de portefeuille déployées. Par conséquent, les considérations relatives à la protection de la vie privée qui motivent la taille minimale de la liste d’états dans le cas des instances de portefeuille ne s’appliquent pas aux listes d’états des attestations de clé dans le cadre de l’option 1, à condition qu’un nombre suffisant d’unités de portefeuille utilise le même type de WSCD ou de magasin de clés.

— REMARQUE: lorsqu’un fournisseur de portefeuille utilise l’option 2, chaque index représente l’état de révocation du WSCD ou du magasin de clés spécifique attesté dans cette attestation de clé.

— REMARQUE: lorsqu’un fournisseur de portefeuille utilise l’option 2, un WSCD ou un magasin de clés spécifique peut également être révoqué à la demande de l’utilisateur.

— R_KA-2: lorsqu’un fournisseur de portefeuille utilise l’option 2, il peut, à titre facultatif, utiliser l’option 'per-issuer reuse' décrite dans le paragraphe R_WIA-1. Si le fournisseur de portefeuille utilise cette option, les exigences des paragraphes R_WIA-1 à R_WIA-3 s’appliquent par analogie.

— R_KA-3: si un fournisseur de portefeuille utilise l’option 2, il doit tenir compte de l’échelle de son déploiement et de l’architecture sous-jacente lorsqu’il détermine la taille des listes d’états de ses attestations de clé, en veillant à ce qu’elles soient suffisamment grandes pour empêcher la corrélation et protéger la vie privée des utilisateurs. Dans la mesure du possible, une liste d’états doit se rapporter au minimum à 10 000 attestations de clé.

— R_KA-4: si un fournisseur de portefeuille utilise l’option 1 ('type-shared index'), il ne doit révoquer une entrée 'key_storage_status.status' que si le type de WSCD ou de magasin de clés présente une vulnérabilité en matière de sécurité.

f) Exigences relatives aux algorithmes de signature

— SA-1: pour signer les attestations d’instance de portefeuille, les attestations de clé, les preuves de possession connexes et les listes d’états des jetons, l’un des algorithmes suivants doit être utilisé:

— ES256 (ECDSA avec SHA-256 et P-256)

— ES384 (ECDSA avec SHA-384 et P-384)

— ES512 (ECDSA avec SHA-512 et P-521)

— SA-2: un fournisseur de portefeuille doit choisir lequel des algorithmes mentionnés dans le paragraphe SA-1 il utilisera.

— SA-3: un serveur d’autorisation ou un émetteur de justificatifs d’identité (tels que définis dans la spécification OID4VCI) doit prendre en charge tous les algorithmes mentionnés dans le paragraphe SA-1.

Annexe II

ANNEXE II — LISTE DES NORMES VISÉES À L’ARTICLE 8

Les spécifications techniques énoncées dans les paragraphes 2 à 6 d’ETSI TS 119 472-1 V1.2.1 (2026-02) s’appliquent, moyennant les adaptations suivantes:

1) 2.1. Références normatives

— [16] ETSI EN 319 412-1 V1.6.1 (2025-06): «Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 1: Overview and common data structures (Signatures électroniques et infrastructures de confiance (ESI) - profils de certificat; partie 1: présentation générale et structures de données communes)».

— [17] ETSI TS 119 412-6 V1.1.1 (2025-09): «Electronic Signatures and Trust Infrastructures (ESI); Certificate Profiles; Part 6: Certificate profile requirements for PID, Wallet, EAA, QEAA, and PSBEAA providers [Signatures électroniques et infrastructures de confiance (ESI); profils de certificat; partie 6: Exigences applicables aux profils de certificats pour les fournisseurs de données d’identification personnelle (PID), de portefeuilles, d’attestations électroniques d’attributs (EAA), d’attestations électroniques qualifiées d’attributs (QEAA) et d’attestations électroniques d’attributs délivrées par un organisme du secteur public (PSBEAA)]».

— [25] Token Status List (TSL) de l’IETF, draft-ietf-oath-status-list-20: «Token Status List», 20 avril 2026.

2) 4.2.11.1 General requirements

— EAA-4.2.11.1-06: lorsqu’un élément d’état est utilisé pour des données d’identification personnelle, des attestations électroniques qualifiées d’attributs ou des attestations électroniques d’attributs délivrées par un organisme du secteur public responsable d’une source authentique ou pour son compte, il indique uniquement si l’attestation est révoquée ou non et ne prend en charge aucune autre valeur d’état telle que la suspension.

— EAA-4.2.11.1-06.1: lorsqu’une attestation est révoquée, sa révocation est permanente.

3) 4.2.13 EAA short-lived

— EAA-4.2.13-03: lorsque des attestations électroniques d’attributs à faible durée de validité sont délivrées pour 24 heures ou moins, aucune révocation n’est exigée.

4) 4.6.3. Requirements for EU EAA issued by or on behalf of a public body responsible for an authentic source (PuB-EAA)

— PuB-EAA-4.6.2-03: vide.

— Pub-EAA-4.6.2-04: vide.

— PuB-EAA-4.6.3-03: La signature numérique PuB-EAA devrait contenir le certificat qualifié à l’appui de la signature numérique PuB-EAA.

— PuB-EAA-4.6.3-04: Le certificat qualifié à l’appui de la signature numérique PuB-EAA doit satisfaire aux exigences du paragraphe 8 d’ETSI TS 119 412-6 v1.1.1 et doit contenir le QcType qcStatement tel que défini dans ETSI EN 319 412-5 v2.5.1, la valeur id-etsi-qct-eidaspsbeaa étant définie comme suit:

id-etsi-qct-eidaspsbeaa OBJECT IDENTIFIER: = {id-etsi-eidas2-qct-extensions 3} — Certificat visé à l’article 45 septies, paragraphe 1, point b), à l’appui de la signature électronique qualifiée ou du cachet électronique qualifié de l’organisme du secteur public visé à l’article 3, point 46), du règlement (UE) no 910/2014.

5) 5.2.10.1 General requirements

— EAA-5.2.10.1-04: vide.

— EAA-5.2.10.1-05: vide.

— EAA-5.2.10.1-06: Le membre «status» peut contenir le membre «status_list» comme indiqué au paragraphe 6.2 du projet draft-ietf-oauth-status-list-20 de l’IETF[25].

— EAA-5.2.10.1-07: vide.

— EAA-5.2.10.1-08: vide.

— EAA-5.2.10.1-09: vide.

— EAA-5.2.10.1-10: vide.

— EAA-5.2.10.1-11: vide.

— EAA-5.2.10.1-12: vide.

6) 6.2.10.1 General requirements

— EAA-6.2.10.1-01: lorsqu’une attestation électronique d’attributs conforme à la norme ISO/IEC mdoc utilise le mécanisme de liste d’états d’attestations tel que défini dans EAA-6.2.10.1-02.2 ou le mécanisme de liste de révocation d’attestations tel que défini dans EAA-6.2.10.1-02.3, son objet de sécurité mobile (MSO) contient la structure d’état, telle que spécifiée dans EAA-6.2.10.1-17, qui contient les informations de révocation du MSO.

— EAA-6.2.10.1-01.1: lorsque l’élément d’état met en œuvre le mécanisme de liste d’identifiants, il contient l’élément identifier_list figurant dans EAA-6.2.10.1-11.

— EAA-6.2.10.1-01.2: lorsque l’élément d’état met en œuvre le mécanisme de liste d’états, il contient l’élément status_list figurant dans EAA-6.2.10.1-13.

— REMARQUE:

— La structure d’état contient une référence à une liste de révocation de MSO.

— La liste de révocation de MSO est une structure COSE_Sign1 qui indique si un MSO donné est révoqué ou non.

— La structure d’état contient toutes les informations nécessaires pour permettre à la partie utilisatrice de portefeuille de déterminer si la liste de révocation de MSO est authentique.

— EAA-6.2.10.1-02: le fournisseur de données d’identification personnelle, le fournisseur d’attestations électroniques d’attributs qualifiées ou le fournisseur d’attestations électroniques d’attributs délivrées par un organisme du secteur public responsable d’une source authentique ou pour son compte utilise l’une des méthodes suivantes pour la révocation des données d’identification personnelle, des attestations électroniques d’attributs qualifiées ou des attestations électroniques d’attributs délivrées par un organisme du secteur public responsable d’une source authentique ou pour son compte:

— EAA-6.2.10.1-02.1: lorsqu’il délivre des attestations électroniques d’attributs à faible durée de validité pour une période inférieure ou égale à 24 heures, la révocation n’est pas nécessaire.

— EAA-6.2.10.1-02.2: utiliser un mécanisme de liste d’états d’attestation pour encoder les informations de révocation sous forme de liste d’états.

— EAA-6.2.10.1-02.2.1: le mécanisme de liste d’états révoque un MSO si le bit de la position de bit définie par l’émetteur dans le MSO est activé dans la liste d’états.

— EAA-6.2.10.1-02.2.2: le mécanisme de liste d’états est précisé dans la spécification relative à la liste d’états des jetons (draft-ietf-oauth-status-list-20).

— EAA-6.2.10.1-02.3: utiliser un mécanisme de liste de révocation d’attestations pour encoder les informations de révocation sous forme de liste d’identifiants.

— EAA-6.2.10.1-02.3.1: le mécanisme de liste d’identifiants révoque un MSO si l’identifiant défini par l’émetteur dans le MSO figure sur la liste d’identifiants.

— EAA-6.2.10.1-02.3.2: EAA-6.2.10.1-06, EAA-6.2.10.1-08, EAA-6.2.10.1-09, EAA-6.2.10.1-10 et EAA-6.2.10.1-11 précisent le mécanisme de liste d’identifiants, sur la base des exigences de la spécification relative à la liste d’états des jetons, y compris les points communs entre le mécanisme de liste d’états et le mécanisme de liste d’identifiants.

— EAA-6.2.10.1-03: lorsqu’un élément d’état est utilisé pour des données d’identification personnelle, des attestations électroniques qualifiées d’attributs ou des attestations électroniques d’attributs délivrées par un organisme du secteur public responsable d’une source authentique ou pour son compte, l’état «révoqué» doit être utilisé exclusivement.

— EAA-6.2.10.1-03.1: pour une liste d’états, cela signifie que seules les valeurs 'valid' et 'invalid', telles que précisées dans la spécification relative à la liste d’états des jetons, doivent être utilisées.

— EAA-6.2.10.1-03.2: pour la liste d’identifiants, seuls les MSO révoqués, par opposition aux MSO provisoirement suspendus, doivent être inscrits sur la liste d’identifiants.

— EAA-6.2.10.1-04: lorsqu’un MSO est révoqué, sa révocation est permanente.

— EAA-6.2.10.1-05: la vérification de la liste de révocation du MSO est facultative pour la partie utilisatrice de portefeuille et, le cas échéant, la vérification doit être conforme aux exigences de vérification précisées dans la spécification relative à la liste d’états des jetons et la spécification relative à la structure d’état énoncée dans EAA-6.2.10.1-01.

— EAA-6.2.10.1-05.1: lorsqu’une partie utilisatrice de portefeuille doit être en mesure de vérifier l’état de révocation des données d’identification personnelle ou des attestations électroniques d’attributs, elle doit prendre en charge à la fois le mécanisme de liste d’états d’attestations et le mécanisme de liste de révocation d’attestations prévus dans EAA-6.2.10.1-02.

— EAA-6.2.10.1-06: le identifier_list et le status_list du MSO peuvent contenir l’élément de certificat.

— EAA-6.2.10.1-06.1: lorsque l’élément de certificat est présent, il doit contenir un certificat contenant la clé publique ayant apposé la signature ou le cachet sur le certificat de plus haut niveau dans l’élément x5chain de la structure de liste de révocation du MSO.

— EAA-6.2.10.1-06.1.1: la partie utilisatrice de portefeuille doit utiliser ce certificat comme ancre de confiance pour vérifier l’élément x5chain de la structure de liste de révocation du MSO.

— EAA-6.2.10.1-06.2: en l’absence d’élément de certificat, le certificat avec lequel a été signé le certificat dans l’élément x5chain du MSO doit être utilisé pour apposer la signature ou le cachet sur le certificat de niveau supérieur dans l’élément x5chain de la structure de liste de révocation du MSO.

— EAA-6.2.10.1-06.2.1: l’instance de la partie utilisatrice de portefeuille doit utiliser ce certificat comme ancre de confiance pour vérifier l’élément x5chain de la structure de liste de révocation du MSO.

— EAA-6.2.10.1-07: conformément à la spécification de liste d’états des jetons, une liste de révocation du MSO doit être mise en œuvre sous forme de jeton de liste d’états au format CWT.

— EAA-6.2.10.1-08: pour la liste de révocation du MSO: pour le mécanisme de la liste d’identifiants et le mécanisme de liste d’états, les exigences applicables sont les suivantes:

— la revendication exp doit être présente.

— la revendication ttl doit être présente.

— la revendication aggregation_uri dans la revendication IdentifierList ou StatusList peut être présente et le fournisseur de données d’identification personnelle, le fournisseur d’attestations électroniques qualifiées d’attributs ou le fournisseur d’attestations électroniques d’attributs délivrées par un organisme du secteur public responsable d’une source authentique ou pour son compte peut utiliser la revendication aggregation_uri pour indiquer que le mécanisme d’agrégation tel que spécifié dans la spécification de la liste d’états des jetons est pris en charge.

— le CWT doit être un objet COSE_Sign1 utilisant l’un des algorithmes de signature suivants pour calculer la signature:

a) 'ES256' (ECDSA avec courbe NIST P-256 et SHA-256);

b) 'ES384' (ECDSA avec courbe NIST P-384 et SHA-384);

c) 'ES512' (ECDSA avec courbe NIST P-521 et SHA-512);

d) 'ESB256' (ECDSA avec courbe NIST brainpoolP256r1 et SHA-256);

e) 'ESB384' (ECDSA avec courbe NIST brainpoolP384r1 et SHA-384);

f) 'ESB512' (ECDSA avec courbe NIST brainpoolP512r1 et SHA-512);

— le CWT doit contenir la x5chain dans l’en-tête protégé qui contient le certificat ou la chaîne de certificats afin de vérifier la signature de la liste de révocation du MSO.

— l’utilisation étendue de la clé de l’identifiant d’objet précisé dans la spécification de la liste d’états des jetons peut servir au certificat de signature de la liste d’états et au certificat de signature de la liste d’identifiants et les instances de parties utilisatrices de portefeuille peuvent prendre en charge l’utilisation étendue de la clé des identifiants d’objet précisés dans la spécification de la liste d’états des jetons et pour l’identifiant d’objet, le fournisseur d’attestations électroniques d’attributs qualifiées ou le fournisseur d’attestations électroniques d’attributs délivrées par un organisme du secteur public ou pour son compte ne doivent pas rendre critique le champ d’utilisation étendue de la clé lorsqu’ils utilisent l’OID d’utilisation étendue de la clé précisé dans la spécification de la liste d’états des jetons.

— EAA-6.2.10.1-09: par dérogation aux exigences de la spécification de la liste d’états des jetons, pour le mécanisme de liste d’identifiants, les exigences applicables sont les suivantes:

— la valeur de la revendication type doit être 'application/identifierlist+cwt';

— la revendication StatusList ne doit pas être présente dans l’ensemble de revendications CWT;

— la structure IdentifierList définie dans EAA-6.2.10.1-11 doit être présente en tant que revendication dans l’ensemble de revendications CWT qui utilise la clé 65530.

— EAA-6.2.10.1-10: la structure IdentifierList doit être une structure CBOR avec le CDDL suivant:

IdentifierList = {

'identifiers': { * Identifier => IdentifierInfo },

? 'aggregation_uri': Aggregation_uri

* tstr => RFU

}

IdentifierInfo = { tstr/int => RFU }

Identifier = bstr

Aggregation_uri = tstr

— EAA-6.2.10.1-10.1: lorsque l’identifiant dans la IdentifierList est présent, le MSO qui contient l’identifiant dans l’élément d’état est révoqué.

— EAA-6.2.10.1-10.2: la revendication aggregation_uri est précisée dans la section 9.2 de la spécification de la liste d’états des jetons.

— EAA-6.2.10.1-10.3: le type de contenu de la liste d’identifiants doit être 'application/identifierlist+cwt' tel qu’énoncé dans les exigences figurant dans la section 8.2 de la spécification de la liste d’états des jetons.

— EAA-6.2.10.1-11: les exigences applicables à l’élément identifier_list dans le MSO sont les suivantes (voir EAA-6.2.10.1-17).

— EAA-6.2.10.1-11.1: l’élément identifier_list est une structure CBOR avec le CDDL suivant:

IdentifierListInfo = {

'id': Identifier ,

'uri': URI,

? 'certificate': Certificate

* tstr => RFU

}

URI = tstr

Certificate = bstr

— EAA-6.2.10.1-11.2: REV-11.2: pour éviter toute éventuelle utilisation de l’identifiant comme corrélation dans différentes présentations, il doit être unique pour chaque MSO.

— EAA-6.2.10.1-12: les exigences applicables à la liste d’états sont les suivantes:

— EAA-6.2.10.1-12.1: l’élément bits de la structure de StatusList doit être fixé à 1.

— EAA-6.2.10.1-13: les exigences applicables à l’élément status_list dans le MSO sont les suivantes (voir EAA-6.2.10.1-17).

— EAA-6.2.10.1-13.1: l’élément status_list doit respecter les exigences applicables à la structure StatusListInfo précisées dans la spécification relative à la liste d’états des jetons et l’élément de certificat facultatif défini dans EAA-6.2.10.1-06 doit être ajouté.

— EAA-6.2.10.1-13.2: pour éviter toute éventuelle utilisation de l’index d’état comme corrélation dans différentes présentations, chaque MSO doit avoir une combinaison d’index d’état et d’URI unique.

— EAA-6.2.10.1-14: le fournisseur de portefeuille doit utiliser la deuxième (EAA-6.2.10.1-02.2) ou la troisième (EAA-6.2.10.1-02.3) des méthodes spécifiées dans EAA-6.2.10.1-02 pour la révocation d’une attestation d’instance de portefeuille (WIA) et pour la révocation d’une attestation de clé (KA).

— EAA-6.2.10.1-15: le fournisseur de portefeuille met en œuvre les mécanismes de révocation d’attestation spécifiés dans EAA-6.2.10.1-02 dans sa solution de portefeuille.

— EAA-6.2.10.1-16: le fournisseur de données d’identification personnelle et le fournisseur d’attestations électroniques d’attributs doivent prendre en charge à la fois le mécanisme de liste d’états d’attestations et le mécanisme de liste de révocation d’attestations spécifiés dans EAA-6.2.10.1-02 pour vérifier l’état de révocation d’une attestation d’instance de portefeuille (WIA) et d’une attestation de clé (KA).

— EAA-6.2.10.1-17: la structure d’état dans le MSO doit être une structure CBOR avec le CDDL suivant:

Status = {

? 'identifier_list' : IdentifierListInfo,

? 'status_list': StatusListInfo,

* tstr => RFU

}

Annexe III

ANNEXE III — SPÉCIFICATIONS TECHNIQUES VISÉES À L’ARTICLE 10

— Spécifications techniques:

— paragraphe 4.2.5 de l’ETSI TS 119 472-3 V1.1.1 (2026-03).

Annexe IV

ANNEXE IV — FORMATS DES SIGNATURES ET CACHETS VISÉS À L’ARTICLE 12

1. Format de signature ou de cachet obligatoire:

a) PAdES (PDF Advanced Electronic Signature) comme spécifié dans ETSI EN 319 142-1 V1.2.1 (2024-01); «Electronic Signatures and Infrastructures (ESI); PAdES digital signatures; Part 1: Building blocks and PAdES baseline signatures [Signatures électroniques et infrastructures de confiance (ESI) - Signatures numériques PAdES; partie 1: blocs de base et signatures de référence PAdES].»

2. Liste des formats facultatifs de signature ou de cachet:

a) XAdES comme spécifié dans la norme «ETSI EN 319 132-1 V1.2.1 (2022-02) Signatures électroniques et infrastructures (ESI) — Signatures numériques au format XAdES — Partie 1: blocs de construction et signatures au format de base XAdES» pour la signature au format XML;

b) JAdES comme spécifié dans la norme «ETSI TS 119 182-1 V1.2.1 (2024-07) Signatures électroniques et infrastructures (ESI) — Signatures numériques au format JAdES — Partie 1: blocs de construction et signatures au format de base JAdES» pour la signature au format JSON;

c) CAdES (signature électronique avancée au format CMS) comme spécifié dans la norme «ETSI EN 319 122-1 V1.3.1 (2023-06) Signatures électroniques et infrastructures (ESI) — Signatures numériques au format CAdES — Partie 1: blocs de construction et signatures au format de base CAdES» pour la signature au format CMS;

d) ASiC (conteneur de signatures associées) comme spécifié dans les normes «ETSI EN 319 162-1 V1.1.1 (2016-04) Signatures électroniques et infrastructures (ESI) — Conteneurs de signatures associées (ASiC) — Partie 1: blocs de construction et conteneurs de base ASiC» et «ETSI EN 319 162-2 V1.1.1 (2016-04) Signatures électroniques et infrastructures (ESI) — Conteneurs de signatures associées (ASiC) — Partie 2: conteneurs ASiC complémentaires» pour la signature de conteneurs.

3. Interface de programmation d’application:

ETSI TS 119 432 v1.3.1 (2026-03) paragraphes 6.4.3, A.6, A.7 et A.8.

Annexe VI

ANNEXE VI — LABEL DE CONFIANCE DE L’UE POUR LE PORTEFEUILLE D’IDENTITÉ NUMÉRIQUE EN COULEUR

Annexe VII

ANNEXE VII — LABEL DE CONFIANCE DE L’UE POUR LE PORTEFEUILLE D’IDENTITÉ NUMÉRIQUE EN NOIR ET BLANC

Annexe VIII

ANNEXE VIII — DONNÉES DU LABEL DE CONFIANCE DE L’UE POUR LE PORTEFEUILLE D’IDENTITÉ NUMÉRIQUE

| Données | Description | Encodage | Statut

| TrustMarkResourceURL | URL des ressources graphiques du label de confiance de l’UE pour le portefeuille d’identité numérique et des ressources d’information des utilisateurs dans l’interface utilisateur du portefeuille. | URL | Obligatoire

| ListOfCertifiedWalletsURL | URL de la liste publique des solutions de portefeuille certifiées dans l’UE, telle que prévue par le règlement d’exécution (UE) 2025/849 de la Commission. | URL | Obligatoire

| ListOfCertifiedWalletsQRCode | Code QR contenant les informations de ListOfCertifiedWalletsURL | ISO-8859-1 Byte mode QR code | Facultatif

| WalletSolutionInfoPageURL | URL de la page d’information de la solution de portefeuille certifiée de ListOfCertifiedWalletsURL complétée par un '?' et l’identifiant WalletSolutionID de la solution de portefeuille. | URL | Obligatoire

| WalletSolutionInfoPageQRCode | Code QR contenant les informations de WalletSolutionInfoPageURL | ISO-8859-1 Byte mode QR code | Facultatif

| WalletVerifierToolURL * | URL renvoyant au point de terminaison de l’outil de vérification du portefeuille /.well-known/openid-credential-issuer utilisé pour extraire les métadonnées du fournisseur d’attestation. | URL | Facultatif