This matrix extracts all requirements related to trusted lists, participant registration, and trust evaluation from Annex 2 (High-Level Requirements) of the EUDI Wallet Architecture and Reference Framework version 2.9.0 (ARF v2.9.0). This repository aligns with ARF v2.9.0.
Terminology (ARF v2.9.0): Where validation/consumption of trust anchors is described (e.g. OIA_12, RPA_04), the ARF uses LoTE (List of Trusted Entities). Publication artifacts may still be referred to as Trusted Lists (TL) where aligned with ETSI TS 119 612 / eIDAS (e.g. QEAA Provider national trusted lists). WUA is an umbrella term covering WIA (Wallet Instance Attestation) and KA (Key Attestation); see ARF Topic 9 and Technical Specification 3 V1.5.
Note on Reg_12–Reg_18: In ARF v2.9.0 these HLRs are empty; access certificate policy requirements (including Certificate Transparency) are specified in ETSI TS 119 411-8 and ETSI EN 319 411-1. See Task 5 certificate profiles.
| Identifier | Requirement Specification | Source | References |
|---|---|---|---|
| OIA_12 | For both proximity and remote presentation flows, a Relying Party SHALL validate the signature of a PID using a trust anchor provided in a PID Provider LoTE made available in accordance with Topic 31. | Topic 1 | Topic 1 |
| OIA_13 | For both proximity and remote presentation flows, a Relying Party SHALL validate the qualified signature of a QEAA in accordance with Art.32 of the [European Digital Identity Regulation]. For the verification, the Relying Party SHALL use a trust anchor provided in a QEAA Provider Trusted List made available in accordance with Art. 22 of the [European Digital Identity Regulation]. | Topic 1 | Topic 1 |
| OIA_14 | For both proximity and remote presentation flows, a Relying Party SHALL validate the signature of a PuB-EAA using a trust anchor provided in a PUB-EAA Provider Trusted List made available in accordance with Topic 31. | Topic 1 | Topic 1 |
| OIA_15 | For both proximity and remote presentation flows, a Relying Party SHALL validate the signature of a non-qualified EAA using a trust anchor provided according to the mechanism(s) specified in the applicable Rulebook, see Topic 12. | Topic 1 | Topic 1 |
| RPACANot_03 | Relying Parties, PID Providers, QEAA Providers, PuB-EAA Providers, and non-qualified EAA Providers SHALL ensure that their access certificates can be authenticated using the trust anchors of an Access Certificate Authority notified to the Commission. | Topic 31 | Topic 31 |
| RPACANot_03a | Relying Parties, PID Providers, QEAA Providers, PuB-EAA Providers, and non-qualified EAA Providers SHALL ensure that their registration certificates, if issued to them, can be authenticated using the trust anchors of a Provider of registration certificates notified to the Commission. | Topic 31 | Topic 31 |
| RPRC_03 | The contents of a registration certificate SHALL include at least the information required in Annex V of the CIR 2025/848 regarding registration of wallet-relying parties. | Topic 44 | Topic 44 |
| RPRC_07 | The contents of a registration certificate SHALL include an EU-wide unique identifier for the subject of the certificate. | Topic 44 | Topic 44 |
| RPRC_04 | If the subject of the registration certificate uses the services of an intermediary (see Topic 52), the 'association to the intermediary' mentioned in Annex I (15) of [CIR 2025/848] SHALL consist of the user-friendly name and unique identifier of this intermediary, as meant in requirements Reg_31 and Reg_32. | Topic 44 | Topic 44 |
| RPRC_05 | If the subject of the registration certificate is not a Relying Party (i.e. in the terms of CIR 2025/848, a Service Provider), the certificate SHALL NOT contain the intended use as meant in Annex I (9) and (10) of CIR 2025/848. | Topic 44 | Topic 44 |
| RPRC_06 | The contents of a registration certificate SHALL include a name for the subject of the certificate, in a format suitable for presenting to a User. | Topic 44 | Topic 44 |
| RPRC_08 | The EU-wide unique identifier meant in RPRC_07 SHALL be identical in all registration certificates issued for a given entity. | Topic 44 | Topic 44 |
| RPRC_10 | If, during registration, a Relying Party received one or more registration certificates, it SHALL distribute these to all its Relying Party Instances. | Topic 44 | Topic 44 |
| RPRC_11 | The contents of a registration certificate issued to a Relying Party SHALL at least one of the following: a) the URL of a web form provided by the Relying Party, which Users can use to send data deletion requests, b) an e-mail address of the Relying Party, on which the Relying Party is prepared to receive data deletion requests from Users, c) a telephone number of the Relying Party, on which the Relying Party is prepared to receive data deletion requests from Users. | Topic 44 | Topic 44 |
| RPRC_12 | The contents of a registration certificate issued to a Relying Party SHALL contain the name and country of the Data Protection Authority supervising the Relying Party. In addition, the registration certificate SHALL contain at least one of the following: a) the URL of a web form provided by the DPA, which Users can use to report suspicious attribute presentation requests. b) an e-mail address of the DPA, on which the DPA is prepared to receive reports about suspicious attribute presentation requests from Users, c) a telephone number of the DPA, on which the DPA is prepared to receive reports about suspicious attribute presentation requests from Users. | Topic 44 | Topic 44 |
| RPRC_19 | If a Relying Party Instance received one or more registration certificates (see RPRC_10), it SHALL include a single registration certificate applicable for its current intended use in each presentation request to a Wallet Unit, according to the applicable standard's extension mentioned in RPRC_20. The registration certificate SHALL be included in the request by value, not by reference. The Relying Party Instance SHALL do so both in proximity and remote presentation flows. | Topic 44 | Topic 44 |
| RPRC_19a | A Relying Party Instance SHALL include in each presentation request the following information, according to the applicable standard's extension mentioned in RPRC_20a: a) the user-friendly name of the Relying Party, b) the unique identifier of the Relying Party, c) a User-friendly description of the intended use of the Relying Party, d) the URL of the Registrar of the Relying Party, and e) the identifier of the intended use of the Relying Party. | Topic 44 | Topic 44 |
| RPRC_20 | Relying Party Instances and Wallet Units SHALL support the extension for [ISO/IEC 18013-5] or the extension for [OpenID4VP], as specified in [ETSI TS 119 472-2] and amended by a CIR in preparation, as applicable, for transferring a single Relying Party registration certificate from a Relying Party Instance to a Wallet Unit. | Topic 44 | Topic 44 |
| RPRC_20a | Relying Party Instances and Wallet Units SHALL support the extension for [ISO/IEC 18013-5] or the extension for [OpenID4VP], as specified in [ETSI TS 119 472-2] and amended by a CIR in preparation, as applicable, for transferring the information listed in RPRC_19a from a Relying Party Instance to a Wallet Unit. | Topic 44 | Topic 44 |
| Identifier | Requirement Specification | Source | References |
|---|---|---|---|
| ISSU_07 | After a Wallet Unit receives a PID from a PID Provider, it SHALL validate the signature of the PID using a trust anchor of the PID Provider provided in a LoTE made available in accordance with Topic 31. | Topic 10 | Topic 10 |
| ISSU_08 | After a Wallet Unit receives a QEAA from a QEAA Provider, it SHALL validate the qualified signature of the QEAA in accordance with Art. 32 of the [European Digital Identity Regulation]. For the verification, the Wallet Unit SHALL use a trust anchor provided in a QEAA Provider Trusted List made available in accordance with Art. 22 of the [European Digital Identity Regulation]. | Topic 10 | Topic 10 |
| ISSU_09 | After a Wallet Unit receives a PuB-EAA from a PUB-EAA Provider, it SHALL validate the signature of a PuB-EAA using a trust anchor provided in a PUB-EAA Provider Trusted List made available in accordance with Topic 31. | Topic 10 | Topic 10 |
| ISSU_10 | After a Wallet Unit receives a non-qualified EAA from an EAA Provider, it SHALL validate the signature of the EAA if it has access to the trust anchors of the EAA Provider. | Topic 10 | Topic 10 |
| ISSU_23 | For the verification of a PID Provider's access certificates, a Wallet Unit SHALL accept the trust anchors in the LoTE(s) of Access Certificate Authorities it needs. | Topic 10 | Topic 10 |
| ISSU_24 | A Wallet Unit SHALL authenticate and validate the access certificate of the PID Provider before requesting the issuance of a PID. The Wallet Unit SHALL verify that the access certificate is authentic and is valid at the time of validation, and that the issuer of the access certificate is included in an Access Certificate Authority LoTE. | Topic 10 | Topic 10 |
| ISSU_24a | Before requesting the issuance of a PID, the Wallet Unit SHALL verify that the PID Provider is indeed a registered PID Provider. To do so, the Wallet Unit SHALL a) Inspect the entitlement member in the registration certificate of the PID Provider, if provided in the Credential Issuer Metadata per [ETSI TS 119 472-3] section 4.2.3, and verify the authenticity of the registration certificate. b) If no registration certificate is present, query the responsible Registrar for the registered value of entitlement, using the URI in the Credential Issuer Metadata, if possible. c) If querying the Registrar is not possible, optionally inspect the entitlement member included in the Credential Issuer Metadata itself per [ETSI TS 119 472-3] section 4.2.3. If this procedure does not confirm that the PID Provider is indeed registered as a PID Provider, the Wallet Unit SHALL display a warning to the User, and SHALL NOT request the issuance of a PID. |
Topic 10 | Topic 10 |
| ISSU_33 | For the verification of access certificates, a Wallet Unit SHALL accept only the trust anchors in all LoTE(s) for Access Certificate Authorities. | Topic 10 | Topic 10 |
| ISSU_33a | For the verification of the registration certificates of Attestation Providers, a Wallet Unit SHALL accept only the trust anchors in all LoTE(s) for Providers of registration certificates. | Topic 10 | Topic 10 |
| ISSU_34 | A Wallet Unit SHALL authenticate and validate the access certificate of the Attestation Provider before requesting the issuance of an attestation. The Wallet Unit SHALL verify that the access certificate is authentic and is valid at the time of validation, and that the issuer of the access certificate is in the Access Certificate Authority LoTE(s), as documented in Topic 27. | Topic 10 | Topic 10 |
| ISSU_34a | Before requesting the issuance of an attestation, the Wallet Unit SHALL verify that the Attestation Provider is a registered QEAA Provider, PuB-EAA Provider, or EAA Provider. To do so, the Wallet Unit SHALL a) Inspect the entitlement member in the registration certificate of the Attestation Provider, if provided in the Credential Issuer Metadata per [ETSI TS 119 472-3] section 4.2.3, and verify the authenticity of the registration certificate. b) If no registration certificate is present, query the responsible Registrar for the registered value of entitlement, using the URI in the Credential Issuer Metadata, if possible. c) If querying the Registrar is not possible, optionally inspect the entitlement member included in the Credential Issuer Metadata itself per [ETSI TS 119 472-3] section 4.2.3. If this procedure does not confirm that the Attestation Provider is indeed registered as a QEAA Provider, PuB-EAA Provider, or EAA Provider, the Wallet Unit SHALL display a warning to the User, and SHALL NOT request the issuance of an attestation. |
Topic 10 | Topic 10 |
| RPA_04 | For the verification of access certificates, a Wallet Unit SHALL accept only the trust anchors in the LoTE(s) of all Access Certificate Authorities notified by Member States. | Topic 6 | Topic 6 |
| RPRC_16 | A Wallet Unit SHALL offer the User the possibility to indicate whether the User wants the Wallet Unit to go online to the competent Registrar if that is needed to verify the information registered about the Relying Party. The Wallet Unit SHALL inform the User that this implies that the Registrar learns about the User's interaction with the Relying Party. The Wallet Unit SHALL also inform the User that not requesting this information from the Registrar means that the Wallet Unit has no way to verify the information included by the Relying Party in the presentation request. | Topic 44 | Topic 44 |
| RPRC_17 | If the Relying Party sends a registration certificate to the Wallet Unit in a presentation request, the Wallet Unit SHALL verify the authenticity and validity of the registration certificate according to the technical specification meant in RPRC_02. If the certificate is inauthentic or expired, the Wallet Unit SHALL, when asking for User approval according to RPA_07, notify the User that it could not obtain the information registered about the entity. | Topic 44 | Topic 44 |
| RPRC_18 | If the User indicated that they want the Wallet Unit to go online to the competent Registrar if needed to verify the information registered about the Relying Party (see RPRC_16), and the Relying Party did not send a registration certificate to the Wallet Unit, the Wallet Unit SHALL connect to the URL of the online service of the Registrar to obtain this information. If the Wallet Unit cannot connect to this URL or if it cannot verify the authenticity and validity of the registered information, it SHALL, when asking for User approval according to RPA_07, notify the User that it could not obtain the information registered about the Relying Party. | Topic 44 | Topic 44 |
| RPRC_21 | If the User indicated that they want to verify the information registered about a Relying Party and the Wallet Unit retrieved this information either from the registration certificate or from the online service of the Registrar (see RPRC_16 - RPRC_18), it SHALL verify that all attributes requested in the presentation request are included in the list of attributes registered by the Registrar. If the outcome of the verification is negative, the Wallet Unit SHALL, when asking for User approval according to RPA_07, notify the User about the requested attributes that the Relying Party did not register. | Topic 44 | Topic 44 |
| RPRC_23 | A Wallet Unit SHALL verify that the type of attestation it wants to request from the PID Provider or Attestation Provider is registered by the relevant Registrar, according to ISSU_24a for PID Providers and ISSU_34a for Attestation Providers. | Topic 44 | Topic 44 |
| WURevocation_12 | Before revoking a Wallet Unit per WURevocation_11, the Wallet Provider SHALL verify that the party requesting revocation is indeed a valid PID Provider listed in the LoTE of PID Providers. | Topic 38 | Topic 38 |
| CT_05 | When verifying an access certificate during PID or attestation issuance or presentation, a Wallet Unit SHALL also verify that the access certificate includes at least one valid Signed Certificate Timestamp (SCT). | Topic 55 | Topic 55 |
| CT_06 | If an access certificate does not include a valid SCT, a Wallet Unit SHALL handle this as a failure or Relying Party authentication, in compliance with all requirements in Topic 6 and in particular requirement RPA_06a. | Topic 55 | Topic 55 |
| RPI_07 | In case a Wallet Unit receives a presentation request from an intermediary on behalf of an intermediated Relying Party, it SHALL display the trade names of the intermediary and the intermediary Service to the User when asking for User approval, as described in RPA_07. | Topic 52 | Topic 52 |
| RPI_07a | In case a Wallet Unit receives a presentation request from an intermediary on behalf of an intermediated Relying Party, and if the User indicated that they want to verify the information registered about this Relying Party (according to RPRC_16), the Wallet Unit SHALL verify that that the contractual relationship between the Relying Party and the intermediary is indeed registered by the responsible Registrar according to RPI_04, see also RPRC_04. If this verification fails, the Wallet Unit SHALL notify the User when asking for User consent. | Topic 52 | Topic 52 |
| WPNot_02 | The common set of information to be notified about a Wallet Provider SHALL include: 1. Identification data: i. MS/Country of establishment, ii. Name as registered in an official record, iii. Where applicable: a. Business registration number from an official record, and b. Identification data from the official record. 2. Wallet Provider trust anchors, i.e., public keys and name as per point 1. b. above, supporting the authentication of Key Attestations and Wallet Instance Attestations issued by the Wallet Provider. 3. Name and reference number of the certified Wallet Solution(s) provided by the Wallet Provider. | Topic 31 | Topic 31 |
| WPNot_03 | Wallet Providers SHALL ensure that all WIAs and KAs they issue can be authenticated using the trust anchors notified to the Commission. | Topic 31 | Topic 31 |
| WPNot_04 | PID Providers, Attestation Providers and other relevant actors SHALL accept Wallet Provider trust anchors because of their secure notification by the Member States to the Commission and by their publication in the corresponding Commission-compiled Wallet Provider LoTE, which is sealed by the Commission. | Topic 31 | Topic 31 |
| WPNot_05 | The format of a Wallet Provider LoTE SHALL comply with [ETSI TS 119 602] v1.1.1, including Annex E. | Topic 31 | Topic 31 |
| WPNot_06 | If a Wallet Provider is cancelled (see requirement GenNot_05 above), that Wallet Provider SHALL immediately revoke all of its Wallet Instances and all associated WSCDs and keystores, in accordance with the requirements in Topic 38. If a Wallet Provider is suspended, that Wallet Provider and the Member State SHALL agree on the necessary precautionary measures that need to be taken, which MAY include the immediate revocation of the Wallet Instances and WSCDs or keystores for all or some of its valid Wallet Units. | Topic 31 | Topic 31 |
| Identifier | Requirement Specification | Source | References |
|---|---|---|---|
| ISSU_19 | For the verification of a WIA or KA, a PID Provider SHALL accept the trust anchors in the Wallet Provider LoTE(s) it needs. | Topic 10 | Topic 10 |
| ISSU_19a | A PID Provider SHALL support all Wallet Solutions recognised under the corresponding notified eID scheme, meaning that it is willing and able to issue a PID to a Wallet Unit on request of the User. | Topic 10 | Topic 10 |
| ISSU_21 | Before issuing a PID, a PID Provider SHALL verify the Wallet Unit's WIA and KA using a trust anchor registered in the Wallet Provider LoTE. Moreover, it SHALL verify that the Wallet Instance referenced in the WIA has not been revoked, and that the WSCD referenced in the KA has not been revoked. | Topic 10 | Topic 10 |
| ISSU_12c | The expiration date of a PID SHALL be no later than the end of the revocation maintenance periods of the WIA and the KA presented as part of the PID issuance process. | Topic 10 | Topic 10 |
| ISSU_22 | A PID Provider SHALL sign its Credential Issuer metadata as specified in section 12.2.3 of [OpenID4VCI]. To do so, the PID Provider SHALL use the private key corresponding to the public key in its access certificate. The PID Provider SHALL include its access certificate, as well as all intermediate certificate(s) leading up to the trust anchor of the corresponding Access Certificate Authority (see ISSU_33) in the LoTE, in the x5c parameter in the JOSE header of the JSON Web Signature for the metadata. |
Topic 10 | Topic 10 |
| PPNot_02 | The common set of information to be notified about a PID Provider SHALL include at least: 1. Identification data: i. MS/Country of establishment, ii. Name as registered in an official record, iii. Where applicable: a. A business registration number from an official record, b. Identification data from that official record. 2. PID Provider trust anchors, i.e., public keys and name as per point 1) ii) above, supporting the authentication of PIDs issued by the PID Provider, 3. Trust anchors of Access Certificate Authorities for PID Providers, i.e., public keys and CA name, supporting the authentication of the PID Provider by Wallet Units at the service supply point(s) listed per point 4. below. 4. Service supply point(s), i.e., the URL(s) at which a Wallet Unit can start the process of requesting and obtaining a PID. | Topic 31 | Topic 31 |
| PPNot_03 | PID Providers SHALL ensure that all PIDs they issue can be authenticated using the PID Provider trust anchors notified to the Commission. | Topic 31 | Topic 31 |
| PPNot_04 | PID Providers SHALL ensure that their access certificates can be authenticated using the applicable Access Certificate Authority trust anchors notified to the Commission. | Topic 31 | Topic 31 |
| PPNot_05 | Wallet Units, Relying Parties, and other relevant actors SHALL accept PID Provider trust anchors because of their secure notification by the Member States to the Commission and by their publication in the corresponding Commission-compiled PID Provider LoTE, which is sealed by the Commission. | Topic 31 | Topic 31 |
| PPNot_06 | Wallet Units and other relevant actors SHALL accept Access Certificate Authority trust anchors because of their secure notification by the Member States to the Commission and by their publication in the corresponding Commission-compiled LoTE, which is signed or sealed by the Commission. | Topic 31 | Topic 31 |
| PPNot_07 | The format of a PID Provider LoTE SHALL comply with [ETSI TS 119 602] v1.1.1, including Annex D. | Topic 31 | Topic 31 |
| RPACANot_03 | Relying Parties, PID Providers, QEAA Providers, PuB-EAA Providers, and non-qualified EAA Providers SHALL ensure that their access certificates can be authenticated using the trust anchors of an Access Certificate Authority notified to the Commission. | Topic 31 | Topic 31 |
| RPACANot_03a | Relying Parties, PID Providers, QEAA Providers, PuB-EAA Providers, and non-qualified EAA Providers SHALL ensure that their registration certificates, if issued to them, can be authenticated using the trust anchors of a Provider of registration certificates notified to the Commission. | Topic 31 | Topic 31 |
| Reg_19 | A Member State SHALL approve a PID Provider according to a well-defined policy before including it in its PID Provider Registry. To that end, a Member State SHALL define specific vetting processes and rules of acceptance for inclusion of PID Providers in its Registry. | Topic 27 | Topic 27 |
| Reg_20 | A Member State SHALL identify PID Providers at a level of confidence proportionate to the risk arising from the potential harm a fraudulent PID Provider could cause to Users and other stakeholders in the EUDI Wallet ecosystem. | Topic 27 | Topic 27 |
| RPRC_13 | A Registrar MAY decide that, during the registration process for PID Providers, QEAA Providers, PuB-EAA Provider, or non-qualified EAA Providers, as specified in Topic 27, a Provider of registration certificates associated to the Member State Registrar must create and sign or seal a registration certificate and issue it to the registering party. If so, that registration certificate SHALL comply with the requirements in the technical specification mentioned in RPRC_02. | Topic 44 | Topic 44 |
| RPRC_14 | If, during registration, a PID Provider, QEAA Provider, PuB-EAA Provider, or non-qualified EAA Provider received a registration certificate, it SHALL distribute it to all its service supply points. | Topic 44 | Topic 44 |
| RPRC_15 | The contents of a registration certificate issued to a PID Provider, a QEAA Provider, a PuB-EAA Provider, or a non-qualified EAA Provider SHALL contain the type(s) of attestation that this entity intends to issue to Wallet Units. | Topic 44 | Topic 44 |
| RPRC_22 | If a PID Provider or Attestation Provider received a registration certificate (see RPRC_14), it SHALL include the registration certificate in its Credential Issuer metadata used in the common OpenID4VCI protocol referenced in ISSU_01 and the extension thereof in [ETSI TS 119 472-3]. The registration certificate SHALL be included in the metadata by value, not by reference. | Topic 44 | Topic 44 |
| Identifier | Requirement Specification | Source | References |
|---|---|---|---|
| ISSU_28 | For the verification of a WIA or KA, an Attestation Provider SHALL accept the trust anchors in the Wallet Provider LoTE. | Topic 10 | Topic 10 |
| ISSU_30 | Before issuing a device-bound attestation, an Attestation Provider SHALL verify the Wallet Unit's key attestation using a trust anchor registered in the Wallet Provider LoTE. Moreover, it SHALL verify that the WSCD or keystore referenced in the KA has not been revoked. | Topic 10 | Topic 10 |
| ISSU_30a | Before issuing an attestation, an Attestation Provider SHALL: - verify that the Wallet Provider mentioned in the Wallet Unit's WIA is present in the Wallet Provider LoTE. - authenticate and validate the WIA using the trust anchor(s) registered for the Wallet Provider in that LoTE. | Topic 10 | Topic 10 |
| ISSU_12d | If an Attestation Provider supports revocation chaining for its attestations per WURevocation_19 in Topic 38, the expiration date of an attestation SHALL be no later than the end of the revocation maintenance periods of the WIA and the KA (if applicable) presented as part of the attestation issuance process. | Topic 10 | Topic 10 |
| ISSU_32 | An Attestation Provider SHALL sign its Credential Issuer metadata as specified in section 12.2.3 of [OpenID4VCI]. To do so, the Attestation Provider SHALL use the private key corresponding to the public key in its access certificate. The Attestation Provider SHALL include its access certificate, as well as all intermediate certificate(s) leading up to the trust anchor of the corresponding Access Certificate Authority in the LoTE (see ISSU_33), in the x5c parameter in the JOSE header of the JSON Web Signature for the metadata. |
Topic 10 | Topic 10 |
| PuBPNot_02 | The common set of information to be notified by Member States about PuB-EAA Providers SHALL include at least: 1. Identification data: i. MS/Country of establishment, ii. Name as registered in an official record, iii. Where applicable: a. Registration number as in official record, and b. Official record identification data. iv. Identification data of the Union or national law under which a. Either the PuB-EAA Provider is established as the responsible body for the Authentic Source based on which the electronic attestation of attributes is issued, or b. The PuB-EAA Provider is the body designated to act on behalf of the responsible body referred to in point 1. iv. a. v.The conformity assessment report issued by a conformity assessment body, confirming that the requirements set out in paragraphs 1, 2 and 6 of Article 45f are met. 2. PuB-EAA Provider trust anchors, i.e., public keys and name as per point 1) ii) above, supporting the authentication of PuB-EAAs issued by the PuB-EAA Provider, 3. Service supply point(s), i.e., the URL(s) at which a Wallet Unit can start the process of requesting and obtaining a PuB-EAA from the PuB-EAA Provider. | Topic 31 | Topic 31 |
| PuBPNot_03 | The format of the PuB-EAA Provider Trusted List SHALL comply with [ETSI TS 119 612] v2.1.1. | Topic 31 | Topic 31 |
| RPACANot_03 | Relying Parties, PID Providers, QEAA Providers, PuB-EAA Providers, and non-qualified EAA Providers SHALL ensure that their access certificates can be authenticated using the trust anchors of an Access Certificate Authority notified to the Commission. | Topic 31 | Topic 31 |
| RPACANot_03a | Relying Parties, PID Providers, QEAA Providers, PuB-EAA Providers, and non-qualified EAA Providers SHALL ensure that their registration certificates, if issued to them, can be authenticated using the trust anchors of a Provider of registration certificates notified to the Commission. | Topic 31 | Topic 31 |
| Reg_21 | A Member State SHALL approve an Attestation Provider according to a well-defined policy before including it in its Attestation Provider Registry. To that end, a Member State SHALL define specific vetting processes and rules of acceptance for inclusion of Attestation Providers in its Registry. These processes and rules SHOULD consider any relevant differences between QEAA Providers, PuB-EAA Providers, and non-qualified EAA Providers. | Topic 27 | Topic 27 |
| Reg_22 | A Member State SHALL identify Attestation Providers (i.e., QEAA Providers, PuB-EAA Providers and non-qualified EAA Providers) at a level of confidence proportionate to the risk arising from the potential harm a fraudulent Attestation Provider could cause to Users and other stakeholders in the EUDI Wallet ecosystem. | Topic 27 | Topic 27 |
| RPRC_13 | A Registrar MAY decide that, during the registration process for PID Providers, QEAA Providers, PuB-EAA Provider, or non-qualified EAA Providers, as specified in Topic 27, a Provider of registration certificates associated to the Member State Registrar must create and sign or seal a registration certificate and issue it to the registering party. If so, that registration certificate SHALL comply with the requirements in the technical specification mentioned in RPRC_02. | Topic 44 | Topic 44 |
| RPRC_14 | If, during registration, a PID Provider, QEAA Provider, PuB-EAA Provider, or non-qualified EAA Provider received a registration certificate, it SHALL distribute it to all its service supply points. | Topic 44 | Topic 44 |
| RPRC_15 | The contents of a registration certificate issued to a PID Provider, a QEAA Provider, a PuB-EAA Provider, or a non-qualified EAA Provider SHALL contain the type(s) of attestation that this entity intends to issue to Wallet Units. | Topic 44 | Topic 44 |
| RPRC_22 | If a PID Provider or Attestation Provider received a registration certificate (see RPRC_14), it SHALL include the registration certificate in its Credential Issuer metadata used in the common OpenID4VCI protocol referenced in ISSU_01 and the extension thereof in [ETSI TS 119 472-3]. The registration certificate SHALL be included in the metadata by value, not by reference. | Topic 44 | Topic 44 |
| Identifier | Requirement Specification | Source | References |
|---|---|---|---|
| RPACANot_02 | The common set of information to be notified about an Access Certificate Authority or a Provider of registration certificates SHALL include: 1. Identification data: i) Member State or country of establishment, ii) Name as registered in an official record, iii) Where applicable: - A business registration number from an official record, - Identification data from that official record. 2. Trust anchors of the Access Certificate Authority or Provider of registration certificates, i.e., public keys and name as per point 1) ii), supporting the authentication of access certificates and registration certificates by Wallet Units. | Topic 31 | Topic 31 |
| RPACANot_04 | The trust anchors of Access Certificate Authorities and Providers of registration certificates SHALL be accepted because of their secure notification by the Member States to the Commission and by their publication in the corresponding Commission-compiled LoTEs, which are signed or sealed by the Commission. | Topic 31 | Topic 31 |
| RPACANot_05 | The format of a LoTE for Access Certificate Authorities SHALL comply with [ETSI TS 119 602] v1.1.1, including Annex F. | Topic 31 | Topic 31 |
| RPACANot_06 | If an Access Certificate Authority is suspended or cancelled (see requirement GenNot_05 above), that Access Certificate Authority SHALL immediately revoke all of its temporally valid access certificates. | Topic 31 | Topic 31 |
| Reg_10 | A Member State SHALL ensure that an Access Certificate Authority notified according to Topic 31 issues an access certificate to all PID Providers, QEAA Providers, PuB-EAA Providers, and non-qualified EAA Providers registered in one of the Member State's registries. | Topic 27 | Topic 27 |
| Reg_10a | A Member State SHALL ensure that an Access Certificate Authority notified according to Topic 31 issues one or more access certificates to all Relying Parties registered in one of the Member State's registries. A Relying Party SHALL receive a separate access certificate for each of its Relying Party Instances. | Topic 27 | Topic 27 |
| Reg_11 | A Member State SHALL ensure that the issuance process of access certificates by their notified Access Certificate Authority(s) complies with [ETSI TS 119 411-8]. In addition, the Access Certificate Authority(s) SHALL comply with at least the normalised certificate policy (‘NCP’) requirements as specified in [ETSI EN 319 411-1]. | Topic 27 | Topic 27 |
| CT_01 | An Access CA issuing access certificates SHALL register these in a CT log according to RFC 9162, if such a log is available for access certificates. | Topic 55 | Topic 55 |
| CT_02 | An Access CA issuing access certificates SHALL describe in its CPS how it logs all access certificates. | Topic 55 | Topic 55 |
| CT_03 | In case a CT log provider for access certificates is available, all Access CAs SHALL act as monitors in the CT ecosystem. Access CAs SHOULD still monitor the CT logs in situations of temporary unavailability. | Topic 55 | Topic 55 |
| CT_04 | An Access CA SHALL include at least one Signed Certificate Timestamp (SCT) in each access certificate. | Topic 55 | Topic 55 |
| Identifier | Requirement Specification | Source | References |
|---|---|---|---|
| RPACANot_02 | The common set of information to be notified about an Access Certificate Authority or a Provider of registration certificates SHALL include: 1. Identification data: i) Member State or country of establishment, ii) Name as registered in an official record, iii) Where applicable: - A business registration number from an official record, - Identification data from that official record. 2. Trust anchors of the Access Certificate Authority or Provider of registration certificates, i.e., public keys and name as per point 1) ii), supporting the authentication of access certificates and registration certificates by Wallet Units. | Topic 31 | Topic 31 |
| RPACANot_04 | The trust anchors of Access Certificate Authorities and Providers of registration certificates SHALL be accepted because of their secure notification by the Member States to the Commission and by their publication in the corresponding Commission-compiled LoTEs, which are signed or sealed by the Commission. | Topic 31 | Topic 31 |
| RPACANot_05a | The format of a LoTE for Providers of registration certificates SHALL comply with [ETSI TS 119 602] v1.1.1, including Annex G. | Topic 31 | Topic 31 |
| RPACANot_07 | If a Provider of registration certificates is suspended or cancelled (see requirement GenNot_05 above), that Provider SHALL immediately revoke all of its valid registration certificates (if any). Moreover, the corresponding Registrar SHALL prohibit all access to the registry entries published online per Reg_03 and Reg_04. | Topic 31 | Topic 31 |
| RPRC_01 | Providers of registration certificates SHALL comply with all relevant requirements in [ETSI TS 119 475]. | Topic 44 | Topic 44 |
| RPRC_07 | The contents of a registration certificate SHALL include an EU-wide unique identifier for the subject of the certificate. | Topic 44 | Topic 44 |
| RPRC_09 | A Member State Registrar MAY decide that, during the registration process for Relying Parties, as specified in Topic 27, a Provider of registration certificates associated to the Registrar must create and sign or seal one or more registration certificates. If the Registrar decides to do so, the Provider of registration certificates SHALL create and sign or seal a separate registration certificate for each intended use registered by each Relying Party, and issue it to the Relying Party. Each registration certificate SHALL comply with the requirements in the technical specification mentioned in RPRC_02. | Topic 44 | Topic 44 |
| RPRC_13 | A Registrar MAY decide that, during the registration process for PID Providers, QEAA Providers, PuB-EAA Provider, or non-qualified EAA Providers, as specified in Topic 27, a Provider of registration certificates associated to the Member State Registrar must create and sign or seal a registration certificate and issue it to the registering party. If so, that registration certificate SHALL comply with the requirements in the technical specification mentioned in RPRC_02. | Topic 44 | Topic 44 |
| Identifier | Requirement Specification | Source | References |
|---|---|---|---|
| RPI_01 | An intermediary SHALL register as a Relying Party, in accordance with all requirements in Topic 27, while indicating it intends to act as an intermediary. | Topic 52 | Topic 52 |
| RPI_03 | An intermediary SHALL register each intermediated Relying Party it is acting on behalf of at a Registrar in the Member State where the intermediated Relying Party is established, according all requirements in Topic 44. If a Provider of registration certificates associated with the Registrar issues registration certificates, the intermediary SHALL receive a registration certificate for each of the registered intended uses of the intermediated Relying Party. | Topic 52 | Topic 52 |
| RPI_04 | When registering an intermediated Relying Party, an intermediary SHALL provide legally valid evidence that this Relying Party will indeed use the services of this intermediary to interact with Wallet Units. The Registrar SHALL verify this evidence, and, if it is found to be correct, SHALL register the relationship between the intermediary and the intermediated Relying Party. | Topic 52 | Topic 52 |
| RPI_05 | When an intermediated Relying Party asks its intermediary to request some attributes from a Wallet Unit, it SHALL specify a) its user-friendly name, b) its unique identifier, c) the URL of its Registrar, d) the identifier of its intended use, e) a User-friendly description of its intended use. In addition, if the intermediated Relying Party has registration certificates, it SHALL indicate which single registration certificate the intermediary must include in the presentation request. | Topic 52 | Topic 52 |
| RPI_06 | When requested by an intermediated Relying Party, an intermediary SHALL request a presentation of attributes from a specific Wallet Unit. In the request, the intermediary SHALL include the intermediary's access certificate meant in requirement RPI_01 and the registration certificate of the Relying Party, as meant in RPI_03, if available. In addition, whether or not a registration certificate is available, the intermediary SHALL include in the request the information about the intermediated Relying Party required in RPRC_19a. | Topic 52 | Topic 52 |
| Identifier | Requirement Specification | Source | References |
|---|---|---|---|
| GenNot_01 | Member States SHALL notify all PID Providers, PuB-EAA Providers, Wallet Providers, Access Certificate Authorities, and Providers of registration certificates to the European Commission, using a common system provided by the Commission, complying with all relevant requirements inTechnical Specification 2. | Topic 31 | Topic 31 |
| Reg_01 | Member States SHALL provide processes and mechanisms for PID Providers, QEAA Providers, PuB-EAA Providers, non-qualified EAA Providers, and Relying Parties to register in a registry. | Topic 27 | Topic 27 |
| Reg_01a | Member States SHALL register a common set of data about a) PID Providers, b) QEAA Providers, c) PuB-EAA Providers, d) non-qualified EAA Providers. and e) Relying Parties, according to the relevant requirements in Technical Specification 6. | Topic 27 | Topic 27 |
| Reg_02 | Member States SHALL make publicly available all necessary details and documentation about the registration processes for their registry. | Topic 27 | Topic 27 |
| Reg_03 | Member States SHALL publish the registry entries online, in a sealed or signed machine-readable common format suitable for automated processing, according to the relevant requirements in Technical Specification 5, for the purpose of transparency to Users and other stakeholders. | Topic 27 | Topic 27 |
| Reg_04 | Member States SHALL make the registry entries available online, in a human-readable format. The website used for this purpose SHALL use a secure channel protecting the authenticity and integrity of the information in the registry during transport. Member States SHALL NOT require authentication or prior registration and authorisation of any person wishing to retrieve the information in the registry. | Topic 27 | Topic 27 |
| Reg_06 | Member States SHALL support the common API specified in Technical Specification 5 for to enable automated retrieval of registry entries from the Member States' registries. | Topic 27 | Topic 27 |
| Reg_07 | A Member State SHALL enable a registered PID Provider, QEAA Provider, PuB-EAA Provider, non-qualified EAA Provider, or Relying Party to update the information registered on it, using a process comparable to the original registration process. For Relying Parties, this SHALL be possible using the API or user interface mentioned in Reg_24. | Topic 27 | Topic 27 |
| Reg_08 | A registered PID Provider, QEAA Provider, PuB-EAA Provider, non-qualified EAA Provider, or Relying Party SHALL make any updates necessary to ensure the continued correctness of the registered information without undue delay. | Topic 27 | Topic 27 |
| Reg_09 | Member States SHALL log all changes made on the information registered regarding a PID Provider, QEAA Provider, PuB-EAA Provider, non-qualified EAA Provider, or Relying Party, including at least initial registration, updates, deletion of information, and suspension or cancellation. | Topic 27 | Topic 27 |
| Reg_10 | A Member State SHALL ensure that an Access Certificate Authority notified according to Topic 31 issues an access certificate to all PID Providers, QEAA Providers, PuB-EAA Providers, and non-qualified EAA Providers registered in one of the Member State's registries. | Topic 27 | Topic 27 |
| Reg_10a | A Member State SHALL ensure that an Access Certificate Authority notified according to Topic 31 issues one or more access certificates to all Relying Parties registered in one of the Member State's registries. A Relying Party SHALL receive a separate access certificate for each of its Relying Party Instances. | Topic 27 | Topic 27 |
| Reg_11 | A Member State SHALL ensure that the issuance process of access certificates by their notified Access Certificate Authority(s) complies with [ETSI TS 119 411-8]. In addition, the Access Certificate Authority(s) SHALL comply with at least the normalised certificate policy (‘NCP’) requirements as specified in [ETSI EN 319 411-1]. | Topic 27 | Topic 27 |
| Reg_31 | An access certificate SHALL contain a name for the entity (i.e., the PID Provider, QEAA Provider, PuB-EAA Provider, non-qualified EAA Provider, or Relying Party), in a format suitable for presenting to a User. This name SHALL be identical to the name for the entity registered according to [Technical Specification 6] and included in the entity's registration certificate(s) (if present) according to RPRC_06. | Topic 27 | Topic 27 |
| Reg_32 | An access certificate SHALL contain an EU-wide unique identifier for the entity (i.e., the PID Provider, QEAA Provider, PuB-EAA Provider, non-qualified EAA Provider, or Relying Party), which SHALL be identical to the identifier for the entity registered according to [Technical Specification 6] and included in the entity's registration certificate(s) (if present) according to RPRC_07. | Topic 27 | Topic 27 |
| Reg_19 | A Member State SHALL approve a PID Provider according to a well-defined policy before including it in its PID Provider Registry. To that end, a Member State SHALL define specific vetting processes and rules of acceptance for inclusion of PID Providers in its Registry. | Topic 27 | Topic 27 |
| Reg_20 | A Member State SHALL identify PID Providers at a level of confidence proportionate to the risk arising from the potential harm a fraudulent PID Provider could cause to Users and other stakeholders in the EUDI Wallet ecosystem. | Topic 27 | Topic 27 |
| Reg_20a | A Registrar SHALL provide a method to suspend or cancel a registered PID Provider. | Topic 27 | Topic 27 |
| Reg_20b | A Registrar SHALL have a policy for the suspension or cancellation of a registered PID Provider, which SHALL specify that a PID Provider is suspended or cancelled at least on request of the PID Provider or of a competent national authority. | Topic 27 | Topic 27 |
| Reg_21 | A Member State SHALL approve an Attestation Provider according to a well-defined policy before including it in its Attestation Provider Registry. To that end, a Member State SHALL define specific vetting processes and rules of acceptance for inclusion of Attestation Providers in its Registry. These processes and rules SHOULD consider any relevant differences between QEAA Providers, PuB-EAA Providers, and non-qualified EAA Providers. | Topic 27 | Topic 27 |
| Reg_22 | A Member State SHALL identify Attestation Providers (i.e., QEAA Providers, PuB-EAA Providers and non-qualified EAA Providers) at a level of confidence proportionate to the risk arising from the potential harm a fraudulent Attestation Provider could cause to Users and other stakeholders in the EUDI Wallet ecosystem. | Topic 27 | Topic 27 |
| Reg_22a | A Registrar SHALL provide a method to suspend or cancel a registered Attestation Provider. | Topic 27 | Topic 27 |
| Reg_22b | A Registrar SHALL have a policy for the suspension or cancellation of a registered Attestation Provider, which SHALL specify that an Attestation Provider is suspended or cancelled at least on request of the Attestation Provider or of a competent national authority. | Topic 27 | Topic 27 |
| Reg_24 | A Member State SHALL enable a Relying Party to register remotely, using an API or user interface. | Topic 27 | Topic 27 |
| Reg_25 | A Member State SHALL identify a Relying Party at a level of confidence proportionate to the risk arising from the potential harm a fraudulent Relying Party could cause to Users and other stakeholders in the EUDI Wallet ecosystem. | Topic 27 | Topic 27 |
| Reg_26 | With respect to Reg_25, a Member State SHALL consider whether a registering entity intends to act as an intermediary. | Topic 27 | Topic 27 |
| Reg_29 | A Member State SHALL have a policy for the cancellation of a registered Relying Party, which SHALL specify that a Relying Party is cancelled at least on request of the Relying Party or of a competent national authority. | Topic 27 | Topic 27 |
| RPRC_09 | A Member State Registrar MAY decide that, during the registration process for Relying Parties, as specified in Topic 27, a Provider of registration certificates associated to the Registrar must create and sign or seal one or more registration certificates. If the Registrar decides to do so, the Provider of registration certificates SHALL create and sign or seal a separate registration certificate for each intended use registered by each Relying Party, and issue it to the Relying Party. Each registration certificate SHALL comply with the requirements in the technical specification mentioned in RPRC_02. | Topic 44 | Topic 44 |
| RPRC_13 | A Registrar MAY decide that, during the registration process for PID Providers, QEAA Providers, PuB-EAA Provider, or non-qualified EAA Providers, as specified in Topic 27, a Provider of registration certificates associated to the Member State Registrar must create and sign or seal a registration certificate and issue it to the registering party. If so, that registration certificate SHALL comply with the requirements in the technical specification mentioned in RPRC_02. | Topic 44 | Topic 44 |
| Identifier | Requirement Specification | Source | References |
|---|---|---|---|
| GenNot_02 | In addition to [Technical Specification 2] referred to in GenNot_01, the European Commission SHALL establish standard operating procedures for the notification of a PID Provider, PuB-EAA Provider, Wallet Provider, Access Certificate Authority, or Provider of registration certificates to the Commission. | Topic 31 | Topic 31 |
| GenNot_03 | The common system mentioned in GenNot_01 SHALL enable: - A secure notification channel between Member States and the Commission for all notifications. - A notification, verification, and publication process and associated validation steps (with follow-up and monitoring) at the Commission side. - Collected data to be processed, consolidated, signed or sealed, and published in both a machine-processable Trusted List or LoTE and in a human-readable format, manually and/or automatically using e.g. a web service and/or API. | Topic 31 | Topic 31 |
| GenNot_05 | In addition to [Technical Specification 2] referred to in GenNot_01, the European Commission SHALL establish standard operating procedures for the suspension or cancellation of a PID Provider, PuB-EAA Provider, Wallet Provider, Access Certificate Authority, or Provider of registration certificates. These operating procedures SHALL include unambiguous conditions for suspension or cancellation. As an outcome of the suspension or cancellation procedure, the status of the suspended or cancelled PID Provider, PuB-EAA Provider, Wallet Provider, Access Certificate Authority or Provider of registration certificates in the respective LoTE or Trusted List SHALL be changed to Invalid. | Topic 31 | Topic 31 |
| TLPub_01 | The European Commission SHALL establish technical specifications for the system enabling the publication by the Commission of the information notified by the Member States regarding PID Providers, Wallet Providers, PuB-EAA Providers, Access Certificate Authorities, and Providers of registration certificates. | Topic 31 | Topic 31 |
| TLPub_02 | The European Commission SHALL establish technical specifications for the set of information to be published about PID Providers, Wallet Providers, PuB-EAA Providers, Access Certificate Authorities and Providers of registration certificates, based on the information notified by the Member States. | Topic 31 | Topic 31 |
| TLPub_03 | The publication of the information referred to in TLPub_01 SHALL take place over a secure channel protecting the authenticity and integrity of the published information. | Topic 31 | Topic 31 |
| TLPub_04 | The technical system mentioned in TLPub_01 SHALL NOT require authentication or prior registration and authorisation of any entity wishing to retrieve the published information. | Topic 31 | Topic 31 |
| TLPub_05 | The information referred to in TLPub_01 SHALL be published in an electronically signed or sealed form that is suitable for automated processing, and in a human-readable format, e.g., through introspection and display facilities, over an authenticated channel. | Topic 31 | Topic 31 |
| TLPub_06 | The Commission SHALL publish in the OJEU the locations of the LoTEs for PID Providers, Wallet Providers, Access Certificate Authorities, and Providers of registration certificates, as well as the location of the Trusted List(s) of PuB-EAA Providers. | Topic 31 | Topic 31 |
| TLPub_07 | The Commission SHALL publish in the OJEU the trust anchors to be used for verifying the signature or seal mentioned in TLPub_05. | Topic 31 | Topic 31 |
| TLPub_08 | As part of the specifications referred to in TLPub_01, the European Commission SHALL establish technical specifications for ensuring the availability and authenticity of the full history regarding the information notified about PID Providers, Wallet Providers, PuB-EAA Providers, Access Certificate Authorities, and Providers of registration certificates. | Topic 31 | Topic 31 |
| RPRC_01 | Providers of registration certificates SHALL comply with all relevant requirements in [ETSI TS 119 475]. | Topic 44 | Topic 44 |