Use when working with EUDI high-level requirements for 'Issuing a PID or attestation to a Wallet Unit' (Part 1). Contains normative requirements from ARF Annex 2.
| Index | Requirement specification |
|---|---|
| ISSU_01 | Wallet Providers SHALL ensure that their Wallet Solution supports the OpenID4VCI protocol specified in [OpenID4VCI], as profiled in Sections 4 and 6 of [HAIP], and with additions and changes as documented in this Annex (see e.g. this Topic and Topic 9) and in Technical Specification 3. Note: For clarity: in [HAIP] v1.0, Section 6 implies that Wallet Units must comply with the applicable requirements in [OpenID4VCI] Annex A.2 when requesting the issuance of an attestation in ISO/IEC 18013-5-compliant format, and with the applicable requirements in [OpenID4VCI] Annex A.3 when requesting the issuance of an attestation in SD-JWT VC format. |
| ISSU_01a | PID Providers and Attestation Providers SHALL support the OpenID4VCI protocol specified in [OpenID4VCI], as profiled in Sections 4 and 6 of [HAIP], and with additions and changes as documented in this Annex (see e.g. this Topic and Topic 9) and in Technical Specification 3. Note: For clarity: in [HAIP] v1.0, Section 6 implies that PID Providers and Attestation Providers must comply with the applicable requirements in [OpenID4VCI] Annex A.2 when issuing an attestation in ISO/IEC 18013-5-compliant format, and with the applicable requirements in [OpenID4VCI] Annex A.3 when issuing an attestation in SD-JWT VC format. |
| ISSU_02 | Wallet Providers SHALL ensure that their Wallet Solution supports the attestation formats specified in ISO/IEC 18013-5, see [ISO18013-5], and in SD-JWT-based Verifiable Credentials (SD-JWT VC), see [SD-JWT-VC], with additions and changes as documented in this Annex and in future technical specifications created by or on behalf of the Commission. |
| ISSU_03 | Wallet Units, PID Providers, and Attestation Providers SHALL support the W3C Digital Credentials API for the issuance of PIDs and attestations. Note: This requirement implies that the following conditions will be satisfied: a) the DC API specification will become a W3C Recommendation, b) this specification will comply with the principles outlined in Section 4.4.3.1 of the ARF main document, c) this specification will be broadly supported by relevant browsers and operating systems, and d) the [OpenID4VCI] standard will specify how to use OpenID4VCI with the DC API. |
| ISSU_04 | The OpenID4VCI protocol referenced in requirement ISSU_01, or an EUDI Wallet-specific extension or profile thereof, SHALL enable PID Providers and Attestation Provider to issue to a Wallet Unit a batch of multiple PIDs or attestations that are simultaneously valid and contain the same attributes. |
| ISSU_05 | A Wallet Unit SHALL support a process to activate a newly issued PID, in accordance with the requirements for LoA High in Commission Implementing Regulation (EU) 2015/1502 Section 2.2.2. The Wallet Unit SHALL NOT allow a User to use a non-activated PID. Note: a) The goal of the activation process is to verify that the PID was delivered into the Wallet Unit and WSCA/WSCD of the User who is the subject of the PID. b) This requirement is not applicable for QEAAs, PuB-EAAs or non-qualified EAAs, since these are not identity means in the sense of Commission Implementing Regulation (EU) 2015/1502. |
| ISSU_06 | After a Wallet Unit receives a PID or an attestation from a PID Provider or Attestation Provider, it SHALL verify that the PID or attestation it received matches the PID or attestation requested by the Wallet Unit. |
| 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], unless this would result in the validation of the PID signature being done by the same component that created the signature. Note: This could be the case in architectures where the Wallet Provider is also the PID Provider and the Wallet Units use a remote HSM as their WSCD. |
| 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]. Note: a) Requirements ISSU_07 to ISSU_10 are equivalent to requirements OIA_12 to OIA_15 in Topic 1. b) These requirements imply that a Wallet Instance must be aware whether the attestation it is requesting from an issuer is a PID, a QEAA, a PuB-EAA, or a non-qualified EAA. These requirements also imply that the Wallet Unit must store trust anchors in such a way that, when it receives an issued attestation, it is able to distinguish between trust anchors usable either for PIDs, for QEAAs, for PuB-EAAs, or for non-qualified EAAs. |
| ISSU_09 | After a Wallet Unit receives a PuB-EAA from a PUB-EAA Provider, it SHALL validate the qualified signature of the PuB-EAA in accordance with Art. 32 of the [European Digital Identity Regulation]. For that verification, the Wallet Unit SHALL use the public key provided in the qualified certificate of the QTSP supporting the qualified signature. The Wallet Unit SHALL also validate the qualified certificate of the QTSP using a trust anchor provided in a Trusted List made available in accordance with Art. 22 of the [European Digital Identity Regulation]. Finally, the Wallet Unit SHALL also verify the certified attributes of the qualified certificate, as specified in Article 45f. |
| 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. Note: For a non-qualified EAA, an Attestation Rulebook may be available, see [Topic 12], explaining how EAA Providers distribute their trust anchors. However, it is not required for Wallet Units to be in possession of the trust anchors of all non-qualified EAA Providers, even when an Attestation Rulebook is available. |
| ISSU_11 | A Wallet Unit SHALL request the User's approval before storing a PID or attestation obtained from a PID Provider or Attestation Provider. When requesting approval, the Wallet Instance SHALL display the contents of the PID or attestation to the User. The Wallet Instance SHALL also inform the User about the identity of the PID Provider or Attestation Provider, using the subject information in the PID Provider's or Attestation Provider's access certificate. |
| ISSU_11b | In case one or more of the verifications in ISSU_06 - ISSU_11 fail, the Wallet Unit SHALL immediately delete the PID or attestation it received. The Wallet Instance SHALL notify the User about the fact that issuance of the PID or attestation was not successful, including the reason for this failure. |
| ISSU_12 | A PID Provider or Attestation Provider SHALL offer its PIDs or attestations in all formats required in the PID Rulebook or the applicable Attestation Rulebook, see [Topic 12]. Note: Examples include the mdoc format specified in [ISO/IEC 18013-5] and the SD-JWT VC-format specified in [SD-JWT VC]. |
| ISSU_12a | A Wallet Provider SHALL ensure that, when a User instructs their Wallet Unit to request a PID or attestation from a PID Provider or Attestation Provider, the Wallet Unit requests that PID or attestation in all formats offered by the PID Provider or Attestation Provider. Note: Examples include the mdoc format specified in [ISO/IEC 18013-5] and the SD-JWT VC-format specified in [SD-JWT VC]. |
| ISSU_12b | The WSCA/WSCD or a keystore SHALL generate a new key pair for a new PID or attestation, on request the Wallet Instance. This MAY be done either prior to the issuance of any PID or attestation, or during the issuance process. Note: a) See also WUA_05 and WUA_05a. b) In case of synchronous issuing in a remote HSM architecture, re-use of an existing key pair for the new PID or attestation may be acceptable and it may not be necessary to generate a new key pair for each new PID or attestation. |
| ISSU_12c | The expiration date of a PID SHALL be no later than the expiration date of the WUA presented as part of the PID issuance process. Note: This requirement is an implication of WURevocation_18 in Topic 38. If the PID would be valid for longer than the WUA, the PID Provider would not be able to use the revocation information in the WUA to verify the revocation status of the Wallet Unit. |
| 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 expiration date of the WUA presented as part of the attestation issuance process. Note: See note in ISSU_12c. |
| Index | Requirement specification |
|---|---|
| ISSU_13 | A Wallet Provider SHALL ensure that at least one PID Provider is willing to issue a PID complying with [PID Rulebook] to Users of the Wallet Units it provides. |
| ISSU_14 | A PID Provider SHALL ensure that all PIDs it issues to Wallet Units comply with the requirements specified in [PID Rulebook]. |
| ISSU_15 | A PID Provider SHALL support the OpenID4VCI protocol referenced in ISSU_01 for issuing PIDs. |
| ISSU_16 | Empty |
| ISSU_17 | A PID Provider SHALL implement device binding for all PIDs it issues, meaning it SHALL ensure that a PID is cryptographically bound to the WSCA/WSCD included in the Wallet Unit, as specified in Topic 9. Note: Device binding is called 'mdoc authentication' in [ISO/IEC 18013-5] and 'key binding' in [SD-JWT-VC]. |
| ISSU_18 | A PID Provider SHALL verify the identity of the subject of the PID in compliance with Level of Assurance (LoA) High requirements. Note: These requirements will be determined by the relevant eID scheme. |
| ISSU_18a | A PID Provider SHALL ensure that the attributes attested in the PID issued are valid for the identified PID subject at any point of time of PID validity. |
| ISSU_19 | For the verification of a WUA or WIA, a PID Provider SHALL accept the trust anchors in the Wallet Provider LoTE(s) it needs. Note: a) The Wallet Provider LoTE is explained in [Topic 31]. b) It is not mandatory for a PID Provider to accept all Wallet Provider LoTEs, if there are multiple. This is because it is not mandatory for a PID Provider to accept all certified Wallet Solutions in the EUDI Wallet ecosystem. Each PID Provider will choose which LoTEs they need to subscribe to. |
| 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. |
| ISSU_20 | To inform its potential PID subjects about the Wallet Solution(s) they can use for requesting a PID, a PID Provider SHALL publish a list of supported Wallet Solutions in such a way that it can be easily found, for example on the PID Provider's website. Note: This a policy requirement rather than a technical requirement. |
| ISSU_21 | Before issuing a PID, a PID Provider SHALL verify that the Wallet Provider mentioned in the Wallet Unit's WUA and WIA is present in a Wallet Provider LoTE. The PID Provider SHALL also authenticate and validate the WUA and WIA using the trust anchor(s) registered for the Wallet Provider in that LoTE. Moreover, it SHALL verify that the Wallet Units's WUA is not revoked. Note: a) For the WUA, see [Topic 9] and [Topic 38]. b) CIR 2024/2977, Article 3 (9), also allows another authentication mechanism in accordance with an electronic identity scheme notified at assurance level high. However, the ARF does not further specify such other authentication mechanisms, which means that in general they will not be interoperable. |
| 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. |
| ISSU_22a | Empty |
| ISSU_22b | Empty |
| 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. Note: a) Access Certificate Authority LoTEs are explained in [Topic 27]. |
| ISSU_23a | A Wallet Provider SHALL support at least one PID Provider, meaning that its Wallet Units SHALL be capable of requesting the issuance of a PID from these PID Provider(s), and that the Wallet Provider has agreed with the PID Provider(s) that the PID Provider(s) will process such a request according to the agreed rules and procedures. |
| ISSU_23b | Prior to or during installation of a Wallet Instance, the Wallet Provider SHALL notify the User about the PID Provider(s) that are supported by the Wallet Unit. |
| 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. |
| ISSU_24a | Before requesting the issuance of an attestation, 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. Note: The information in the entitlement member included in the Credential Issuer Metadata (3rd option above) is self-declared by the PID Provider. It is up to the Wallet Provider to decide to trust this information if the registration certificate is not available and querying the registry is not successful. |
| Index | Requirement specification |
|---|---|
| ISSU_25 | An Attestation Provider SHALL ensure all attestations issued to Wallet Units comply with the requirements specified in the applicable Rulebook, as described in [Topic 12]. |
| ISSU_26 | An Attestation Provider SHALL support the OpenID4VCI protocol referenced in ISSU_01 for issuing attestations. |
| ISSU_27 | An Attestation Provider SHOULD implement device binding for all attestations it issues. If an issued attestation is device-bound, the Attestation Provider SHALL ensure that the attestation is cryptographically bound to a WSCA/WSCD or a keystore available to the Wallet Unit, as specified in Topic 9. Note: a) Device binding is called 'mdoc authentication' in [ISO/IEC 18013-5] and 'key binding' in [SD-JWT-VC]. b) Implementing mdoc authentication is mandatory in [ISO/IEC 18013-5] and therefore, it is mandatory for attestations complying with that standard. c) An Attestation Provider can indicate the desired level of security for the private key storage in its Credential Issuer metadata . See [OpenID4VCI] section 12.2.4 and Appendix D.2. See also WIAM_14b, WIAM_14c, and WUA_05 and WUA_05a. |
| ISSU_27a | If the subject of the attestation is a natural person, an Attestation Provider SHALL verify the identity of the subject of the attestation, in compliance with applicable requirements and in accordance with relevant standards or Implementing Regulations. Note: Not every attestation has a natural person as its subject. For example, a holiday voucher may be valid for any User that can present it to a Relying Party and therefore has no subject. This is comparable to the concept of a 'bearer token'. |
| ISSU_27b | If applicable, an Attestation Provider SHALL ensure that the attributes attested in the attestation issued are valid for the identified attestation subject. |
| ISSU_27c | The Attestation Provider SHALL verify that the User requesting the attestation has the right to receive it. |
| ISSU_28 | For the verification of a WUA or WIA, an Attestation Provider SHALL accept the trust anchors in the Wallet Provider LoTE. Note: The Wallet Provider LoTE is explained in [Topic 31]. |
| ISSU_29 | A QEAA Provider or PuB-EAA Provider SHALL support all Wallet Solutions, except in case the attestation in question is a Strong User Authentication (SUA) attestation as meant in Topic 20 and the Wallet Provider does not support processing of the transactional data associated with the SUA attestation. Except for such cases, A QEAA Provider or PuB-EAA Provider SHALL NOT discriminate between Wallet Solutions when processing a request for the issuance of an attestation. Note: This requirement is not applicable for non-qualified EAA Providers. For example, a non-qualified EAA Provider may choose to issue attestations in the format specified in [W3C VCDM], see ARB_01a. In that case, it will support only those Wallet Solutions that have implemented this attestation format. |
| ISSU_30 | Before issuing a device-bound attestation, an Attestation Provider SHALL: - verify that the Wallet Provider mentioned in the Wallet Unit's WUA is present in the Wallet Provider LoTE. - authenticate and validate the WUA using the trust anchor(s) registered for the Wallet Provider in that LoTE. - verify that the Wallet Unit's WUA is not revoked. Note: For the WUA, see [Topic 9] and [Topic 38]. |
| 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. Note: This requirement applies to both device-bound and non-device-bound attestations |
| ISSU_31 | Empty |
| 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. |
| ISSU_32a | Empty |
| ISSU_33 | For the verification of access certificates, a Wallet Unit SHALL accept the trust anchors in all LoTE(s) for Access Certificate Authorities. Note: Access Certificate Authority LoTEs are explained in [Topic 27]. |
| ISSU_33a | For the verification of the registration certificates of Attestation Providers, a Wallet Unit SHALL accept the trust anchors in all LoTE(s) for Providers of registration certificates. |
| ISSU_33b | A Wallet Provider SHALL support all Attestation Providers, except possibly if the attestation in question is a Strong User Authentication (SUA) attestation as meant in Topic 20 and the Wallet Provider chooses to not support processing of the transactional data associated with that attestation. Except for such cases, Wallet Units SHALL be capable of requesting the issuance of a QEAA, PuB-EAA, or non-qualified EAA from all Attestation Providers at the User's request. |
| 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]. |
| 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. Note: The information in the entitlement member included in the Credential Issuer Metadata (3rd option above) is self-declared by the Attestation Provider. It is up to the Wallet Provider to decide to trust this information if the registration certificate is not available and querying the registry is not successful. |
| ISSU_34b | Before requesting the issuance of an attestation, the Wallet Unit SHALL verify whether the Provider properly registered for the issuance of the type of attestation that the User wants to obtain. To do so, the Wallet Unit SHALL a) Inspect the providesAttestations 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 providesAttestations, using the URI in the Credential Issuer Metadata, if possible. c) If querying the Registrar is not possible, optionally inspect the providesAttestations 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 registered for the relevant type of attestation, the Wallet Unit SHALL display a warning to the User, and SHALL NOT request the issuance of an attestation. Note: The information in the providesAttestation member included in the Credential Issuer Metadata (3rd option above) is self-declared by the Attestation Provider. It is up to the Wallet Provider to decide to trust this information if the registration certificate is not available and querying the registry is not successful. |