Harmonized_ID;Part;Category;Topic;Topic_Number;Topic_Title;Subsection;Index;Requirement_specification;Notes
EW-PIO-01-001;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 1 - Accessing Online Services with a Wallet Unit;1;Accessing Online Services with a Wallet Unit;;OIA_01;A Wallet Unit SHALL support [OpenID4VP] for remote presentation flows and [ISO/IEC 18013-5] for proximity presentation flows, to receive and respond to presentation requests for person identification data (PID) and attestations by Relying Parties.;
EW-PIO-01-002;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 1 - Accessing Online Services with a Wallet Unit;1;Accessing Online Services with a Wallet Unit;;OIA_02;A Wallet Unit SHALL support proving cryptographic device binding between the WSCA/WSCD or a keystore included in the Wallet Unit and a PID or attestation, in accordance with [SD-JWT VC] or [ISO/IEC 18013-5].;Such a mechanism is called 'mdoc authentication' in [ISO/IEC 18013-5] and 'key binding' in [SD-JWT VC].
EW-PIO-01-003;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 1 - Accessing Online Services with a Wallet Unit;1;Accessing Online Services with a Wallet Unit;;OIA_03;Empty;
EW-PIO-01-004;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 1 - Accessing Online Services with a Wallet Unit;1;Accessing Online Services with a Wallet Unit;;OIA_03a;Wallet Providers SHALL ensure that their Wallet Solution supports the protocol specified in 'OpenID for Verifiable Presentations', see [OpenID4VP], with additions and changes as documented in this Annex and in technical specifications referenced in this Annex.;
EW-PIO-01-005;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 1 - Accessing Online Services with a Wallet Unit;1;Accessing Online Services with a Wallet Unit;;OIA_03b;For remote presentation flows, when the format of the requested attestation complies with [ISO/IEC 18013-5], Relying Parties and Wallet Units SHALL comply with the requirements in the profile for OpenID4VP specified in [ISO/IEC 18013-7] Annex B.;
EW-PIO-01-006;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 1 - Accessing Online Services with a Wallet Unit;1;Accessing Online Services with a Wallet Unit;;OIA_03c;For remote presentation flows, when the format of the requested attestation complies with [SD-JWT VC], Relying Parties and Wallet Units SHALL comply with the requirements in the 'OpenID for Verifiable Presentations for IETF SD-JWT VC' profile specified in [HAIP].;
EW-PIO-01-007;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 1 - Accessing Online Services with a Wallet Unit;1;Accessing Online Services with a Wallet Unit;;OIA_04;A Wallet Unit SHALL verify and process PID or attestation presentation requests from Relying Parties in accordance with the protocols and interfaces specified in [OpenID4VP] for remote flows.;
EW-PIO-01-008;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 1 - Accessing Online Services with a Wallet Unit;1;Accessing Online Services with a Wallet Unit;;OIA_05;After verifying and processing a PID or attestation request, the Wallet Unit SHALL display to the User the identity of the requesting Relying Party and the requested attributes.;
EW-PIO-01-009;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 1 - Accessing Online Services with a Wallet Unit;1;Accessing Online Services with a Wallet Unit;;OIA_06;A Wallet Unit SHALL present the requested attributes only after having received the User's authorisation.;See also OIA_07.
EW-PIO-01-010;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 1 - Accessing Online Services with a Wallet Unit;1;Accessing Online Services with a Wallet Unit;;OIA_07;A Wallet Unit SHALL support selective disclosure of attributes from PIDs and attestations to be released to the requesting Relying Parties.;
EW-PIO-01-011;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 1 - Accessing Online Services with a Wallet Unit;1;Accessing Online Services with a Wallet Unit;;OIA_08;Wallet Units and Relying Party Instances SHALL support the [W3C Digital Credentials API]](<https://wicg.github.io/digital-credentials/>) for remote presentation flows, provided that a) this API is a W3C Recommendation, b) this API complies with the expectations outlined in [Chapter 3](../../discussion-topics/f-digital-credential-api.md#3) of the Topic F discussion paper, and c) this API is broadly supported by relevant browsers and operating systems.;
EW-PIO-01-012;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 1 - Accessing Online Services with a Wallet Unit;1;Accessing Online Services with a Wallet Unit;;OIA_08a;If Wallet Units and Relying Party Instances do not support the [W3C Digital Credentials API], they SHALL implement adequate mitigations for the challenges described in [Section 4.4.3.1](../../architecture-and-reference-framework-main.md#4431-introduction) of the ARF main document.;
EW-PIO-01-013;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 1 - Accessing Online Services with a Wallet Unit;1;Accessing Online Services with a Wallet Unit;;OIA_08b;If a Wallet Unit supports the [W3C Digital Credentials API], it SHALL, by default (see OIA_08d), disclose the presence of all stored attestations (mean their attestation type) to the Digital Credentials API framework, but it SHALL NOT disclose the attributes and their values in these attestations.;The latter restriction applies even if such disclosure would enhance the services provided by the operating system to the Wallet Unit, for example, attestation selection in the context of the Digital Credentials API.
EW-PIO-01-014;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 1 - Accessing Online Services with a Wallet Unit;1;Accessing Online Services with a Wallet Unit;;OIA_08c;If a Relying Party supports the [W3C Digital Credentials API], the Relying Party's presentation request MAY be processed by the browser and/or the operating system for searching available attestations, for preventing fraud targeting the User, or for troubleshooting purposes. Moreover, the request SHOULD be processed by the browser and/or the Operating System for User security purposes. However, the request SHALL NOT be processed by the browser and/or the operating system for market analysis purposes (including as a secondary purpose) or for the browser's and/or the operating system's own purposes.;
EW-PIO-01-015;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 1 - Accessing Online Services with a Wallet Unit;1;Accessing Online Services with a Wallet Unit;;OIA_08d;If a Wallet Unit supports the [W3C Digital Credentials API], it SHALL provide a global User setting to disable the disclosure of stored attestations via the Digital Credentials API framework, as described in OIA_08b. When this setting is disabled, the Wallet Unit SHALL NOT advertise or respond to presentation requests or issuance requested communicated via the DC API.;
EW-PIO-01-016;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 1 - Accessing Online Services with a Wallet Unit;1;Accessing Online Services with a Wallet Unit;;OIA_08e;If a Wallet Unit supports the [W3C Digital Credentials API], it SHALL use the CTAP-Hybrid flow only if the expectations outlined in Chapter 4 of the [Topic F discussion paper](../../discussion-topics/f-digital-credential-api.md) are met.;
EW-PIO-01-017;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 1 - Accessing Online Services with a Wallet Unit;1;Accessing Online Services with a Wallet Unit;;OIA_09;For remote presentation flows the Wallet Unit SHALL ensure that the attributes included in the presented attestation are accessible only to the Relying Party Instance, by encrypting the presentation response. The technical specification meant in OIA_03a SHALL specify mechanisms preventing decryption of the presentation response via Man-in-the-Middle attacks by the browser, the operating system, or other components between the Wallet Unit and the Relying Party.;
EW-PIO-01-018;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 1 - Accessing Online Services with a Wallet Unit;1;Accessing Online Services with a Wallet Unit;;OIA_10;For both proximity and remote presentation flows, if a Wallet Unit contains two PIDs having the same encoding (e.g. ISO/IEC 18013-5 or SD-JWT VC-compliant) and a Relying Party requests a PID, the Wallet Unit SHALL ask the User which of these PIDs they want to release, unless the Wallet Unit can decide from context.;
EW-PIO-01-019;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 1 - Accessing Online Services with a Wallet Unit;1;Accessing Online Services with a Wallet Unit;;OIA_11;For both proximity and remote presentation flows, if a Wallet Unit contains two attestations having the same encoding (e.g. ISO/IEC 18013-5 or SD-JWT VC-compliant) and the same attestation type, and a Relying Party requests an attestation of that type and encoding, the Wallet Unit SHALL ask the User which of these attestations they want to release, unless the Wallet Unit can decide from context.;Attestation types are explained in [[Topic 12](./annex-2.02-high-level-requirements-by-topic.md#a239-topic-12---attestation-rulebooks)].
EW-PIO-01-020;Actor-Specific Requirements;Relying Parties;Topic 1 - Accessing Online Services with a Wallet Unit;1;Accessing Online Services with a Wallet Unit;;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 Trusted List made available in accordance with [[Topic 31](./annex-2.02-high-level-requirements-by-topic.md#a2320-topic-31---notification-and-publication-of-pid-provider-wallet-provider-attestation-provider-access-certificate-authority-and-provider-of-registration-certificates)].;
EW-PIO-01-021;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 1 - Accessing Online Services with a Wallet Unit;1;Accessing Online Services with a Wallet Unit;;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](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG#d1e2162-73-1) of the [European Digital Identity Regulation].;
EW-PIO-01-022;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 1 - Accessing Online Services with a Wallet Unit;1;Accessing Online Services with a Wallet Unit;;OIA_14;For both proximity and remote presentation flows, a Relying Party SHALL validate the qualified signature of a PuB-EAA in accordance with [Art.32](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG#d1e2594-73-1) of the [European Digital Identity Regulation]. For that verification, the Relying Party SHALL use the public key provided in the qualified certificate of the QTSP supporting the qualified signature. The Relying Party 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](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG#d1e2162-73-1) of the [European Digital Identity Regulation]. The Relying Party SHALL also verify the certified attributes of the qualified certificate, as specified in [Article 45f](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e3902-1-1).;
EW-PIO-01-023;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 1 - Accessing Online Services with a Wallet Unit;1;Accessing Online Services with a Wallet Unit;;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](./annex-2.02-high-level-requirements-by-topic.md#a239-topic-12---attestation-rulebooks)].;a) OIA_12 - OIA_15 imply that a Relying Party Instance must know if the attestation it is requesting from a Wallet Instance is a PID, a QEAA, a PuB-EAA, or a non-qualified EAA. These requirements also imply that the Relying Party Instance must store trust anchors in such a way that, at the time of verification, it is able to distinguish between trust anchors usable either for PIDs, for QEAAs, for PuB-EAAs, or for non-qualified EAAs. b) PID Providers, QEAA Providers, and PuB-EAA Providers are trusted by other actors in the EUDI Wallet ecosystem to not fraudulently issue attestations (or PIDs) that they are not legally allowed to issue. This trust is warranted since these kinds of providers operate within a regulated framework and are regularly audited. However, non-qualified EAA Providers are unregulated and may not be completely trustworthy. Therefore, when it receives an non-qualified attestation, a Relying Party Instance may have to verify that the non-qualified EAA Provider is authorised or registered to issue this type of attestation, in addition to verifying the signature over the attestation using the EAA Provider's trust anchor. Mechanisms allowing to do this should be defined in the applicable Rulebook, see ARB_26.
AS-RP-01-002;Actor-Specific Requirements;Relying Parties;Topic 1 - Accessing Online Services with a Wallet Unit;1;Accessing Online Services with a Wallet Unit;;OIA_16;When receiving a PID or attestation, a Relying Party Instance SHALL discard the values of all unique elements, including at least the ones mentioned in requirement ISSU_35 in [Topic 10](./annex-2.02-high-level-requirements-by-topic.md#a237-topic-10---issuing-a-pid-or-attestation-to-a-wallet-unit), as well as any timestamps, as soon as they are no longer needed. The Relying Party Instance SHALL NOT communicate these values to the Relying Party or to any other party inside or outside the EUDI Wallet ecosystem.;
EW-DM-03-01;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 3 - PID Rulebook;3;PID Rulebook;A. Generic HLRs;PID_01;PIDs and PID Providers SHALL comply with all requirements in [PID Rulebook].;
EW-DM-03-02;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 3 - PID Rulebook;3;PID Rulebook;A. Generic HLRs;PID_02;A PID Provider SHALL issue any PID in both the format specified in ISO/IEC 18013-5 [ISO/IEC 18013-5] and the format specified in [SD-JWT VC].;[CIR 2024/2977] mentions the W3C Verifiable Credentials Data Model v1.1 instead of [SD-JWT VC]. The latest stable version of this standard is [W3C VCDM 2.0].  However, W3C VCDM is not a complete specification of an attestation format. In particular, it does not specify a specific proof method to be used. Without additional specification, such as those in [W3C VC-JOSE-COSE] or [W3C VC Data Integrity], and making further choices, it is impossible to implement a PID based on W3C VCDM. This Rulebook considers [SD-JWT VC] to essentially be such an additional specification. See also [Section 5.3.4](../../architecture-and-reference-framework-main.md#534-w3c-verifiable-credentials) of the ARF main document.
EW-DM-03-03;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 3 - PID Rulebook;3;PID Rulebook;A. Generic HLRs;PID_03;The portrait in a PID SHALL consist of a single portrait image in JPEG format. The portrait image SHALL comply with the quality requirements for a Full Frontal Image Type in ISO/IEC 19794-5 clauses 8.2, 8.3, and 8.4. However, the attribute portrait SHALL NOT comply with the format requirements in ISO/IEC 19794-5 clauses 8.1 and 8.5, meaning it SHALL NOT contain any of the headers or blocks specified in clause 5 except for the image data itself (a JPEG).;
EW-DM-03-04;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 3 - PID Rulebook;3;PID Rulebook;B. HLRs for ISO/IEC 18013-5-compliant PIDs;PID_04;PID Providers SHALL use eu.europa.ec.eudi.pid.1 as the attestation type for ISO/IEC 18013-5-compliant PIDs.;a) This identifier uses the general format [Reverse Domain].[Domain Specific Extension]. Since the European Commission controls the domain ec.europa.eu, this attestation type identifier will not collide with any attestation type identifiers defined by other organisations in other Attestation Rulebooks. b) The version number 1 in this identifier is used to distinguish between the first version of the PID, defined in the [PID Rulebook](../annex-3/annex-3.01-pid-rulebook.md), and any future version, which will then have an incremented version number.
EW-DM-03-05;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 3 - PID Rulebook;3;PID Rulebook;B. HLRs for ISO/IEC 18013-5-compliant PIDs;PID_05;When issuing a PID compliant with [ISO/IEC 18013-5], a PID Provider SHALL use the value eu.europa.ec.eudi.pid.1 for the identifier of the namespace for the PID attributes specified in [Section 4.2 of the PID Rulebook](../annex-3/annex-3.01-pid-rulebook.md#42-encoding-of-pid-attributes-and-metadata).;a) The version number 1 allows for future extension(s) or change(s) of the ISO/IEC 18013-5-compliant PID attributes. b) This namespace has the same value as the attestation type specified in requirement PID_04. This is allowed according to ISO/IEC 18013-5.
EW-DM-03-06;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 3 - PID Rulebook;3;PID Rulebook;B. HLRs for ISO/IEC 18013-5-compliant PIDs;PID_06;When issuing a PID compliant with [ISO/IEC 18013-5], a PID Provider MAY include attributes that are not defined in the [PID Rulebook](../annex-3/annex-3.01-pid-rulebook.md). If so, these attributes SHALL be defined within a domestic PID namespace as meant in requirement ARB_10 in [Topic 12](./annex-2.02-high-level-requirements-by-topic.md#a239-topic-12---attestation-rulebooks). The PID Provider SHALL generate the identifier for this domestic PID namespace by appending the applicable ISO 3166-1 alpha-2 country code or the ISO 3166-2 region code, separated by a period, to the PID namespace identifier specified in PID_05, excluding the version number. The PID Provider MAY include a version number in the domestic PID namespace identifier.;For example, the identifier of the first domestic PID namespace for Germany could be eu.europa.ec.eudi.pid.de.1
EW-DM-03-07;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 3 - PID Rulebook;3;PID Rulebook;B. HLRs for ISO/IEC 18013-5-compliant PIDs;PID_07;A PID Provider that defines a domestic namespace SHALL publish the namespace, including all attribute identifiers, their definition, presence and encoding format, in an Attestation Rulebook complying with all applicable requirements in [Topic 12](./annex-2.02-high-level-requirements-by-topic.md#a239-topic-12---attestation-rulebooks).;
EW-DM-03-08;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 3 - PID Rulebook;3;PID Rulebook;B. HLRs for ISO/IEC 18013-5-compliant PIDs;PID_08;When issuing a PID compliant with [ISO/IEC 18013-5], a PID Provider SHALL include both the attributes and the metadata specified in [CIR 2024/2977] in the PID as (issuer-signed or device-signed) data elements.;This implies that technically speaking, there is no difference between these attributes and metadata.
EW-DM-03-09;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 3 - PID Rulebook;3;PID Rulebook;B. HLRs for ISO/IEC 18013-5-compliant PIDs;PID_09;When issuing a PID compliant with [ISO/IEC 18013-5], a PID Provider SHALL encode each attribute or metadata in the PID as specified in the third column of the tables in [Section 4.2.1 of the PID Rulebook](../annex-3/annex-3.01-pid-rulebook.md#421-overview).;
EW-DM-03-10;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 3 - PID Rulebook;3;PID Rulebook;B. HLRs for ISO/IEC 18013-5-compliant PIDs;PID_10;When issuing a PID compliant with [ISO/IEC 18013-5], a PID Provider SHALL encode each attribute or metadata in the PID in Concise Binary Object Representation (CBOR) according to [RFC 8949].;
EW-DM-03-11;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 3 - PID Rulebook;3;PID Rulebook;B. HLRs for ISO/IEC 18013-5-compliant PIDs;PID_11;When issuing a PID compliant with [ISO/IEC 18013-5], a PID Provider SHALL ensure that each PID contains at most one attribute with the same attribute identifier.;
EW-DM-03-12;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 3 - PID Rulebook;3;PID Rulebook;B. HLRs for ISO/IEC 18013-5-compliant PIDs;PID_12;When issuing a PID compliant with [ISO/IEC 18013-5], a PID Provider SHALL ensure that the value of all attributes and metadata in the PID is valid at the value of the timestamp in the validFrom element in the MSO, see [ISO/IEC 18013-5] clause 9.1.2.4.;The value of the age_over_18, age_over_NN, or age_in_years attributes, if present, changes whenever the User to whom the person identification data relates has a relevant birthday. The value of many other attributes will also change over time.
EW-DM-03-13;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 3 - PID Rulebook;3;PID Rulebook;B. HLRs for ISO/IEC 18013-5-compliant PIDs;PID_13;When issuing a PID compliant with [ISO/IEC 18013-5], a PID Provider SHALL ensure that the issuance_date attribute, if present, is not later than the validFrom element in the MSO, see [ISO/IEC 18013-5] clause 9.1.2.4.;
EW-DM-03-14;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 3 - PID Rulebook;3;PID Rulebook;C. HLRs for SD-JWT VC-compliant PIDs;PID_14;A PID Provider issuing [SD-JWT VC]-compliant PIDs SHALL include the vct claim in their PIDs, where the vct claim SHALL be a URN within the `urn:eudi:pid:` namespace. The type indicated by the vct claim SHALL be `urn:eudi:pid:1` for the type defined in this document or a domestic type that extends it.;
EW-DM-03-15;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 3 - PID Rulebook;3;PID Rulebook;C. HLRs for SD-JWT VC-compliant PIDs;PID_15;Empty;
EW-DM-03-16;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 3 - PID Rulebook;3;PID Rulebook;C. HLRs for SD-JWT VC-compliant PIDs;PID_16;A PID Provider that defines a domestic type SHALL publish information about the type, including all claim identifiers, their definition, presence and encoding format, in an Attestation Rulebook complying with all applicable requirements in [Topic 12](./annex-2.02-high-level-requirements-by-topic.md#a239-topic-12---attestation-rulebooks).;
EW-DM-03-17;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 3 - PID Rulebook;3;PID Rulebook;C. HLRs for SD-JWT VC-compliant PIDs;PID_17;When issuing a PID compliant with [SD-JWT VC], a PID Provider SHALL include both the attributes and the metadata specified in [CIR 2024/2977] in the PID as claims.;This implies that technically speaking, there is no difference between these attributes and metadata.
EW-DM-03-18;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 3 - PID Rulebook;3;PID Rulebook;C. HLRs for SD-JWT VC-compliant PIDs;PID_18;When issuing a PID compliant with [SD-JWT VC], a PID Provider SHALL encode each attribute or metadata in the PID as specified in the tables in [Section 5.2 of the PID Rulebook](../annex-3/annex-3.01-pid-rulebook.md#52-encoding-of-pid-attributes).;
EW-DM-03-19;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 3 - PID Rulebook;3;PID Rulebook;C. HLRs for SD-JWT VC-compliant PIDs;PID_19;When issuing a PID compliant with [SD-JWT VC], a PID Provider SHALL ensure that the value of all attributes and metadata in the PID is valid at the value of the timestamp in the nbf claim, if present.;The value of the age-related claims, if present, changes whenever the User to whom the person identification data relates has a relevant birthday. The value of many other attributes will also change over time.
EW-DM-03-20;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 3 - PID Rulebook;3;PID Rulebook;C. HLRs for SD-JWT VC-compliant PIDs;PID_20;When issuing a PID compliant with [SD-JWT VC], a PID Provider SHALL ensure that the date_of_issuance claim, if present, is not later than the value of the timestamp in the nbf claim, if present.;
EW-DM-03-21;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 3 - PID Rulebook;3;PID Rulebook;C. HLRs for SD-JWT VC-compliant PIDs;PID_21;When issuing a PID compliant with [SD-JWT VC], a PID Provider SHALL make all claims (i.e., all top-level properties, all nested properties, and all array entries) selectively disclosable individually, except those claims defined as non-selectively disclosable in [SD-JWT VC].;
EW-DM-04-001;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 4 - mDL Rulebook;4;mDL Rulebook;;mDL_01;mDLs and mDL Providers SHALL comply with all requirements in [mDL Rulebook].;
AS-WP-06-001;Actor-Specific Requirements;Wallet Providers;Topic 6 - Relying Party authentication and User approval;6;Relying Party authentication and User approval;A. Relying Party authentication;RPA_01;The Wallet Unit used by a User, as well as the Relying Party Instance used by the Relying Party, SHALL implement a mechanism for Relying Party authentication in PID or attestation presentation transactions. This mechanism SHALL: - enable the Wallet Unit to identify and authenticate the Relying Party, - enable the Wallet Unit to verify that the request from the Relying Party was not copied and replayed, - use Relying Party Instance access certificates issued in accordance with [[Topic 27](./annex-2.02-high-level-requirements-by-topic.md#a2316-topic-27---registration-of-pid-providers-providers-of-qeaas-pub-eaas-and-non-qualified-eaas-and-relying-parties)].;
AS-WP-06-002;Actor-Specific Requirements;Wallet Providers;Topic 6 - Relying Party authentication and User approval;6;Relying Party authentication and User approval;A. Relying Party authentication;RPA_01a;If a Wallet Unit supports the [W3C Digital Credentials API] for remote presentation flows, it SHALL retain full authority over the process meant in RPA_01. In particular, this process SHALL NOT be handled by a third party, including the browser and the operating system.;
AS-WP-06-003;Actor-Specific Requirements;Wallet Providers;Topic 6 - Relying Party authentication and User approval;6;Relying Party authentication and User approval;A. Relying Party authentication;RPA_02;The Commission SHALL ensure that technical specifications for the Relying Party authentication mechanism mentioned in RPA_01 are created both for Wallet Units complying with [ISO/IEC 18013-5] and for Wallet Units complying with [OpenID4VP]. These specifications SHALL comply with applicable requirements in these standards.;
AS-RP-06-001;Actor-Specific Requirements;Relying Parties;Topic 6 - Relying Party authentication and User approval;6;Relying Party authentication and User approval;A. Relying Party authentication;RPA_02a;The technical specifications mentioned in RPA_02 SHALL ensure that a Relying Party Instance includes its access certificates in the presentation request by value, not by reference.;This ensures that no external requests are necessary to carry out Relying Party authentication, and that transactions are atomic and self-contained.
AS-WP-06-004;Actor-Specific Requirements;Wallet Providers;Topic 6 - Relying Party authentication and User approval;6;Relying Party authentication and User approval;A. Relying Party authentication;RPA_03;A Wallet Unit and a Relying Party Instance SHALL perform Relying Party authentication in all PID or attestation presentation transactions to Relying Parties, whether proximity or remote, using a Relying Party Instance access certificate.;The actions both entities perform differ. For example, while the Relying Party creates a signature over some data in the request, the Wallet Unit validates that signature.
AS-WP-06-005;Actor-Specific Requirements;Wallet Providers;Topic 6 - Relying Party authentication and User approval;6;Relying Party authentication and User approval;A. Relying Party authentication;RPA_04;For the verification of Relying Party Instance access certificates, a Wallet Unit SHALL accept the trust anchors in the Trusted List(s) of Relying Party Access Certificate Authorities of all Member States.;For more information about Relying Party Access Certificate Authorities, please see [[Topic 31](./annex-2.02-high-level-requirements-by-topic.md#a2320-topic-31---notification-and-publication-of-pid-provider-wallet-provider-attestation-provider-access-certificate-authority-and-provider-of-registration-certificates)].
AS-WP-06-006;Actor-Specific Requirements;Wallet Providers;Topic 6 - Relying Party authentication and User approval;6;Relying Party authentication and User approval;A. Relying Party authentication;RPA_05;If Relying Party authentication fails for any reason, the Wallet Instance SHALL inform the User that the identity of the Relying Party could not be verified and that therefore the request is not trustworthy.;
AS-WP-06-007;Actor-Specific Requirements;Wallet Providers;Topic 6 - Relying Party authentication and User approval;6;Relying Party authentication and User approval;A. Relying Party authentication;RPA_06;If Relying Party authentication succeeds, the Wallet Instance SHALL display to the User the name of the Relying Party as included in the Relying Party access certificate, together with the attributes requested by the Relying Party. The Wallet Instance SHALL do so when asking the User for approval according to RPA_07.;If the Relying Party is an intermediary acting on behalf of an intermediated Relying Party, the Wallet Instance displays the names of both the intermediary and the intermediated Relying Party to the User, see RPI_07.
AS-WP-06-008;Actor-Specific Requirements;Wallet Providers;Topic 6 - Relying Party authentication and User approval;6;Relying Party authentication and User approval;A. Relying Party authentication;RPA_06a;If Relying Party authentication fails for any reason, the Wallet Unit SHALL notify the User. In addition, the Wallet Unit SHALL either not present the requested attributes to the Relying Party, or give the User the choice to present the requested attributes or not.;It is up to the Wallet Provider to make a choice for one of these two options.
AS-WP-06-009;Actor-Specific Requirements;Wallet Providers;Topic 6 - Relying Party authentication and User approval;6;Relying Party authentication and User approval;B. User approval;RPA_07;A Wallet Unit SHALL ensure the User approved the release of any attribute(s) in the Wallet Unit to a Relying Party, prior to releasing these attributes. A Wallet Unit SHALL always allow the User to refuse releasing an attribute requested by the Relying Party.;
AS-WP-06-010;Actor-Specific Requirements;Wallet Providers;Topic 6 - Relying Party authentication and User approval;6;Relying Party authentication and User approval;B. User approval;RPA_07a;If a Wallet Unit supports the [W3C Digital Credentials API] for remote presentation flows, it SHALL retain full authority over the process meant in RPA_07. In particular, this process SHALL NOT be handled by a third party, including the browser and the operating system.;
AS-WP-06-011;Actor-Specific Requirements;Wallet Providers;Topic 6 - Relying Party authentication and User approval;6;Relying Party authentication and User approval;B. User approval;RPA_08;A Wallet Unit SHALL authenticate the User before allowing the User to give or refuse approval for releasing any attributes, in accordance with WIAM_14 or WIAM_15, as applicable.;
AS-WP-06-012;Actor-Specific Requirements;Wallet Providers;Topic 6 - Relying Party authentication and User approval;6;Relying Party authentication and User approval;B. User approval;RPA_09;Empty;
AS-WP-06-013;Actor-Specific Requirements;Wallet Providers;Topic 6 - Relying Party authentication and User approval;6;Relying Party authentication and User approval;B. User approval;RPA_10;When asking for User approval, the Wallet Unit SHALL show to the User the User-friendly description of the Relying Party's intended use and, if available, the link to the applicable privacy policy.;The User-friendly description of the Relying Party's intended use is included in  the presentation request and also in the registration certificate, if available. The link to the privacy policy is included in the registration certificate, or in the absence of a registration certificate, the Wallet Unit obtained the link from the Registrar's online service, if the User requested this. See RPRC_19a and other requirements in [Topic 44](./annex-2.02-high-level-requirements-by-topic.md#a2326-topic-44---registration-certificates-for-pid-providers-providers-of-qeaas-pub-eaas-and-non-qualified-eaas-and-relying-parties) for details.
AS-WP-06-014;Actor-Specific Requirements;Wallet Providers;Topic 6 - Relying Party authentication and User approval;6;Relying Party authentication and User approval;B. User approval;RPA_10a;The Wallet Unit SHOULD ensure that the User gives approval either to present all attributes requested in a presentation request, or none of them.;This means that a User should be asked either to approve the presentation of all requested attributes or to deny all of them. The Wallet Unit should not allow partial approval, since this would mean that the Relying Party cannot deliver the service, but nevertheless receives some User attributes. This would be a violation of the User's privacy. Note that a Relying Party is not allowed to request more data than is justified for the intended use. So if the User feels that the Relying Party is actually requesting more data than needed, that implies that the Relying Party is not trustworthy and should not receive any data.
AS-WP-06-015;Actor-Specific Requirements;Wallet Providers;Topic 6 - Relying Party authentication and User approval;6;Relying Party authentication and User approval;B. User approval;RPA_11;When the presentation of an attestation is denied by the User, the Wallet Unit SHALL behave towards the Relying Party as if the attestation did not exist.;
AS-WP-06-016;Actor-Specific Requirements;Wallet Providers;Topic 6 - Relying Party authentication and User approval;6;Relying Party authentication and User approval;B. User approval;RPA_12;When asking for User approval, the Wallet Unit MAY indicate to the User whether the attestation requested by a Relying Party is device-bound or not.;The intent of this indication is to warn the User than a non-device bound attestation may be copied by the Relying Party and presented to a third party.
AS-AP-07-001;Actor-Specific Requirements;Attestation & PID Providers;Topic 7 - Attestation revocation and revocation checking;7;Attestation revocation and revocation checking;;VCR_01;A PID Provider, QEAA Provider, or PuB-EAA Provider SHALL use one of the following methods for revocation of a PID, QEAA, or PuB-EAA: - Only issue short-lived attestations having a validity period of 24 hours or less, such that revocation will never be necessary, - Use an Attestation Status List mechanism specified per VCR_11, or - Use an Attestation Revocation List mechanism specified per VCR_11.;The 24-hour period originates from ETSI EN 319 411-1 V1.4.1, requirement REV-6.2.4-03A. This requires that the process of revocation must take at most 24 hours. Consequently, revocation may make no sense if the attestation is valid for less than 24 hours, because it may reach the end of its validity period before it is revoked.
AS-AP-07-002;Actor-Specific Requirements;Attestation & PID Providers;Topic 7 - Attestation revocation and revocation checking;7;Attestation revocation and revocation checking;;VCR_01a;A Wallet Provider SHALL use either the second or the third of the methods specified in VCR_01 for revocation of a WUA.;Due to requirement WUA_08 in [Topic 9](./annex-2.02-high-level-requirements-by-topic.md#a236-topic-9---wallet-unit-attestation), it is not possible to issue short-lived WUAs. This implies that all WUAs are revocable.
AS-AP-07-003;Actor-Specific Requirements;Attestation & PID Providers;Topic 7 - Attestation revocation and revocation checking;7;Attestation revocation and revocation checking;;VCR_02;For non-qualified EAAs, the relevant Rulebook SHALL specify whether that type of EAA must be revocable. If a non-qualified EAA type must be revocable, the relevant Rulebook SHALL determine which of the methods mentioned in VCR_01 must be implemented by the relevant EAA Providers for the revocation of such an EAA.;
AS-AP-07-004;Actor-Specific Requirements;Attestation & PID Providers;Topic 7 - Attestation revocation and revocation checking;7;Attestation revocation and revocation checking;;VCR_03;If a PID or attestation is revocable, the PID Provider of a given PID, or the Attestation Provider of a given attestation, SHALL be the only party in the EUDI Wallet ecosystem responsible for executing the revocation of that PID or attestation. *Note: A PID Provider, Attestation Provider MAY outsource the operation of the revocation process to a third party.;
AS-AP-07-005;Actor-Specific Requirements;Attestation & PID Providers;Topic 7 - Attestation revocation and revocation checking;7;Attestation revocation and revocation checking;;VCR_03a;The Wallet Provider of a given WUA SHALL be the only party in the EUDI Wallet ecosystem responsible for executing the revocation of that WUA.;A Wallet Provider MAY outsource the operation of the revocation process to a third party.
AS-AP-07-006;Actor-Specific Requirements;Attestation & PID Providers;Topic 7 - Attestation revocation and revocation checking;7;Attestation revocation and revocation checking;;VCR_04;A PID Provider, Attestation Provider or Wallet Provider that revoked a PID, attestation, or WUA SHALL NOT reverse the revocation.;
AS-AP-07-007;Actor-Specific Requirements;Attestation & PID Providers;Topic 7 - Attestation revocation and revocation checking;7;Attestation revocation and revocation checking;;VCR_05;If a PID, attestation, or WUA is revocable, the PID Provider, Attestation Provider, or Wallet Provider SHALL have a policy specifying under which conditions a PID, attestation, or WUA it issued will be revoked.;
AS-AP-07-008;Actor-Specific Requirements;Attestation & PID Providers;Topic 7 - Attestation revocation and revocation checking;7;Attestation revocation and revocation checking;;VCR_06;If a PID, attestation, or WUA is revocable, the PID Provider, Attestation Provider, or Wallet Provider SHALL revoke a PID, attestation, or WUA when its security has been compromised.;
AS-AP-07-009;Actor-Specific Requirements;Attestation & PID Providers;Topic 7 - Attestation revocation and revocation checking;7;Attestation revocation and revocation checking;;VCR_07;A Wallet Provider SHALL revoke all valid WUAs issued to a Wallet Unit upon the explicit request of the User to revoke their Wallet Unit.;
AS-AP-07-010;Actor-Specific Requirements;Attestation & PID Providers;Topic 7 - Attestation revocation and revocation checking;7;Attestation revocation and revocation checking;;VCR_07a;If a PID or attestation is revocable, the PID Provider or Attestation Provider SHOULD revoke that PID or attestation upon the explicit request of the User to whom the PID or the attestation was issued.;
AS-AP-07-011;Actor-Specific Requirements;Attestation & PID Providers;Topic 7 - Attestation revocation and revocation checking;7;Attestation revocation and revocation checking;;VCR_07b;If a PID or attestation is revocable, the PID Provider or Attestation Provider SHOULD revoke that PID if the Wallet Unit on which it resides is revoked, in compliance with requirement WURevocation_18 in [Topic 38](./annex-2.02-high-level-requirements-by-topic.md#a2322-topic-38---wallet-unit-revocation).;
AS-AP-07-012;Actor-Specific Requirements;Attestation & PID Providers;Topic 7 - Attestation revocation and revocation checking;7;Attestation revocation and revocation checking;;VCR_08;If a PID is revocable, the PID Provider SHALL revoke a PID upon the death of the natural person who is the subject of the PID, or the cease of activity of the legal person who is the subject of the PID.;
AS-AP-07-013;Actor-Specific Requirements;Attestation & PID Providers;Topic 7 - Attestation revocation and revocation checking;7;Attestation revocation and revocation checking;;VCR_09;If a PID, attestation, or WUA is revocable, the PID Provider, Attestation Provider or Wallet Provider SHALL revoke a PID, attestation, or WUA if the value of one or more attributes in the PID, attestation, or WUA was changed (including attributes being added or deleted) and it is still valid for at least 24 hours. Subsequently, if the User's contact details are known, the PID Provider, Attestation Provider, or Wallet Provider SHOULD, via an out-of-band manner, notify the User about the revocation and ask the User to request re-issuance of the PID, attestation, or WUA using their Wallet Unit.;If the value of the attributes is determined by a party different from the Provider, such as an Authentic Source, the Provider is responsible for ensuring that this third party notifies them about such changes.
AS-AP-07-014;Actor-Specific Requirements;Attestation & PID Providers;Topic 7 - Attestation revocation and revocation checking;7;Attestation revocation and revocation checking;;VCR_10;Wallet Providers SHALL implement the attestation revocation mechanisms specified per VCR_11 in their Wallet Solutions.;
AS-AP-07-015;Actor-Specific Requirements;Attestation & PID Providers;Topic 7 - Attestation revocation and revocation checking;7;Attestation revocation and revocation checking;;VCR_11;The Commission SHALL create or reference technical specifications providing all necessary details for PID Providers, Attestation Providers, and Wallet Providers to implement an Attestation Status List mechanism or an Attestation Revocation List mechanism for the PIDs, attestations, and WUAs they issue. These technical specifications SHALL also contain all details necessary for Relying Party Instances, Relying Parties, and Wallet Units interacting with other Wallet Units to use these mechanisms to verify the revocation status of PIDs, attestations, and WUAs.;'Attestation Status List' and 'Attestation Revocation List' are specific mechanisms, defined in Annex 1. Attestation Revocation Lists are sometimes referred to as 'Identifier Lists'.
AS-AP-07-016;Actor-Specific Requirements;Attestation & PID Providers;Topic 7 - Attestation revocation and revocation checking;7;Attestation revocation and revocation checking;;VCR_12;If a Relying Party decides it needs to be able to verify the revocation status of PIDs or attestations, it SHALL support both the Attestation Status List mechanism and the Attestation Revocation List mechanism specified per VCR_11.;Per VCR_13, it is recommended but not mandatory for a Relying Party to verify whether a PID or attestation is revoked.
AS-AP-07-017;Actor-Specific Requirements;Attestation & PID Providers;Topic 7 - Attestation revocation and revocation checking;7;Attestation revocation and revocation checking;;VCR_12a;A PID Provider or Attestation Provider SHALL support both the Attestation Status List mechanism and the Attestation Revocation List mechanism specified per VCR_11 for verifying the revocation status of a WUA.;
AS-AP-07-018;Actor-Specific Requirements;Attestation & PID Providers;Topic 7 - Attestation revocation and revocation checking;7;Attestation revocation and revocation checking;;VCR_13;A Relying Party Instance SHOULD verify the revocation status of a PID or attestation upon obtaining it from a Wallet Unit, following the steps specified per VCR_11.;
AS-AP-07-019;Actor-Specific Requirements;Attestation & PID Providers;Topic 7 - Attestation revocation and revocation checking;7;Attestation revocation and revocation checking;;VCR_14;When no reliable information regarding the revocation status of a PID or attestation is available, a Relying Party SHOULD perform a risk analysis considering all relevant factors for the use case, before taking a decision to accept or refuse the PID or attestation.;
AS-AP-07-020;Actor-Specific Requirements;Attestation & PID Providers;Topic 7 - Attestation revocation and revocation checking;7;Attestation revocation and revocation checking;;VCR_15;A Relying Party Instance SHOULD NOT request the relevant Attestation Status List or Attestation Revocation List each time an attestation is presented to it by a Wallet Unit. Rather, the Relying Party operating the Relying Party Instance SHOULD download each new version of the list once, at a time and from a location unrelated to the presentation of a PID or attestation by a User. The Relying Party SHOULD then distribute the list to all of its Relying Party Instances, using an Relying Party-internal distribution mechanism.;
AS-AP-07-021;Actor-Specific Requirements;Attestation & PID Providers;Topic 7 - Attestation revocation and revocation checking;7;Attestation revocation and revocation checking;;VCR_16;A PID Provider, Attestation Provider or Wallet Provider SHALL NOT require the Relying Party or Relying Party Instance to authenticate itself before downloading an Attestation Status List or Attestation Revocation List.;
AS-AP-07-022;Actor-Specific Requirements;Attestation & PID Providers;Topic 7 - Attestation revocation and revocation checking;7;Attestation revocation and revocation checking;;VCR_17;When using an Attestation Status List for revocation, the PID Provider, Attestation Provider or Wallet Provider SHALL randomly assign the index for each PID or attestation, to prevent this index from becoming a correlator.;Randomly assigning indices within a bitstring or byte array is more complicated than creating random identifiers (e.g. serial numbers) for attestations, as is needed for an Attestation Revocation List. This is because duplicate indices and unnecessarily long bitstrings or byte arrays must be prevented.
AS-AP-07-023;Actor-Specific Requirements;Attestation & PID Providers;Topic 7 - Attestation revocation and revocation checking;7;Attestation revocation and revocation checking;;VCR_18;When using an Attestation Status List for revocation, the PID Provider, Attestation Provider, or Wallet Provider SHALL represent a sufficiently large number of PIDs, attestations, or WUAs on each Attestation Status List to ensure herd privacy.;In this context, herd privacy means that if an entity requests a particular status list, the PID Provider, Attestation Provider, or Wallet Provider is not able to deduce which PID, attestation or WUA (likely) was presented to that entity. Complying with this requirement may be difficult in case the number of PIDs, attestations, or WUAs to be represented on the list is small. In such a case, decoy entries can be added to the list to obfuscate the real number of referenced PIDs, attestations, or WUAs.
AS-AP-07-024;Actor-Specific Requirements;Attestation & PID Providers;Topic 7 - Attestation revocation and revocation checking;7;Attestation revocation and revocation checking;;VCR_19;A Wallet Unit SHOULD regularly check the revocation status of its PIDs, attestations, and WUAs, and notify the User if a PID, attestation, or WUA (i.e, the Wallet Unit itself), is revoked.;
AS-WP-09-001;Actor-Specific Requirements;Wallet Providers;Topic 9 - Wallet Unit Attestation;9;Wallet Unit Attestation;A. Support for WUA Use Cases;WUA_01;A WUA SHALL contain information about the capabilities of the WSCA/ WSCD of the Wallet Unit, such that a PID Provider or Attestation Provider is able to take a well-grounded decision on whether to issue a PID or attestation to the Wallet Unit.;
AS-WP-09-002;Actor-Specific Requirements;Wallet Providers;Topic 9 - Wallet Unit Attestation;9;Wallet Unit Attestation;A. Support for WUA Use Cases;WUA_02;The WUA SHALL enable PID Providers and Attestation Providers to verify the authenticity and revocation status of the Wallet Unit.;
AS-WP-09-003;Actor-Specific Requirements;Wallet Providers;Topic 9 - Wallet Unit Attestation;9;Wallet Unit Attestation;A. Support for WUA Use Cases;WUA_03;A Wallet Provider SHALL ensure that a non-revoked Wallet Unit at all times can present a WUA, when requested by a PID Provider or Attestation Provider.;
AS-WP-09-004;Actor-Specific Requirements;Wallet Providers;Topic 9 - Wallet Unit Attestation;9;Wallet Unit Attestation;A. Support for WUA Use Cases;WUA_04;Empty;
AS-WP-09-005;Actor-Specific Requirements;Wallet Providers;Topic 9 - Wallet Unit Attestation;9;Wallet Unit Attestation;A. Support for WUA Use Cases;WUA_05;During issuance of a PID, the Wallet Unit SHALL request the WSCA/WSCD to generate a new key pair for the new PID. The Wallet Unit SHALL provide the PID Provider with a valid WUA describing the properties of the WSCA/WSCD that generated the new PID private key.;A PID private key is always generated and managed by the WSCA/WSCD, which by definition complies with requirements for Level of Assurance High.
AS-WP-09-006;Actor-Specific Requirements;Wallet Providers;Topic 9 - Wallet Unit Attestation;9;Wallet Unit Attestation;A. Support for WUA Use Cases;WUA_05a;During issuance of a device-bound attestation, a Wallet Unit SHALL retrieve the requirements of the Attestation Provider regarding key storage from the Credential Issuer metadata (see ISSU_27). The Wallet Unit SHALL determine which of its WSCA/WSCD or keystore(s), if any, comply with these requirements. If a compliant WSCA/WSCD or keystore is available to the Wallet Unit, the Wallet Unit SHALL request it to generate a new key pair for the new attestation. The Wallet Unit SHALL provide the Attestation Provider with a valid WUA.;A WUA describes the properties of the WSCA/WSCD, not a keystore (see WUA_01) and contains a public key corresponding to a private key in the WSCA/WSCD, not in a keystore (WUA_09). If the Attestation Provider has a need for a key attestation of the new attestation key generated by a keystore, it can optionally use the mechanisms for key attestation as provided by the OS of the User's device.
AS-WP-09-007;Actor-Specific Requirements;Wallet Providers;Topic 9 - Wallet Unit Attestation;9;Wallet Unit Attestation;A. Support for WUA Use Cases;WUA_06;If a Wallet Unit contains a WSCA/WSCD and one or more keystores, it SHALL, internally and securely, keep track of which PID(s) and attestation(s) are bound to which WSCA/WSCD or keystore.;
AS-WP-09-008;Actor-Specific Requirements;Wallet Providers;Topic 9 - Wallet Unit Attestation;9;Wallet Unit Attestation;A. Support for WUA Use Cases;WUA_07;A Wallet Unit SHALL present a WUA only to a PID Provider or Attestation Provider, as part of the issuance process of a PID or an attestation.;
AS-WP-09-009;Actor-Specific Requirements;Wallet Providers;Topic 9 - Wallet Unit Attestation;9;Wallet Unit Attestation;A. Support for WUA Use Cases;WUA_08;A WUA SHALL enable PID Providers to request a Wallet Provider to revoke a Wallet Unit, in accordance with requirement WURevocation_11, by including an identifier for the Wallet Unit in the WUA. The Wallet Provider SHALL ensure that this Wallet Unit identifier does not enable tracking of the User.;a) This is a legal requirement from [CIR 2024/2977]. See also [Section 6.5.3.4 of the ARF main document](../../architecture-and-reference-framework-main.md#6534-wallet-provider-issues-one-or-more-wallet-unit-attestations-to-the-wallet-unit). b) The Wallet Unit identifier meant here can be the same as the one used for revoking the WUA, for instance a URI and index to an Attestation Status List (see [Topic 7](./annex-2.02-high-level-requirements-by-topic.md#a235-topic-7---attestation-revocation-and-revocation-checking)).
AS-WP-09-010;Actor-Specific Requirements;Wallet Providers;Topic 9 - Wallet Unit Attestation;9;Wallet Unit Attestation;B. WUA in relation Cryptographic Keys ;WUA_09;A WUA SHALL contain a public key, and the corresponding private key SHALL be generated by the WSCA/WSCD described in the WUA.;
AS-WP-09-011;Actor-Specific Requirements;Wallet Providers;Topic 9 - Wallet Unit Attestation;9;Wallet Unit Attestation;B. WUA in relation Cryptographic Keys ;WUA_10;Empty (moved to [Topic 18](./annex-2.02-high-level-requirements-by-topic.md#a2311-topic-18---combined-presentations-of-attributes));
AS-WP-09-012;Actor-Specific Requirements;Wallet Providers;Topic 9 - Wallet Unit Attestation;9;Wallet Unit Attestation;B. WUA in relation Cryptographic Keys ;WUA_11;During PID or attestation issuance, the PID Provider SHALL verify that the WSCA/WSCD described in the WUA received from the Wallet Unit has proven possession of the private key corresponding to the public key in the WUA.;This requirement also applies for the issuance of non-device bound attestations.
AS-WP-09-013;Actor-Specific Requirements;Wallet Providers;Topic 9 - Wallet Unit Attestation;9;Wallet Unit Attestation;B. WUA in relation Cryptographic Keys ;WUA_11a;During issuance of a PID or a device-bound attestation, the PID Provider or Attestation Provider SHALL verify that the WSCA/WSCD or a keystore has proven possession of the new PID or attestation private key.;
AS-WP-09-014;Actor-Specific Requirements;Wallet Providers;Topic 9 - Wallet Unit Attestation;9;Wallet Unit Attestation;B. WUA in relation Cryptographic Keys ;WUA_11b;During issuance of a PID, the PID Provider SHOULD verify a proof of cryptographic binding generated by the WSCA/WSCD per requirement ACP_01, if present, to verify that the new PID private key is managed by the same WSCA/WSCD as the WUA private key.;a) This requirement only applies to a PID, since the Wallet Unit can not provide this proof for an attestation bound to a keystore. b) The three proofs mentioned in WUA_11, WUA_11a and WUA_11b MAY be implemented as a single cryptographic proof.
AS-WP-09-015;Actor-Specific Requirements;Wallet Providers;Topic 9 - Wallet Unit Attestation;9;Wallet Unit Attestation;B. WUA in relation Cryptographic Keys ;WUA_12;The Wallet Unit SHALL be able to prove that it possesses the private key corresponding to the public key in the WUA.;
AS-WP-09-016;Actor-Specific Requirements;Wallet Providers;Topic 9 - Wallet Unit Attestation;9;Wallet Unit Attestation;B. WUA in relation Cryptographic Keys ;WUA_13;Empty;
AS-WP-09-017;Actor-Specific Requirements;Wallet Providers;Topic 9 - Wallet Unit Attestation;9;Wallet Unit Attestation;B. WUA in relation Cryptographic Keys ;WUA_14;Empty (moved to [Topic 18](./annex-2.02-high-level-requirements-by-topic.md#a2311-topic-18---combined-presentations-of-attributes));
AS-WP-09-018;Actor-Specific Requirements;Wallet Providers;Topic 9 - Wallet Unit Attestation;9;Wallet Unit Attestation;B. WUA in relation Cryptographic Keys ;WUA_15;Empty;
AS-WP-09-019;Actor-Specific Requirements;Wallet Providers;Topic 9 - Wallet Unit Attestation;9;Wallet Unit Attestation;B. WUA in relation Cryptographic Keys ;WUA_16;If the WSCA/WSCD is able to export a private key, the Wallet Provider SHALL specify this capability as an attribute in the WUA.;
AS-WP-09-020;Actor-Specific Requirements;Wallet Providers;Topic 9 - Wallet Unit Attestation;9;Wallet Unit Attestation;C. Requirements regarding privacy;WUA_17;A Wallet Provider SHALL consider all relevant factors, including offline usage, interoperability, and the risk of a WUA becoming a vector to track the User, when deciding on the validity period of a WUA. ;Regarding interoperability, see ISSU_12c, which limits the validity period of PIDs issued based on the validity period of the WUA
AS-WP-09-021;Actor-Specific Requirements;Wallet Providers;Topic 9 - Wallet Unit Attestation;9;Wallet Unit Attestation;C. Requirements regarding privacy;WUA_18;A Wallet Unit SHALL release a WUA only to a PID Provider or Attestation Provider, and not to a Relying Party or any other entity.;
AS-WP-09-022;Actor-Specific Requirements;Wallet Providers;Topic 9 - Wallet Unit Attestation;9;Wallet Unit Attestation;D. Miscellaneous requirements;WUA_19;Empty;
AS-WP-09-023;Actor-Specific Requirements;Wallet Providers;Topic 9 - Wallet Unit Attestation;9;Wallet Unit Attestation;D. Miscellaneous requirements;WUA_20;A Wallet Provider SHALL ensure that its Wallet Units comply with all relevant requirements specified in [Technical Specification 3](../../technical-specifications/ts3-wallet-unit-attestation.md).;
AS-WP-09-024;Actor-Specific Requirements;Wallet Providers;Topic 9 - Wallet Unit Attestation;9;Wallet Unit Attestation;D. Miscellaneous requirements;WUA_20a;A PID Provider or Attestation Provider SHALL comply with all relevant requirements specified in [Technical Specification 3](../../technical-specifications/ts3-wallet-unit-attestation.md).;
AS-WP-09-025;Actor-Specific Requirements;Wallet Providers;Topic 9 - Wallet Unit Attestation;9;Wallet Unit Attestation;D. Miscellaneous requirements;WUA_21;Empty;
EW-PIO-10-001;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;A - Generic HLRs;ISSU_01;Wallet Providers SHALL ensure that their Wallet Solution supports the OpenID4VCI protocol specified in [OpenID4VCI], as profiled by the 'OpenID for Verifiable Credential Issuance' profile specified in [HAIP], and with additions and changes as documented in this Annex (see e.g. this Topic and [[Topic 9](./annex-2.02-high-level-requirements-by-topic.md#a236-topic-9---wallet-unit-attestation)]) and in future technical specifications created by or on behalf of the Commission.;
AS-AP-10-001;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;A - Generic HLRs;ISSU_01a;PID Providers and Attestation Providers SHALL support the OpenID4VCI protocol specified in [OpenID4VCI], as profiled by the 'OpenID for Verifiable Credential Issuance' profile specified in [HAIP], and with additions and changes as documented in this Annex (see e.g. this Topic and [[Topic 9](./annex-2.02-high-level-requirements-by-topic.md#a236-topic-9---wallet-unit-attestation)]) and in future technical specifications created by or on behalf of the Commission.;
AS-AP-10-002;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;A - Generic HLRs;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.;
AS-AP-10-003;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;A - Generic HLRs;ISSU_03;Wallet Units, PID Providers, and Attestation Providers SHALL support the [W3C Digital Credentials API]](<https://wicg.github.io/digital-credentials/>) for the issuance of PIDs and attestations, provided that a) this API is a W3C Recommendation, b) this API complies with the expectations outlined in [Chapter 3](../../discussion-topics/f-digital-credential-api.md#3)  of the Topic F discussion paper, and c) this API is broadly supported by relevant browsers and operating systems.;
AS-AP-10-004;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;A - Generic HLRs;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.;
AS-AP-10-005;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;A - Generic HLRs;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](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32015R1502) Section 2.2.2. The Wallet Unit SHALL NOT allow a User to use a non-activated PID.;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.
AS-AP-10-006;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;A - Generic HLRs;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.;
AS-AP-10-007;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;A - Generic HLRs;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 provided in a PID Provider Trusted List made available in accordance with [[Topic 31](./annex-2.02-high-level-requirements-by-topic.md#a2320-topic-31---notification-and-publication-of-pid-provider-wallet-provider-attestation-provider-access-certificate-authority-and-provider-of-registration-certificates)], unless this would result in the validation of the PID signature being done by the same component that created the signature.;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.
AS-AP-10-008;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;A - Generic HLRs;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](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG#d1e2162-73-1) of the [European Digital Identity Regulation].;
AS-AP-10-009;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;A - Generic HLRs;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](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG#d1e2162-73-1) 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](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e3902-1-1).;
AS-AP-10-010;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;A - Generic HLRs;ISSU_10;After a Wallet Unit receives a non-qualified EAA from an EAA Provider, it SHALL validate the signature of the EAA using a trust anchor provided according to the mechanism(s) specified in the applicable Rulebook, see [[Topic 12](./annex-2.02-high-level-requirements-by-topic.md#a239-topic-12---attestation-rulebooks)].;a) Requirements ISSU_07 to ISSU_10 are equivalent to requirements OIA_12 to OIA_15 in [Topic 1](./annex-2.02-high-level-requirements-by-topic.md#a231-topic-1---accessing-online-services-with-a-wallet-unit). 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. c) PID Providers, QEAA Providers, and PuB-EAA Providers are trusted by other actors in the EUDI Wallet ecosystem to not fraudulently issue attestations (or PIDs) that they are not legally allowed to issue. This trust is warranted since these kinds of providers operate within a regulated framework and are regularly audited. However, non-qualified EAA Providers are unregulated and may not be completely trustworthy. Therefore, before requesting an non-qualified attestation, a Wallet Unit may need to verify that the non-qualified EAA Provider is authorised or registered to issue this type of attestation. Mechanisms allowing to do this may be defined in the applicable Rulebook, see ARB_26.
AS-AP-10-011;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;A - Generic HLRs;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.;
AS-AP-10-012;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;A - Generic HLRs;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.;
AS-AP-10-013;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;A - Generic HLRs;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](./annex-2.02-high-level-requirements-by-topic.md#a239-topic-12---attestation-rulebooks)].;Examples include the mdoc format specified in [ISO/IEC 18013-5] and the SD-JWT VC-format specified in [SD-JWT VC].
AS-AP-10-014;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;A - Generic HLRs;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.;Examples include the mdoc format specified in [ISO/IEC 18013-5] and the SD-JWT VC-format specified in [SD-JWT VC].
AS-AP-10-015;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;A - Generic HLRs;ISSU_12b;During issuance of a PID or a device-bound attestation, the WSCA/WSCD or a key store SHALL generate a new key pair for a new PID or attestation, on request of the PID Provider or Attestation Provider via the Wallet Instance.;See also WUA_05. 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.
AS-AP-10-016;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;A - Generic HLRs;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.;This requirement is an implication of WURevocation_18 in [Topic 38](./annex-2.02-high-level-requirements-by-topic.md#a2322-topic-38---wallet-unit-revocation). 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.
AS-AP-10-017;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;A - Generic HLRs;ISSU_12d;If an Attestation Provider supports revocation chaining for its attestations per WURevocation_19 in [Topic 38](./annex-2.02-high-level-requirements-by-topic.md#a2322-topic-38---wallet-unit-revocation), 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.;See note in ISSU_12c.
AS-AP-10-018;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;B - HLRs for PID issuance;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.;
AS-AP-10-019;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;B - HLRs for PID issuance;ISSU_14;A PID Provider SHALL ensure that all PIDs it issues to Wallet Units comply with the requirements specified in [PID Rulebook].;
AS-AP-10-020;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;B - HLRs for PID issuance;ISSU_15;A PID Provider SHALL support the OpenID4VCI protocol referenced in ISSU_01 for issuing PIDs.;
AS-AP-10-021;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;B - HLRs for PID issuance;ISSU_16;Empty;
AS-AP-10-022;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;B - HLRs for PID issuance;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 requirements WUA_11 - WUA_11b in [[Topic 9](./annex-2.02-high-level-requirements-by-topic.md#a236-topic-9---wallet-unit-attestation)].;Device binding is called 'mdoc authentication' in [ISO/IEC 18013-5] and 'key binding' in [SD-JWT-VC].
AS-AP-10-023;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;B - HLRs for PID issuance;ISSU_18;A PID Provider SHALL verify the identity of the subject of the PID in compliance with Level of Assurance (LoA) High requirements.;These requirements will be determined by the relevant eID scheme.
AS-AP-10-024;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;B - HLRs for PID issuance;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.;
AS-AP-10-025;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;B - HLRs for PID issuance;ISSU_19;For the verification of a WUA, a PID Provider SHALL accept the trust anchors in the Wallet Provider Trusted List it needs.;a) The Wallet Provider Trusted List is explained in [[Topic 31](./annex-2.02-high-level-requirements-by-topic.md#a2320-topic-31---notification-and-publication-of-pid-provider-wallet-provider-attestation-provider-access-certificate-authority-and-provider-of-registration-certificates)]. b) It is not mandatory for a PID Provider to accept all Wallet Provider Trusted Lists, 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 Trusted Lists they need to subscribe to.
AS-AP-10-026;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;B - HLRs for PID issuance;ISSU_19a;A PID Provider SHALL support at least one Wallet Solution, meaning that it is willing and able to issue a PID to a Wallet Unit on request of the User.;
AS-AP-10-027;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;B - HLRs for PID issuance;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.;
AS-AP-10-028;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;B - HLRs for PID issuance;ISSU_21;Before issuing a PID, a PID Provider SHALL verify that the Wallet Provider mentioned in the Wallet Unit's WUA is present in a Wallet Provider Trusted List. The PID Provider SHALL also authenticate and validate the WUA using the trust anchor(s) registered for the Wallet Provider in the Wallet Provider Trusted List. Moreover, it SHALL verify that the Wallet Units's WUA is not revoked.;a) For the WUA, see [[Topic 9](./annex-2.02-high-level-requirements-by-topic.md#a236-topic-9---wallet-unit-attestation)] and [[Topic 38](./annex-2.02-high-level-requirements-by-topic.md#a2322-topic-38---wallet-unit-revocation)]. b) [CIR 2024/2977](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2977), 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.
AS-AP-10-029;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;B - HLRs for PID issuance;ISSU_22;A PID Provider SHALL include its PID Provider access certificate in its Issuer metadata used in the common OpenID4VCI protocol referenced in ISSU_01.;
AS-AP-10-030;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;B - HLRs for PID issuance;ISSU_22a;A PID Provider SHALL sign its metadata (as defined in OpenID4VCI) using the private key corresponding to its PID Provider access certificate.;
AS-AP-10-031;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;B - HLRs for PID issuance;ISSU_22b;The common OpenID4VCI protocol referenced in requirement ISSU_01, or an EUDI Wallet-specific extension or profile thereof, SHALL enable a PID Provider or Attestation Provider to include its access certificate and registration certificate in its Issuer metadata, according to requirement ISSU_22 and RPRC_22, respectively.;
AS-AP-10-032;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;B - HLRs for PID issuance;ISSU_23;For the verification of PID Provider access certificates, a Wallet Unit SHALL accept the trust anchors in the Trusted List(s) of Access Certificate Authorities it needs.;a) Access Certificate Authority Trusted Lists are explained in [[Topic 27](./annex-2.02-high-level-requirements-by-topic.md#a2316-topic-27---registration-of-pid-providers-providers-of-qeaas-pub-eaas-and-non-qualified-eaas-and-relying-parties)]. b) It is not mandatory for a Wallet Unit to accept all Access Certificate Authority Trusted Lists for PID Providers, if there are multiple. Wallet Providers will choose which of these Trusted Lists they need to subscribe to, for example depending on the Member State(s) they are operating in.
AS-AP-10-033;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;B - HLRs for PID issuance;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.;
AS-AP-10-034;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;B - HLRs for PID issuance;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.;
AS-AP-10-035;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;B - HLRs for PID issuance;ISSU_24;A Wallet Unit SHALL authenticate and validate the PID Provider access certificate 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 a CA that is in a Access Certificate Authority Trusted List.;
AS-AP-10-036;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;B - HLRs for PID issuance;ISSU_24a;Before requesting the issuance of a PID, the Wallet Unit SHALL verify that the PID Provider is indeed a registered PID Provider. The Wallet Unit SHALL do so using information contained in the PID Provider registration certificate, if available in the Credential Issuer metadata of the PID Provider. If the registration certificate is not available, the Wallet Unit SHALL use the URL of the Registrar's online service, contained in the Credential Issuer metadata, to obtain the necessary information from the Registrar. If the registered information 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.;
AS-AP-10-037;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;C - HLRs for Attestation Issuance;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](./annex-2.02-high-level-requirements-by-topic.md#a239-topic-12---attestation-rulebooks)].;
AS-AP-10-038;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;C - HLRs for Attestation Issuance;ISSU_26;An Attestation Provider SHALL support the OpenID4VCI protocol referenced in ISSU_01 for issuing attestations.;
AS-AP-10-039;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;C - HLRs for Attestation Issuance;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 requirement WUA_11 - WUA_11b in [[Topic 9](./annex-2.02-high-level-requirements-by-topic.md#a236-topic-9---wallet-unit-attestation)].;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]; 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.
AS-AP-10-040;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;C - HLRs for Attestation Issuance;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.;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'.
AS-AP-10-041;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;C - HLRs for Attestation Issuance;ISSU_27b;If applicable, an Attestation Provider SHALL ensure that the attributes attested in the attestation issued are valid for the identified attestation subject.;
AS-AP-10-042;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;C - HLRs for Attestation Issuance;ISSU_27c;The Attestation Provider SHALL verify that the User requesting the attestation has the right to receive it.;
AS-AP-10-043;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;C - HLRs for Attestation Issuance;ISSU_28;For the verification of a WUA, an Attestation Provider SHALL accept the trust anchors in the Wallet Provider Trusted List.;The Wallet Provider Trusted List is explained in [[Topic 31](./annex-2.02-high-level-requirements-by-topic.md#a2320-topic-31---notification-and-publication-of-pid-provider-wallet-provider-attestation-provider-access-certificate-authority-and-provider-of-registration-certificates)].
AS-AP-10-044;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;C - HLRs for Attestation Issuance;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](./annex-2.02-high-level-requirements-by-topic.md#a2313-topic-20---strong-user-authentication-for-electronic-payments) 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.;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.
AS-AP-10-045;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;C - HLRs for Attestation Issuance;ISSU_30;Before issuing an attestation, an Attestation Provider SHALL: - verify that the Wallet Provider mentioned in the Wallet Unit's WUA is present in the Wallet Provider Trusted List. - authenticate and validate the WUA using the trust anchor(s) registered for the Wallet Provider in the Wallet Provider Trusted List. - verify that the Wallet Unit's WUA is not revoked.;For the WUA, see [[Topic 9](./annex-2.02-high-level-requirements-by-topic.md#a236-topic-9---wallet-unit-attestation)] and [[Topic 38](./annex-2.02-high-level-requirements-by-topic.md#a2322-topic-38---wallet-unit-revocation)].
AS-AP-10-046;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;C - HLRs for Attestation Issuance;ISSU_31;Empty;
AS-AP-10-047;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;C - HLRs for Attestation Issuance;ISSU_32;An Attestation Provider SHALL include its Attestation Provider access certificate and registration certificate(s) in its Issuer metadata used in the common OpenID4VCI protocol referenced in ISSU_01.;
AS-AP-10-048;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;C - HLRs for Attestation Issuance;ISSU_32a;An Attestation Provider SHALL sign its metadata (as defined in OpenID4VCI) using the private key corresponding to its Attestation Provider access certificate.;
AS-AP-10-049;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;C - HLRs for Attestation Issuance;ISSU_33;For the verification of Attestation Provider access certificates, a Wallet Unit SHALL accept the trust anchors in all applicable Access Certificate Authority Trusted List(s).;Access Certificate Authority Trusted Lists are explained in [[Topic 27](./annex-2.02-high-level-requirements-by-topic.md#a2316-topic-27---registration-of-pid-providers-providers-of-qeaas-pub-eaas-and-non-qualified-eaas-and-relying-parties)]. There may be separate Access Certificate Authority Trusted Lists for QEAA Providers, PuB-EAA Providers, and EAA Providers.
AS-AP-10-050;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;C - HLRs for Attestation Issuance;ISSU_33a;For the verification of Attestation Provider registration certificates, a Wallet Unit SHALL accept the trust anchors in all Trusted List(s) for Providers of registration certificates.;
AS-AP-10-051;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;C - HLRs for Attestation Issuance;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](./annex-2.02-high-level-requirements-by-topic.md#a2313-topic-20---strong-user-authentication-for-electronic-payments) 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.;
AS-AP-10-052;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;C - HLRs for Attestation Issuance;ISSU_34;A Wallet Unit SHALL authenticate and validate the Attestation Provider access certificate 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 a CA that is in an Access Certificate Authority Trusted List, as documented in [[Topic 27](./annex-2.02-high-level-requirements-by-topic.md#a2316-topic-27---registration-of-pid-providers-providers-of-qeaas-pub-eaas-and-non-qualified-eaas-and-relying-parties)].;
AS-AP-10-053;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;C - HLRs for Attestation Issuance;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. The Wallet Unit SHALL also verify the Provider's sub-entitlements, i.e., whether the Provider properly registered for the issuance of the type of attestation that the User wants to obtain. The Wallet Unit SHALL do these checks using information contained in the Attestation Provider registration certificate, if available in the Credential Issuer metadata of the Attestation Provider. If the registration certificate is not available, the Wallet Unit SHALL use the URL of the Registrar's online service, contained in the Credential Issuer metadata, to obtain such information. If the registered information does not confirm that the Attestation Provider is indeed registered as a QEAA Provider, PuB-EAA Provider, or EAA Provider, or if the registered information 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.;
AS-AP-10-054;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;D - HLRs for Privacy Risks and Mitigation ;ISSU_35;A PID Provider or Attestation Provider SHALL ensure that all unique elements in a PID or attestation have a negligible chance of having the same value across all PIDs or attestations issued by that Provider. This SHALL include at least a) the salt used for hashing every attribute, b) the hash values of all attributes, c) the attestation identifier or index used for revocation purposes (if applicable), d) the attestation public key used for device binding (if applicable), and e) the value of the Attestation Provider signature.;a) The list of unique elements is based on [ISO/IEC 18013-5] and [SD-JWT VC]. b) This requirement can be achieved, for example, by ensuring that salt values, indexes and attestation identifiers are pseudo-random numbers generated by a cryptographically secure pseudo-random number generator (CSPRNG).
AS-AP-10-055;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;D - HLRs for Privacy Risks and Mitigation ;ISSU_35a;A Wallet Provider SHALL ensure that all unique elements in a WUA have a negligible chance of having the same value across all WUAs issued by that Wallet Provider. This SHALL include at least a) the attestation identifier or index used for revocation purposes, b) the WUA public key used for device binding, and c) the value of the Wallet Provider signature.;a) The list of unique elements is based on [Technical Specification 3](../../technical-specifications/ts3-wallet-unit-attestation.md). b) This requirement can be achieved, for example, by ensuring that indexes are pseudo-random numbers generated by a cryptographically secure pseudo-random number generator (CSPRNG).
AS-AP-10-056;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;D - HLRs for Privacy Risks and Mitigation ;ISSU_35b;After issuing a PID, attestation, or WUA, a PID Provider, Attestation Provider or Wallet Provider SHALL discard the values of all unique elements, including at least the ones mentioned in requirement ISSU_35 or ISSU_35a (as applicable) above, as well as any timestamps, as soon as they are no longer needed. The Provider SHALL NOT communicate these values to any other party inside or outside the EUDI Wallet ecosystem.;
AS-AP-10-057;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;D - HLRs for Privacy Risks and Mitigation ;ISSU_36;When issuing PIDs, attestations, or WUAs in a batch to a Wallet Unit, a PID Provider, Attestation Provider, or Wallet Provider SHALL ensure that the timestamps in these PIDs, attestations, or WUAs do not enable Relying Parties to conclude that they are part of the same batch (and therefore belong to the same User).;This can be done, for example, by making timestamps sufficiently imprecise that a high number of batches, each issued to a different Wallet Unit, share the same timestamp values (herd privacy).
AS-AP-10-058;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;D - HLRs for Privacy Risks and Mitigation ;ISSU_37;A Wallet Provider SHALL ensure that its Wallet Solution supports the following methods for limiting the number of times a User can present the same PID or attestation to Relying Parties: Method A (Once-only attestations, as specified in requirement ISSU_43 - ISSU_47) and Method B (Limited-time attestations, as specified in requirement ISSU_48 - ISSU_50). In addition, a Wallet Provider MAY ensure that its Wallet Solution supports Method C (Rotating-batch attestations, as specified in requirement ISSU_51 - ISSU_54) or Method D (Per-Relying Party attestations, as specified in requirement ISSU_55 - ISSU_57).;Wallet Solutions, PID Providers, Attestation Providers, and Wallet Providers are free to define and use other methods as well. However, such other methods are out of scope of the ARF.
AS-AP-10-059;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;D - HLRs for Privacy Risks and Mitigation ;ISSU_38;A PID Provider, Attestation Provider, or Wallet Provider SHALL have a policy describing which of the methods A, B, C, or D, it will use to limit the number of times a Wallet Unit may present a single PID, attestation, or WUA. For each supported method, the policy SHALL also specify how the values for respective parameters for that method, such as technical validity period and batch size, will be chosen. The goal of the policy SHALL be to ensure that the risk of linkability is mitigated to an acceptable level, given the (expected) usage of the PID, attestation, or WUA by the User. To determine what an acceptable level of risk is, the PID Provider, Attestation Provider, or Wallet Provider SHALL carry out a risk analysis regarding linkability.;If an Attestation Provider issues multiple attestation types, these requirements apply for each type of attestation separately.
AS-AP-10-060;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;D - HLRs for Privacy Risks and Mitigation ;ISSU_39;The Commission SHALL create or reference a profile or extension of the OpenID4VCI specification enabling a PID Provider, Attestation Provider, or Wallet Provider to indicate in their OpenID4VCI Issuer metadata which of the methods A, B, C, or D the Wallet Unit must use for the PID, attestation, or WUA issued. Indicated methods SHALL be ordered by preference. This profile or extension SHALL also enable the PID Provider, Attestation Provider, or Wallet Provider to set the value of parameters to be used by the Wallet Unit for each method (if applicable).;For example, the parameters to be set for method A include the lower limit for unused attestations and the batch size to be requested.
AS-AP-10-061;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;D - HLRs for Privacy Risks and Mitigation ;ISSU_40;PID Providers, Attestation Providers, and Wallet Providers SHALL indicate in their OpenID4VCI Issuer metadata at least that either method A or method B must be used for a given type of PID, attestation, or WUA. PID Providers, Attestation Providers, and Wallet Providers MAY additionally indicate that it prefers using method C and/or method D over method A or method B. In such a case, a Wallet Unit supporting method C and/or method D SHALL use that method, while a Wallet Unit not supporting these methods SHALL use method A or method B, as applicable. *Example: An Attestation Provider indicates methods {D, C, A} in their metadata, in that order. A Wallet Unit that supports methods C and D (as well as A and B) then uses method D for this type of attestation. A Wallet Unit supporting methods A, B and C uses method C. A Wallet Unit supporting only methods A and B uses method A.*;
AS-AP-10-062;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;D - HLRs for Privacy Risks and Mitigation ;ISSU_41;To the maximum extent possible, Wallet Providers, PID Providers, and Attestation Providers SHALL ensure that Users do not notice which of the methods A, B, C, or D is used for their PIDs, attestations, or WUAs.;
AS-AP-10-063;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;D - HLRs for Privacy Risks and Mitigation ;ISSU_42;To the maximum extent possible, Wallet Providers, PID Providers, and Attestation Providers SHALL ensure that no User action is needed for the re-issuance of WUAs, PIDs, or attestations.;For the topic of re-issuance, see also the [Discussion Paper for Topic B](../../discussion-topics/b-re-issuance-and-batch-issuance-of-pids-and-attestations.md).
AS-AP-10-064;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;Method A: Once-only attestations;ISSU_43;The Wallet Unit SHALL request the PID Provider, Attestation Provider, or Wallet Provider to issue PIDs, attestations, or WUAs in batches to the Wallet Unit. All PIDs, attestations, or WUAs in a batch SHALL have the same attribute values and the same technical validity period.;
AS-AP-10-065;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;Method A: Once-only attestations;ISSU_44;The Wallet Unit SHALL present each PID, attestation, or WUA only once to a Relying Party, except when it has fallen back to Method B as specified below, or to another available method.;
AS-AP-10-066;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;Method A: Once-only attestations;ISSU_45;The Wallet Unit SHALL have a lower limit for the number of unused PIDs, attestations, or WUAs it holds, and SHALL request the issuance of a new batch when this limit is reached. During the first issuance of a new PID, attestation, or WUA, see requirement ISSU_39, the PID Provider, Attestation Provider or Wallet Provider SHALL inform the Wallet Unit about the value of the lower limit and the size of the batch to be requested.;
AS-AP-10-067;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;Method A: Once-only attestations;ISSU_46;If the Wallet Unit must request a new batch of PIDs, attestations, or WUAs, but is not able to do so because it is offline, the Wallet Unit SHALL warn the User that they are about to lose the possibility to present this PID or attestation to a Relying Party (or request (re-)issuance of a PID or attestation, in case of the WUA) and request them to connect their device to the internet.;
AS-AP-10-068;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;Method A: Once-only attestations;ISSU_47;If the Wallet Unit has run out of unused PIDs, attestations, or WUAs, but is not able to request a new batch because it is offline, it SHALL fall back to method B (see requirement 6), or another available method. This means that, when requested by a Relying Party or Attestation Provider, the Wallet Unit SHALL again present one of the already used PIDs, attestations or WUAs. The Wallet Unit SHALL return to using method A as soon as it is able to go online and request a new batch of PIDs, attestations, or WUAs.;
AS-AP-10-069;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;Method B: Limited-time attestations;ISSU_48;The Wallet Unit SHALL request the PID Provider, Attestation Provider, or Wallet Provider to issue a single PID, attestation, or WUA to the Wallet Unit.;
AS-AP-10-070;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;Method B: Limited-time attestations;ISSU_49;The Wallet Unit SHALL present that PID, attestation, or WUA multiple times to the same Relying Party or Attestation Provider, or to different Relying Parties or Attestation Providers, when requested to do so.;
AS-AP-10-071;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;Method B: Limited-time attestations;ISSU_50;The Wallet Unit SHALL request the PID Provider, Attestation Provider, or Wallet Provider to re-issue a PID, attestation, or WUA some time before the one existing in the Wallet Unit expires. The PID Provider, Attestation Provider, or Wallet Provider SHALL inform the Wallet Unit about the moment at which the Wallet Unit must request the re-issuance of a PID, attestation, or WUA, relative to the expiration date of the existing one.;It is the responsibility of the Relying Party receiving a PID or attestation (or the Attestation Provider receiving a WUA) to validate whether a presented PID, attestation, or WUA is temporally valid. A Wallet Unit is allowed to present a PID, attestation, or WUA even if its expiration date is in the past.
AS-AP-10-072;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;Method C: Rotating-batch attestations;ISSU_51;The Wallet Unit SHALL request the PID Provider, Attestation Provider, or Wallet Provider to issue PIDs, attestations, or WUAs in batches to the Wallet Unit. All PIDs, attestations, or WUAs in a batch SHALL have the same attribute values and the same technical validity period.;
AS-AP-10-073;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;Method C: Rotating-batch attestations;ISSU_52;When a presentation of attributes is requested by multiple Relying Parties, the Wallet Unit SHALL present each PID or attestation in a batch once, in a random order. Similarly, when a WUA is requested by multiple Attestation Providers, the Wallet Unit SHALL present each WUA in a batch once, in a random order.;
AS-AP-10-074;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;Method C: Rotating-batch attestations;ISSU_53;When all PIDs, attestations, or WUAs in a batch have been presented once, the Wallet Unit SHALL reset the batch, and start presenting each PID, attestation, or WUA in the batch again in a random order.;
AS-AP-10-075;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;Method C: Rotating-batch attestations;ISSU_54;The Wallet Unit SHALL request the PID Provider, Attestation Provider, or Wallet Provider to re-issue a batch of PIDs, attestations, or WUAs, some time before the batch in the Wallet Unit expires. The PID Provider, Attestation Provider, or Wallet Provider SHALL inform the Wallet Unit about the size of the batch and about the moment at which the Wallet Unit must request the re-issuance of a batch, relative to the expiration date of the existing one.;
AS-AP-10-076;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;Method D: Per-Relying Party attestations;ISSU_55;The Wallet Unit SHALL present a different PID, attestation, or WUA to each different Relying Party or Attestation Provider upon their request. This means that it SHALL comply with Method A for such Relying Parties or Attestation Providers.;
AS-AP-10-077;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;Method D: Per-Relying Party attestations;ISSU_56;In case a given Relying Party requests attributes from a given type of PID or attestation multiple times, the Wallet Unit MAY present the same PID or attestation to this Relying Party each time. If it does, it SHALL comply with Method B or Method C for such a Relying Party.;
AS-AP-10-078;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;Method D: Per-Relying Party attestations;ISSU_56a;In case a given Attestation Provider requests a WUA multiple times, the Wallet Unit MAY present the same WUA to this Attestation Provider each time. If it does, it SHALL comply with Method B or Method C for such an Attestation Provider.;
AS-AP-10-079;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;Method D: Per-Relying Party attestations;ISSU_57;The Wallet Unit SHALL keep track of which PID or attestation it has presented to which Relying Party.;To do so, the Wallet Unit can use the unique RP identifier from the extension of the presentation request meant in RPRC_19a.
AS-AP-10-080;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;Method D: Per-Relying Party attestations;ISSU_57a;The Wallet Unit SHALL keep track of which WUA it has presented to which Attestation Provider, using the unique identifier obtained from the respective access certificate.;
AS-AP-10-081;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;E - HLRs for re-issuance and batch issuance of PIDs, attestations and WUAs;ISSU_58;A Wallet Unit SHALL give its User the option to manually initiate a re-issuance process for any of the PIDs or attestations in their Wallet Unit.;This requirement does not apply for WUAs, since Users must not be involved in the management of WUAs.
AS-AP-10-082;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;E - HLRs for re-issuance and batch issuance of PIDs, attestations and WUAs;ISSU_59;After a successful re-issuance, a Wallet Unit SHALL compare the attribute values of the re-issued PID or attestation with those of the existing PID or attestation, and SHALL notify the User in case of any differences.;This requirement does not apply for WUAs, since Users must not be involved in the management of WUAs.
AS-AP-10-083;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;E - HLRs for re-issuance and batch issuance of PIDs, attestations and WUAs;ISSU_60;A Wallet Unit SHALL gracefully handle situations in which re-issuance of a PID, attestation, or WUA is refused by the PID Provider, Attestation Provider, or Wallet Provider,for example by attempting a retry after an appropriate delay.;
AS-AP-10-084;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;E - HLRs for re-issuance and batch issuance of PIDs, attestations and WUAs;ISSU_61;A Wallet Unit SHALL support PID or attestation first-time batch issuance with a single User authentication, regardless of the size of the batch.;a) See also requirement WIAM_14. b) This requirement does not apply for WUAs, since Users must not be involved in the management of WUAs.
AS-AP-10-085;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;E - HLRs for re-issuance and batch issuance of PIDs, attestations and WUAs;ISSU_62;If a PID, attestation, or WUA was successfully re-issued because the value of one or more of its attributes was changed (including attributes being added or deleted), a Wallet Unit SHOULD delete the correct pre-existing PID, attestation, or WUA.;a) It is up to the Wallet Unit, possibly using metadata provided by the PID Provider, Attestation Provider, or Wallet Provider using the [OpenID4VCI] protocol, to determine the PID, attestation, or WUA to be deleted. b) Additionally, per requirement VCR_09, the PID Provider, Attestation Provider, or Wallet Provider revokes the pre-existing PID, attestation, or WUA.
AS-AP-10-086;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;E - HLRs for re-issuance and batch issuance of PIDs, attestations and WUAs;ISSU_63;PID Providers, Attestation Providers, Wallet Providers, and Wallet Units SHALL support the features of [OpenID4VCI] enabling the re-issuance of PIDs, attestations, and WUAs.;
AS-AP-10-087;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;E - HLRs for re-issuance and batch issuance of PIDs, attestations and WUAs;ISSU_64;PID Providers, Attestation Providers, Wallet Providers, and Wallet Units SHALL support the features of [OpenID4VCI] enabling the batch issuance of PIDs, attestations, and WUAs.;
AS-AP-10-088;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;E - HLRs for re-issuance and batch issuance of PIDs, attestations and WUAs;ISSU_65;The common OpenID4VCI protocol referenced in requirement ISSU_01, or an EUDI Wallet-specific extension or profile thereof, SHALL enable a PID Provider, Attestation Provider or Wallet Provider to verify that a re-issued PID, device-bound attestation, or WUA is bound to the same WSCA/WSCD or keystore to which the existing PID, device-bound attestation, or WUA is bound.;This can be done, for instance, by requiring that OAuth 2.0 Demonstrating Proof of Possession (DPoP) [RFC 9449] is used for each Refresh Token, and that the private key of the Refresh Token and the private key of the existing PID, attestation, or WUA are stored in the same WSCA/WSCD or keystore.
AS-AP-10-089;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;E - HLRs for re-issuance and batch issuance of PIDs, attestations and WUAs;ISSU_66;The common OpenID4VCI protocol referenced in requirement ISSU_01, or an EUDI Wallet-specific extension or profile thereof, SHALL enable an Attestation Provider to verify that the Refresh Token used for the re-issuance of a non device-bound attestation is bound to a WSCA/WSCD or keystore included with the Wallet Unit in which the replaced attestation is stored.;a) This requirement implies that if an Attestation Provider enables re-issuance of an attestation by issuing Refresh Tokens, these tokens must be device-bound, even in case the attestation itself is not device-bound. b) This requirement does not apply to PIDs and WUAs, since these are bound to the WSCA/WSCD because they must be issued and managed at Level of Assurance High.
AS-WP-11-001;Actor-Specific Requirements;Wallet Providers;Topic 11 - Pseudonyms;11;Pseudonyms;A. HLRs related to Use Cases;PA_01;A Wallet Unit SHALL enable a User to generate a Pseudonym and register it at a Relying Party.;
AS-WP-11-002;Actor-Specific Requirements;Wallet Providers;Topic 11 - Pseudonyms;11;Pseudonyms;A. HLRs related to Use Cases;PA_02;A Wallet Unit SHALL enable a User to authenticate with a Pseudonym towards a Relying Party if the Wallet Unit was used previously to register the Pseudonym for the same Relying Party;
AS-WP-11-003;Actor-Specific Requirements;Wallet Providers;Topic 11 - Pseudonyms;11;Pseudonyms;A. HLRs related to Use Cases;PA_03;A Wallet Unit SHALL be able to perform the actions specified in the above two requirements independently of whether the interaction with the Relying Party is initiated on the same device hosting the Wallet Instance or on a device different from the one hosting the Wallet Instance.;
AS-WP-11-004;Actor-Specific Requirements;Wallet Providers;Topic 11 - Pseudonyms;11;Pseudonyms;A. HLRs related to Use Cases;PA_04;A Wallet Unit SHALL enable the User to use multiple different Pseudonyms at a given Relying Party.;
AS-WP-11-005;Actor-Specific Requirements;Wallet Providers;Topic 11 - Pseudonyms;11;Pseudonyms;A. HLRs related to Use Cases;PA_05;A Wallet Unit SHOULD enable a User to freely choose a User alias for each Pseudonym registered at a Relying Party. Setting an alias SHOULD be optional for the User. The User SHOULD be able to change the alias for any Pseudonym. ;
AS-WP-11-006;Actor-Specific Requirements;Wallet Providers;Topic 11 - Pseudonyms;11;Pseudonyms;A. HLRs related to Use Cases;PA_06;A Wallet Unit SHALL enable a User to choose which Pseudonym to authenticate with towards a Relying Party, if multiple Pseudonyms are registered for this Relying Party. The Wallet Unit SHOULD present the User with the aliases of the applicable Pseudonyms, if assigned, when making this choice.;
AS-WP-11-007;Actor-Specific Requirements;Wallet Providers;Topic 11 - Pseudonyms;11;Pseudonyms;A. HLRs related to Use Cases;PA_07;A Wallet Unit SHALL enable a User to delete a Pseudonym.;
AS-WP-11-008;Actor-Specific Requirements;Wallet Providers;Topic 11 - Pseudonyms;11;Pseudonyms;A. HLRs related to Use Cases;PA_08;A Wallet Unit SHALL enable the User to manage Pseudonyms within the Wallet Unit in a user-friendly and transparent manner.;
AS-WP-11-009;Actor-Specific Requirements;Wallet Providers;Topic 11 - Pseudonyms;11;Pseudonyms;A. HLRs related to Use Cases;PA_08a;A Wallet Unit SHALL log Pseudonym registration and presentation transactions as specified in [Topic 19](./annex-2.02-high-level-requirements-by-topic.md#a2312-topic-19---user-navigation-requirements-dashboard-logs-for-transparency).;
AS-WP-11-010;Actor-Specific Requirements;Wallet Providers;Topic 11 - Pseudonyms;11;Pseudonyms;A. HLRs related to Use Cases;PA_09;A Wallet Unit SHALL enable the User to see all existing pseudonyms, including the associated Relying Party.;
AS-WP-11-011;Actor-Specific Requirements;Wallet Providers;Topic 11 - Pseudonyms;11;Pseudonyms;B. HLRs related to Relying Parties;PA_10;A Relying Party SHALL be able to verify that a User is registering a Pseudonym using a non-revoked Wallet Unit.;
AS-WP-11-012;Actor-Specific Requirements;Wallet Providers;Topic 11 - Pseudonyms;11;Pseudonyms;B. HLRs related to Relying Parties;PA_11;A Relying Party SHALL be able to verify that a User is authenticating with a Pseudonym using a non-revoked Wallet Unit.;
AS-WP-11-013;Actor-Specific Requirements;Wallet Providers;Topic 11 - Pseudonyms;11;Pseudonyms;B. HLRs related to Relying Parties;PA_12;If Wallet Unit is used to register a Pseudonym at a Relying Party in combination with a PID, attestation or WUA being presented to the same Relying Party, then this Relying Party SHALL be able to verify that the same User performed both actions.;
AS-WP-11-014;Actor-Specific Requirements;Wallet Providers;Topic 11 - Pseudonyms;11;Pseudonyms;B. HLRs related to Relying Parties;PA_13;The Relying Party SHALL be able to validate that the pseudonym presented to them belongs to the User presenting it.;
AS-WP-11-015;Actor-Specific Requirements;Wallet Providers;Topic 11 - Pseudonyms;11;Pseudonyms;C. HLRs related to privacy;PA_14;A Wallet Unit SHALL store the information necessary for authenticating with a Pseudonym in a keystore.;
AS-WP-11-016;Actor-Specific Requirements;Wallet Providers;Topic 11 - Pseudonyms;11;Pseudonyms;C. HLRs related to privacy;PA_15;A Relying Party SHALL NOT be able to derive the User's true identity, or any data identifying the User, from the Pseudonym value received by the Relying Party;
AS-WP-11-017;Actor-Specific Requirements;Wallet Providers;Topic 11 - Pseudonyms;11;Pseudonyms;C. HLRs related to privacy;PA_16;A Wallet Unit SHALL NOT reveal the same Pseudonym to different Relying Parties unless the User explicitly chooses otherwise.;
AS-WP-11-018;Actor-Specific Requirements;Wallet Providers;Topic 11 - Pseudonyms;11;Pseudonyms;C. HLRs related to privacy;PA_17;It SHALL NOT be possible to correlate Pseudonyms based on their values nor on other metadata sent by the Wallet Unit during registration and authentication, meaning that colluding Relying Parties SHALL NOT able to conclude that different Pseudonyms belong to the same User.;
AS-WP-11-019;Actor-Specific Requirements;Wallet Providers;Topic 11 - Pseudonyms;11;Pseudonyms;C. HLRs related to privacy;PA_18;The Wallet Unit SHALL ensure that Pseudonyms contain sufficient entropy to make the chance of colliding Pseudonyms (meaning two Users having the same Pseudonym value for the same Relying Party) negligible.;
AS-WP-11-020;Actor-Specific Requirements;Wallet Providers;Topic 11 - Pseudonyms;11;Pseudonyms;C. HLRs related to privacy;PA_19;A Wallet Unit SHALL NOT share the User's optionally assigned Pseudonym aliases with any Relying Party.;
AS-WP-11-021;Actor-Specific Requirements;Wallet Providers;Topic 11 - Pseudonyms;11;Pseudonyms;C. HLRs related to privacy;PA_20;The Wallet Unit SHALL verify the identity of a Relying Party when a User registers a Pseudonym or authenticates with a Pseudonym, provided the profile or extension of [W3C WebAuthn] meant in PA_21 enables the Wallet Unit to do this. In case the profile or extension does not enable this, the Wallet Unit SHALL trust the WebAuthn Client (i.e., the browser) to verify the Relying Party identity.;[W3C WebAuthn] currently does not offer a way for an Authenticator (i.e., the Wallet Unit) to authenticate a Relying Party. Instead, the Client (i.e., the browser) will authenticate the Relying Party, using TLS.
AS-WP-11-022;Actor-Specific Requirements;Wallet Providers;Topic 11 - Pseudonyms;11;Pseudonyms;D. HLRs related to interoperability;PA_21;The Commission SHALL create or reference a technical specification containing a profile or extension of the [W3C WebAuthn] specification compliant with the HLRs specified in this Topic. This specification SHALL contain all details necessary for Wallet Units and Relying Parties to generate, register, and use Pseudonyms.;
AS-WP-11-023;Actor-Specific Requirements;Wallet Providers;Topic 11 - Pseudonyms;11;Pseudonyms;D. HLRs related to interoperability;PA_22;Wallet Providers SHALL ensure that their Wallet Solution supports the [W3C WebAuthn] specification and the technical specification meant in requirement PA_21.;
AS-AP-12-001;Actor-Specific Requirements;Attestation & PID Providers;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;A. Requirements regarding attestation formats;ARB_01;The Scheme Provider for an Attestation Rulebook describing a type of attestation that is a QEAA or a PuB-EAA SHALL specify that one or more of the following two common format(s) must be used for these attestations: - The format specified in ISO/IEC 18013-5, see [ISO18013-5]. - The format specified in SD-JWT-based Verifiable Credentials (SD-JWT VC), see [SD-JWT-VC].;
EW-DM-12-001;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;A. Requirements regarding attestation formats;ARB_01a;The Scheme Provider for an Attestation Rulebook describing a type of attestation that is a non-qualified EAA SHALL specify that one or more of the following three common format(s) must be used for these attestations: - The format specified in ISO/IEC 18013-5, see [ISO18013-5]. - The format specified in SD-JWT-based Verifiable Credentials (SD-JWT VC), see [SD-JWT-VC]. - The format specified in W3C Verifiable Credentials Data Model, see [W3C VCDM v2.0].;
EW-DM-12-002;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;A. Requirements regarding attestation formats;ARB_01b;The Scheme Provider for an Attestation Rulebook describing attestations using the format specified in [SD-JWT VC] SHALL ensure that these attestations comply with the 'SD-JWT VCs' profile specified in [HAIP].;
EW-DM-12-003;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;A. Requirements regarding attestation formats;ARB_02;The Scheme Provider for an Attestation Rulebook SHALL analyse whether it must be possible for a User to present that type of attestation when the Wallet Unit and the Relying Party are in proximity and attestations are presented without using the internet. If so, the Attestation Rulebook SHALL specify that the attestations must be issued in the ISO/IEC 18013-5-compliant mdoc format.;In theory, it is possible to use SD-JWT VC-compliant attestations in proximity use cases. In practice, however, the only protocol available to request and release SD-JWT VC-compliant attestations between a Wallet Unit and a Relying Party Instance is OpenID4VP. That protocol cannot be used without internet connectivity.
EW-DM-12-004;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;A. Requirements regarding attestation formats;ARB_03;The Scheme Provider for an Attestation Rulebook MAY specify in the Attestation Rulebook that that type of attestation must be issued in the [SD-JWT VC]-compliant format, provided the [SD-JWT VC] specification has been approved by an EU standardisation body or by the European Digital Identity Cooperation Group established pursuant to [Article 46e](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e4536-1-1)(1) of the [European Digital Identity Regulation].;
EW-DM-12-005;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;A. Requirements regarding attestation formats;ARB_04;If an Attestation Rulebook specifies that a type of attestation can be issued in a format compliant with [W3C VCDM v2.0], the Scheme Provider for that Attestation Rulebook SHALL ensure the Rulebook references one or more documents specifying in detail how a Relying Party can request attributes from a such an attestation, and how a User can selectively disclose attributes from such an attestation. Moreover, these referenced documents SHALL be approved by an EU standardisation body or by the European Digital Identity Cooperation Group established pursuant to [Article 46e](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e4536-1-1)(1) of the [European Digital Identity Regulation].;
EW-DM-12-006;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;B. Requirements regarding attestation types;ARB_05;The Scheme Provider for an Attestation Rulebook SHALL specify a value for the attestation type, which SHALL be unique within the scope of the EUDI Wallet ecosystem.;In ISO/IEC 18013-5, the attestation type is called 'document type' and is included as a docType key-value pair in both the mdoc request and the mdoc response. Also, a method for generating unique attestation type values is recommended. In OpenID4VP, the attestation type is included in the meta property of a Credential Query in a presentation request. In [SD-JWT VC], the attestation type is called 'SD-JWT VC type' and is included as a 'vct' claim in the SD-JWT VC.
EW-DM-12-007;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;C. Requirements regarding attestation schemes;ARB_06;The Scheme Provider for an Attestation Rulebook SHALL define all attributes that an attestation of that type may contain. This definition SHALL first describe the semantics of each attribute in an encoding-independent manner and SHALL subsequently for each attribute specify an ISO/IEC 18013-5-compliant format, an SD-JWT VC-compliant format, or both, as needed given the choices made according to ARB_01 - ARB_04.;
EW-DM-12-008;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;C. Requirements regarding attestation schemes;ARB_06a;For ISO/IEC 18013-5-compliant attestations, the Attestation Rulebook SHALL define each attribute within an attribute namespace. An attribute namespace SHALL fully define the identifier, the syntax, and the semantics of each attribute within that namespace. An attribute namespace SHALL have an identifier that is unique within the scope of the EUDI Wallet ecosystem, and each attribute identifier SHALL be unique within that namespace.;In ISO/IEC 18013-5, namespaces are discussed and a method for generating unique namespace identifiers is recommended.
EW-DM-12-009;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;C. Requirements regarding attestation schemes;ARB_06b;For [SD-JWT VC]-compliant attestations, the Scheme Provider for the Attestation Rulebook SHALL ensure that each claim name is either: - included in the IANA registry for JWT claims, - is a Public Name as defined in [RFC 7519], or is a Private Name specific to the attestation type.;[SD-JWT VC] does not discuss how to avoid conflicting claim names. Since SD-JWTs are a special kind of JWTs, the methods specified in RFC 7519 are applicable.
EW-DM-12-010;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;C. Requirements regarding attestation schemes;ARB_07; When determining the attributes to be included in a new attestation type, the Scheme Provider for the applicable Attestation Rulebook SHOULD consider referring to attributes that are already included in the catalogue of attributes specified in [Topic 25](./annex-2.02-high-level-requirements-by-topic.md#a2315-topic-25---unified-definition-and-controlled-vocabularies-for-attributes) or specified in an attestation scheme included in the catalogue of attestation schemes specified in [Commission Implementing Regulation 2025/1569](http://data.europa.eu/eli/reg_impl/2025/1569/oj), rather than unnecessarily re-defining all attributes.;
EW-DM-12-011;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;C. Requirements regarding attestation schemes;ARB_08;The Scheme Provider for an Attestation Rulebook SHOULD, when specifying a new attribute, take into consideration existing conventions for attribute identifier values and attribute syntaxes.;These conventions may depend on the format of the attestation, i.e., CBOR for ISO/IEC 18013-5-compliant attestations or JSON for SD-JWT VC-compliant attestations.
EW-DM-12-012;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;C. Requirements regarding attestation schemes;ARB_09;The Scheme Provider for an Attestation Rulebook SHALL specify, for each attribute in the attestation, whether the presence of that attribute is mandatory, optional, or conditional.;
EW-DM-12-013;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;C. Requirements regarding attestation schemes;ARB_10;The Scheme Provider for an Attestation Rulebook for an ISO/IEC 18013-5 compliant attestation MAY define a domestic namespace to specify attributes that are specific to that Rulebook and are not included in the applicable EU-wide or sectoral namespace. All requirements for namespaces in this Topic SHALL also apply for domestic namespaces.;
EW-DM-12-014;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;C. Requirements regarding attestation schemes;ARB_11;The Scheme Provider for an Attestation Rulebook describing a type of attestation that is a QEAA or a PuB-EAA SHALL include in the Rulebook an attribute as meant in [Annex V](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e40-54-1) point a) and [Annex VII](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e40-56-1) point a) of the [European Digital Identity Regulation]. This attribute SHALL reference the technical specification meant in ARB_25.;
EW-DM-12-015;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;C. Requirements regarding attestation schemes;ARB_12;The Scheme Provider for an Attestation Rulebook describing a type of attestation that is a non-qualified EAA SHOULD include an attribute in the Rulebook indicating that the attestation is an EAA. This attribute SHALL reference the technical specification meant in ARB_25.;
EW-DM-12-016;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;C. Requirements regarding attestation schemes;ARB_13;The Scheme Provider for an Attestation Rulebook describing a type of attestation that is a QEAA SHALL include in the Rulebook one or more attributes or metadata representing the set of data meant in [Annex V](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e40-54-1) point b) of the [European Digital Identity Regulation].;
EW-DM-12-017;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;C. Requirements regarding attestation schemes;ARB_14;The Scheme Provider for an attestation Rulebook describing a type of attestation that is a PuB-EAA SHALL include in the Rulebook one or more attributes or metadata representing the set of data meant in [Annex VII](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e40-56-1) point b) of the [European Digital Identity Regulation].;
EW-DM-12-018;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;C. Requirements regarding attestation schemes;ARB_15;The Scheme Provider for an Attestation Rulebook describing a type of attestation that is a non-qualified EAA SHOULD include in the Rulebook one or more attributes or metadata representing the set of data meant in [Annex V](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e40-54-1) point b) of the [European Digital Identity Regulation].;
EW-DM-12-019;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;C. Requirements regarding attestation schemes;ARB_16;The Scheme Provider for an Attestation Rulebook describing a type of attestation that is a QEAA or a PuB-EAA SHALL include in the Rulebook one or more attributes representing the set of data meant in [Annex V](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e40-54-1) point c) or [Annex VII](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e46-55-1) point c) of the [European Digital Identity Regulation].;
EW-DM-12-020;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;C. Requirements regarding attestation schemes;ARB_17;The Scheme Provider for an Attestation Rulebook describing a type of attestation that is a non-qualified EAA SHOULD include in the Rulebook one or more attributes representing the set of data meant in [Annex V](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e40-54-1) point c) of the [European Digital Identity Regulation].;
EW-DM-12-021;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;C. Requirements regarding attestation schemes;ARB_18;The Scheme Provider for an Attestation Rulebook describing a type of attestation that is a QEAA or a PuB-EAA SHALL include in the Rulebook one or more attributes or metadata representing the set of data meant in [Annex V](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e40-54-1) point e) or [Annex VII](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e40-56-1) point e) of the [European Digital Identity Regulation].;
EW-DM-12-022;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;C. Requirements regarding attestation schemes;ARB_19;The Scheme Provider for an Attestation Rulebook describing a type of attestation that is a non-qualified EAA SHOULD include in the Rulebook one or more attributes representing the set of data meant in [Annex V](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e40-54-1) point e) of the [European Digital Identity Regulation].;
EW-DM-12-023;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;C. Requirements regarding attestation schemes;ARB_20;The Scheme Provider for an Attestation Rulebook describing a type of attestation that is a QEAA or a PuB-EAA SHALL include in the Rulebook one or more attributes or metadata representing the location meant in [Annex V](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e40-54-1) point h) or [Annex VII](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e40-56-1) point h) of the [European Digital Identity Regulation]. For a QEAA, this location SHALL indicate at least the URL at which a machine-readable version of the trust anchor to be used for verifying the QEAA can be found or looked up. For a PuB-EAA, this location SHALL indicate at least the URL at which a machine-readable version of the qualified certificate that signed the PuB-EAA can be found or looked up.;
EW-DM-12-024;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;C. Requirements regarding attestation schemes;ARB_21;The Scheme Provider for an Attestation Rulebook describing a type of attestation that is a non-qualified EAA SHOULD include in the Rulebook one or more attributes or metadata representing the location at which a machine-readable version of the trust anchor to be used for verifying the EAA can be found or looked up.;What this location indicates precisely is dependent on the nature of the mechanism used for distributing trust anchors; see requirement ARB_26.
EW-DM-12-025;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;D. Miscellaneous requirements;ARB_22;The Scheme Provider for an Attestation Rulebook SHALL specify all technical details necessary to ensure interoperability, security, and privacy of that attestation.;An Attestation Rulebook may also specify requirements regarding how the Wallet Unit must display the attestation and the attributes in it to the User.
EW-DM-12-026;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;D. Miscellaneous requirements;ARB_23;The Scheme Provider for an Attestation Rulebook describing a type of attestation that is a QEAA or a PuB-EAA SHALL specify which of the revocation mechanisms specified in [Topic 7](./annex-2.02-high-level-requirements-by-topic.md#a235-topic-7---attestation-revocation-and-revocation-checking) SHALL be supported by that attestation.;
EW-DM-12-027;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;D. Miscellaneous requirements;ARB_24;The Scheme Provider for an Attestation Rulebook describing a type of attestation that is a non-qualified EAA SHALL specify whether that type of EAA must be revocable. If an EAA type must be revocable, the relevant Rulebook SHALL determine which of the revocation mechanisms specified in [Topic 7](./annex-2.02-high-level-requirements-by-topic.md#a235-topic-7---attestation-revocation-and-revocation-checking) SHALL be supported by that attestation.;
EW-DM-12-028;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;D. Miscellaneous requirements;ARB_25;The Commission SHALL take measures to ensure that the following information is included in a technical specification: - The identifier of the attribute containing the indication meant in [Annex V](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e40-54-1) point a) and [Annex VII](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e40-56-1) point a). - The syntax and semantics of this attribute in case the attestation is a QEAA, in case it is PuB-EAA, and in case it is a non-qualified EAA.;
EW-DM-12-029;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;D. Miscellaneous requirements;ARB_26;The Scheme Provider for an Attestation Rulebook describing a type of attestation that is a non-qualified EAA SHOULD define in the Rulebook: - mechanisms allowing a Wallet Unit to verify that the EAA Provider is authorised or registered to issue this type of EAA. - mechanisms allowing a Relying Party to obtain, in a trustworthy manner, the trust anchor(s) of the EAA Providers issuing this type of EAA.;
EW-DM-12-030;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;D. Miscellaneous requirements;ARB_27;The Scheme Provider for an Attestation Rulebook describing a type of attestation that is a QEAA, PuB-EAA, or non-qualified EAA SHOULD specify in the Rulebook whether a Relying Party receiving the attestation must request and verify a PID and verify the cryptographic binding between the PID and the attestation.;Relying Parties can only do so in a trustworthy manner if Wallet Units are able to provide a proof of cryptographic binding showing that the private keys of the attestation and the PID are stored in the same WSCA/WSCD, in accordance with the requirements in [Topic 18](./annex-2.02-high-level-requirements-by-topic.md#a2311-topic-18---combined-presentations-of-attributes).
EW-DM-12-031;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;D. Miscellaneous requirements;ARB_28;An Attribute Scheme Provider SHOULD specify an attribute in an Attestation Rulebook that indicates whether the Attestation Provider during attestation issuance requested a cryptographic binding (as specified in [Topic 18](./annex-2.02-high-level-requirements-by-topic.md#a2311-topic-18---combined-presentations-of-attributes)) between the new attestation and an existing PID or attestation. If present in a Rulebook, the identifier for this attribute SHALL be cryptographically_bound_to, and its contents SHALL be an attestation type or vct (see ARB_05).;The meaning of this attribute, if present, is This attestation is cryptographically bound to one or more attestations of the given attestation type or vct on this Wallet Unit. If a Relying Party receives this attribute from a Wallet Unit, it can subsequently request the Wallet Unit to send a proof of cryptographic binding between the attestation and an attestation indicated in the cryptographically_bound_to attribute.
EW-DM-12-032;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;D. Miscellaneous requirements;ARB_29;The Scheme Provider for an Attestation Rulebook describing a type of attestation that is a QEAA, PuB-EAA, or non-qualified EAA SHOULD ensure that the structure and contents of the Attestation Rulebook follow the descriptions in the [Attestation Rulebook template](https://github.com/eu-digital-identity-wallet/eudi-doc-attestation-rulebooks-catalog/blob/main/template/attestation-rulebook-template.md).;
EW-DM-12-033;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;D. Miscellaneous requirements;ARB_30;If an Attestation Rulebook specifies a [SD-JWT VC]-compliant attestation, the Scheme Provider for that Attestation Rulebook SHALL specify for all claims (i.e., all top-level properties, all nested properties, and all array entries) whether an Attestation Provider MUST, MAY, or MUST NOT make that claim selectively disclosable.;a) This requirement does not apply to claims defined as non-selectively disclosable in [SD-JWT VC]. b) There will be use cases where a specific claim must not be disclosed without simultaneously disclosing one or more other claims. Such cases should be solved by making all of these claims members of the same JSON object (or elements of the same JSON array). That JSON object (or array) is then the claim that must be selectively disclosable, while the nested properties (or individual array elements) must not be selectively disclosable.  c) This requirement does not apply to [ISO/IEC 18013-5]-compliant attestations, since in such attestations, by definition all data elements are selectively disclosable, while none of the key-value pairs or array elements inside a data element (if any) are selectively disclosable.
EW-DM-12-034;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;D. Miscellaneous requirements;ARB_31;If an Attestation Rulebook specifies a [SD-JWT VC]-compliant attestation, the Scheme Provider for that Attestation Rulebook SHOULD consider defining a Type Metadata Document for it, as defined in Chapter 6 of [SD-JWT VC]. If the Scheme Provider defines such a document, it SHOULD contain the Claim Selective Disclosure Metadata (defined in Section 9.3 of [SD-JWT VC]) for each of the claims, in order to specify if that claim is selectively disclosable (see requirement ARB_30).;Although a Type Metadata Document is a highly technical document, defining it has a number of advantages for developers, Attestation Providers, Relying Parties,. and Wallet Units, as spelled out in Chapter 6 of [SD-JWT VC].
EW-DM-12-035;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;D. Miscellaneous requirements;ARB_32;If an Attestation Rulebook specifies a [SD-JWT VC]-compliant attestation, the Scheme Provider for that Attestation Rulebook SHOULD consider defining a JSON Schema for it, as defined in Section 6.5 of [SD-JWT VC], and include or reference that Schema in the Type Metadata Document meant in ARB_31.;Requirements for validation of a Schema (if present) by Wallet Units or Relying Party are specified in Section 6.5.2 of [SD-JWT VC].
EW-DM-12-036;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;D. Miscellaneous requirements;ARB_33;If a Scheme Provider for an Attestation Rulebook registers an attestation scheme in the catalogue of attestation schemes meant in [Commission Implementing Regulation 2025/1569](http://data.europa.eu/eli/reg_impl/2025/1569/oj), Article 8, the registration SHALL include a reference to the corresponding Attestation Rulebook.;By definition, an attestation scheme is machine-readable, whereas an Attestation Rulebook is human-readable.
EW-DM-12-036;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 12 - Attestation Rulebooks;12;Attestation Rulebooks;D. Miscellaneous requirements;ARB_34;The Scheme Provider for an Attestation Rulebook SHALL specify whether that attestation is device-bound or not.;
AS-WP-16-001;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;A. Requirement for Wallet Providers;QES_01;Wallet Providers SHALL ensure that each User has the possibility to receive a qualified certificate for Qualified Electronic Signatures, bound to a QSCD, that is either local, external, or remotely managed in relation to the Wallet Instance.;
AS-WP-16-002;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;A. Requirement for Wallet Providers;QES_02;Wallet Providers SHALL ensure that each User who is a natural person has, at least for non-professional purposes, free-of-charge access to a Signature Creation Application which allows the creation of free-of-charge Qualified Electronic Signatures using the certificates referred to in QES_01. Wallet Providers SHALL ensure that: - The Signature Creation Application SHALL, as a minimum, be capable of signing or sealing User-provided data and Relying Party-provided data. - The Signature Creation Application SHALL be implemented as part of a Wallet Solution or external to it (by providers of trust services or by Relying Parties). - The Signature Creation Application SHALL be able to generate signatures or seals in formats compliant with at least the mandatory formats referred to in QES_08.;a) Signature Creation Application (SCA): see definition in the ETSI TS 119 432 standard. 2) If the SCA is external to the Wallet Solution, it may be for example a separate mobile application, or be hosted remotely, for instance by the QTSP or by a Relying Party.
AS-WP-16-003;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;A. Requirement for Wallet Providers;QES_03;For the use of the qualified certificate referred to in QES_01, Wallet Providers SHALL ensure that a Wallet Unit implements secure authentication of the User, as well as signature or seal invocation capabilities, as a part of a local, external or remote QSCD.;
AS-WP-16-004;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;A. Requirement for Wallet Providers;QES_04;Wallet Providers SHALL enable their Wallet Units to interface with QSCDs using protocols and interfaces necessary for the implementation of secure User authentication and signature or seal functionality.;In a Relying Party-centric flow, the remote QTSP will likely be selected by the Relying Party, which implies the QSCD is managed by the remote QTSP. In a Wallet Unit-driven flow, the User should be able to choose the QSCD.
AS-WP-16-005;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;A. Requirement for Wallet Providers;QES_05;Wallet Providers SHALL enable their Wallet Units to be used for User enrolment to a remote QES Provider (i.e., a QTSP offering remote QES), except where the Wallet Unit interfaces with local or external QSCDs.;
AS-WP-16-006;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;A. Requirement for Wallet Providers;QES_06;Wallet Providers SHALL ensure that their Wallet Solution supports at least one of the following options for remote QES signature creation: - remote QES creation through secure authentication to a QTSP signature web portal, - remote QES creation channelled by the Wallet Unit, - remote QES creation channelled by a Relying Party.;
AS-WP-16-007;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;A. Requirement for Wallet Providers;QES_07;Wallet Providers SHALL ensure that, where a Signature Creation Application relies on a remote Qualified Signature Creation Device and where it is integrated into a Wallet Instance, it supports the Cloud Signature Consortium API Specification 2.0 [CSC API].;
AS-WP-16-008;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;A. Requirement for Wallet Providers;QES_08;Wallet Providers SHALL ensure that their Wallet Units are able to create signatures or seals in accordance with the mandatory PAdES format as specified in ETSI EN 319 142-1 V1.1.1 (2016-04). In addition, Wallet Providers SHOULD ensure that their Wallet Units are able to create signatures or seals in accordance with the following formats: - XAdES as specified in ETSI EN 319 132-1 V1.2.1 (2022-02), - JAdES as specified in ETSI TS 119 182-1 V1.2.1 (2024-07), - CAdES as specified in ETSI EN 3191 22-1 V1.3.1 (2023-06), and - ASiC as specified in ETSI EN 319 162-1 V1.1.1 (2016-04) and ETSI EN 319 162-2 V1.1.1 (2016-04).;
AS-WP-16-009;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;A. Requirement for Wallet Providers;QES_09;Empty;
AS-WP-16-010;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;A. Requirement for Wallet Providers;QES_10;Wallet Providers SHALL ensure that, where the Signature Creation Application is implemented as part of the Wallet Unit and is used to generate signatures or seals of the representation of the document or data to be signed or sealed, the Wallet Unit presents the representation of the document or data to be signed or sealed to the User.;
AS-WP-16-011;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;A. Requirement for Wallet Providers;QES_11;Wallet Providers SHALL ensure that, where the Signature Creation Application is implemented as part of the Wallet Unit, a Wallet Unit computes the hash or digest of the document or data to be signed through a Signature Create Application component.;
AS-WP-16-012;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;A. Requirement for Wallet Providers;QES_12;Wallet Providers SHALL ensure that a Wallet Unit is able to create the signature value of the document or data to be signed either using a local or a remote signing application.;a local signing application is on-device. It may either be embedded in the Wallet Unit or be an external application.
AS-WP-16-013;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;A. Requirement for Wallet Providers;QES_13;Wallet Providers SHALL ensure that a Wallet Unit provides a log of transactions related to qualified electronic signatures or seals generated by or through the Wallet Unit, allowing the User to view the history of previously signed data or documents, according to requirement DASH_04 in [Topic 19](./annex-2.02-high-level-requirements-by-topic.md#a2312-topic-19---user-navigation-requirements-dashboard-logs-for-transparency).;If the signature is generated by a remote Signature Creation Application, the Wallet is at minimum used to authenticate the User to the remote QTSP and to obtain the User's consent for the usage of the private signing key. The logs then record information about these processes.
AS-WP-16-014;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;A. Requirement for Wallet Providers;QES_14;Wallet Providers SHALL ensure that the User will be able to explicitly authorise the creation of a qualified electronic signature or seal through their Wallet Unit.;
AS-WP-16-015;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;A. Requirement for Wallet Providers;QES_15;Wallet Providers SHALL ensure that a Wallet Unit can verify, in remote signature creation scenarios, that the qualified electronic signature or seal creation device is part of a qualified service, which is carried out by a qualified trust service provider.;
AS-WP-16-016;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;A. Requirement for Wallet Providers;QES_16;Wallet Providers SHOULD ensure that a Wallet Unit supports multiple-signing scenarios where multiple signatories are required to sign the same document or data.;
AS-WP-16-017;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;A. Requirement for Wallet Providers;QES_17;Wallet Providers SHALL ensure that Wallet Units provide a signature creation confirmation upon the creation of a qualified electronic signature, informing the User about the outcome of the signature creation process.;See also QES_17a.
AS-WP-16-018;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;A. Requirement for Wallet Providers;QES_17a;If the Signature Creation Application is external to the Wallet Unit, after the User authorises the usage of the private signing key, the Signature Creation Application SHALL return the outcome of the signature creation process to the Wallet Unit.;
AS-WP-16-019;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;A. Requirement for Wallet Providers;QES_18;Wallet Providers SHALL configure at least one default qualified signing service in the Wallet Unit.;
AS-WP-16-020;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;A. Requirement for Wallet Providers;QES_19;Wallet Providers SHALL ensure that, where the Signature Creation Application is implemented as part of the Wallet Unit, a Wallet Unit supports ETSI TS 119 101 (Electronic Signatures and Infrastructures (ESI); Policy and security requirements for applications for signature creation and signature validation) when using signing keys managed by the QSCD, whether locally, externally, or remotely in relation to the Wallet Instance.;
AS-WP-16-021;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;A. Requirement for Wallet Providers;QES_20;Empty;
AS-WP-16-022;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;A. Requirement for Wallet Providers;QES_21;Empty;
AS-WP-16-023;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;A. Requirement for Wallet Providers;QES_22;Empty;
AS-WP-16-024;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;B. Requirements for QTSPs;QES_23;QTSPs providing the remote QES part of a Wallet Solution SHALL support: 1. ETSI TS 119 431-1 (Electronic Signatures and Infrastructures (ESI); Policy and security requirements for trust service providers; Part 1: TSP service components operating a remote QSCD / SCDev), 2. ETSI TS 119 431-2 (Electronic Signatures and Infrastructures (ESI); Policy and security requirements for trust service providers; Part 2: TSP service components supporting AdES digital signature creation), 3. ETSI TS 119 432 (Electronic Signatures and Infrastructures (ESI); Protocols for remote digital signature creation). Wallet Providers and QTSPs providing the remote QES part of a Wallet Solution SHALL comply with Sole Control Assurance Level (SCAL) 2 as defined in CEN EN 419 241-1 (Trustworthy Systems Supporting Server Signing - Part 1: General System Security Requirements).;
AS-WP-16-025;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;B. Requirements for QTSPs;QES_24;QTSPs providing the Signature Creation Application as part of the remote QES part of a Wallet Solution SHALL support ETSI TS 119 101 (Electronic Signatures and Infrastructures (ESI); Policy and security requirements for applications for signature creation and signature validation).;
AS-WP-16-026;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;C. Requirements for Relying Parties;QES_24a;Relying Parties providing the Signature Creation Application in a Relying Party-centric flow SHALL support ETSI TS 119 101 (Electronic Signatures and Infrastructures (ESI); Policy and security requirements for applications for signature creation and signature validation).;
AS-WP-16-027;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;D. Requirements for the Commission;QES_25;Empty;
AS-WP-16-028;Actor-Specific Requirements;Wallet Providers;Topic 16 - Signing documents with a Wallet Unit;16;Signing documents with a Wallet Unit;D. Requirements for the Commission;QES_26;Empty;
AS-WP-18-001;Actor-Specific Requirements;Wallet Providers;Topic 18 - Combined presentations of attributes;18;Combined presentations of attributes;;ACP_01;A Cryptographic Binding of Attestations scheme SHALL enable a WSCA/WSCD to prove that it manages two or more private keys, paired with two or more public keys provided to it by the Wallet Unit.;a)These public keys may be included in WUAs, PIDs, attestations, or pseudonyms. b) The proof may be transitive, so a proof that two keys are stored/managed in the same WSCA/WSCD may be done by proving these keys relate to each other via a third key (also stored in the WSCA/WSCD).
AS-MS-18-001;Actor-Specific Requirements;Member States & Registrars;Topic 18 - Combined presentations of attributes;18;Combined presentations of attributes;;ACP_02;A Cryptographic Binding of Attestations scheme SHALL rely solely on algorithms standardised by a standardisation organisation recognised by the Commission or in a standard recognised by the Commission.;
AS-AP-18-001;Actor-Specific Requirements;Attestation & PID Providers;Topic 18 - Combined presentations of attributes;18;Combined presentations of attributes;;ACP_03;A Cryptographic Binding of Attestations scheme SHOULD be implemented using a Zero-Knowledge Proof mechanism that satisfies the requirements specified in [Topic 53](./annex-2.02-high-level-requirements-by-topic.md#a2331-topic-53-zero-knowledge-proofs).;
AS-WP-18-002;Actor-Specific Requirements;Wallet Providers;Topic 18 - Combined presentations of attributes;18;Combined presentations of attributes;;ACP_04;A Cryptographic Binding of Attestations scheme SHALL be compatible with the requirements for attestation issuance in this document, in particular [Topic 10](./annex-2.02-high-level-requirements-by-topic.md#a237-topic-10---issuing-a-pid-or-attestation-to-a-wallet-unit), as well as with requirements for both remote and proximity presentation flows in this document, in particular [Topic 1](./annex-2.02-high-level-requirements-by-topic.md#a231-topic-1---accessing-online-services-with-a-wallet-unit) and [Topic 24](./annex-2.02-high-level-requirements-by-topic.md#a2314-topic-24---user-identification-in-proximity-scenarios).;
AS-WP-18-003;Actor-Specific Requirements;Wallet Providers;Topic 18 - Combined presentations of attributes;18;Combined presentations of attributes;;ACP_05;A Cryptographic Binding of Attestations scheme SHALL enable an Attestation Provider, during the issuance of an attestation, to request and obtain proof that the private key for the new attestation is managed by the same WSCA/WSCD as the private key of a PID or another attestation already existing on the Wallet Unit.;ACP_05 and ACP_06 may require an addition to the common OpenID4VCI protocol referenced in requirement ISSU_01, or an extension or profile thereof.
AS-AP-18-002;Actor-Specific Requirements;Attestation & PID Providers;Topic 18 - Combined presentations of attributes;18;Combined presentations of attributes;;ACP_06;A Cryptographic Binding of Attestations scheme SHALL enable a PID Provider or Attestation Provider, during the issuance of a PID or attestation, to request and obtain proof that the private key for the new PID or attestation is managed by the same WSCA/WSCD as the private key of the WUA received.;
AS-AP-18-003;Actor-Specific Requirements;Attestation & PID Providers;Topic 18 - Combined presentations of attributes;18;Combined presentations of attributes;;ACP_07;Before making a request according to ACP_05, an Attestation Provider SHALL verify that the new attestation indeed belongs to the User of the existing PID or attestation.;
AS-WP-19-001;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_01;A Wallet Provider SHALL enable a User to access a user-friendly dashboard functionality in their Wallet Unit.;
AS-WP-19-002;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_02;The Wallet Unit SHALL log all transactions executed through the Wallet Unit, including any transactions that were not completed successfully. This log SHALL include all types of transaction executed through the Wallet Unit: a) PID or attestation issuance and re-issuance transactions, b) PID or attestation presentation transactions, c) Wallet-to-Wallet transactions (see [Topic 30](./annex-2.02-high-level-requirements-by-topic.md#a2319-topic-30---interaction-between-wallet-units)), d) pseudonym registration or presentation transactions, e) signature or seal creation transactions (see [Topic 16](./annex-2.02-high-level-requirements-by-topic.md#a2310-topic-16---signing-documents-with-a-wallet-unit)), f) data deletion requests sent to a Relying Party (see [Topic 48](./annex-2.02-high-level-requirements-by-topic.md#a2327-topic-48---blueprint-for-requesting-data-deletion-to-relying-parties)), g) reports sent to a Data Protection Authority (see [Topic 50](./annex-2.02-high-level-requirements-by-topic.md#a2328-topic-50---blueprint-to-report-unlawful-or-suspicious-request-of-data)), h) PID or attestation deletions by the User.;For the data to be logged for a data deletion request to a Relying Party or a report sent to a DPA, see Topic 48 and Topic 50, respectively. For other types of transaction, the data to be logged is specified in the requirements in this Topic.
AS-WP-19-003;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_02a;The Wallet Unit SHALL retain transactions in the log at least for the minimum retention period specified in applicable legislation. If the Wallet Unit must delete transactions from the log, for instance because of size limitations, the Wallet Unit SHALL notify the User via the dashboard before doing so, indicating the potential consequences for the User's data protection rights, and SHALL instruct the User how to export the transactions that are about to be deleted; see DASH_07.;
AS-WP-19-004;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_02b;The dashboard SHALL include a functionality to display to the User an overview of all transactions in the log.;
AS-WP-19-005;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_02c;The transaction log meant in DASH_02 SHALL comply with all relevant requirement in [Technical Specification 10](../../technical-specifications/ts10-data-portability-and-download-(export).md), including measures to ensure and/or verify its confidentiality, integrity, and authenticity.;
AS-WP-19-006;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_03;For a PID or attestation presentation transaction executed through the Wallet Unit, the log SHALL contain at least: a) the date and time of the transaction, b) the name and unique identifier of the corresponding Relying Party, and the Member State in which that Relying Party is established, c) the name, contact details (if available), and unique identifier of the intermediary, if an intermediary is involved in the transaction, d) the attestation type(s) and the identifier(s) of the attribute(s) that were requested, as well as those that were presented, e) in the case of non-completed transactions, the reason for such non-completion, f) the URL of the online service of the Relying Party's Registrar.  g) the web form URL (if available), e-mail address (if available), and telephone number (if available) provided by the Relying Party for sending data deletion requests, see requirement RPRC_11 in [Topic 44](./annex-2.02-high-level-requirements-by-topic.md#a2326-topic-44---registration-certificates-for-pid-providers-providers-of-qeaas-pub-eaas-and-non-qualified-eaas-and-relying-parties), h) the name and country of the Data Protection Authority supervising the Relying Party, as well as the web form URL (if available), e-mail address (if available), and telephone number (if available) provided by this DPA for reporting suspicious attribute presentation requests. i) information on the intended use and the URL to the applicable privacy policy (if available).;The information in points g), h), and i) may be retrieved from the registration certificate or from the Registrar's online service (see [Topic 44](../annex-2/annex-2.02-high-level-requirements-by-topic.md#a2326-topic-44---relying-party-registration-certificates)).
AS-WP-19-007;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_03a;For a PID or attestation presentation transaction or a Wallet-to-Wallet transaction executed through the Wallet Unit, the log SHALL NOT contain the value of any attributes presented to the Relying Party or the Verifier Wallet Unit, or the value of any transactional data included in the presentation request.;
AS-WP-19-008;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_03b;For a Wallet-to-Wallet transaction executed through the Wallet Unit, the log SHALL contain at least: a) the date and time of the transaction, b) the role of the Wallet Unit (Holder Wallet Unit or Verifier Wallet Unit), c) the attestation type(s) and the identifier(s) of the attribute(s) that were requested, as well as those that were presented, d) in the case of non-completed transactions, the reason for such non-completion.;
AS-WP-19-009;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_03c;For a pseudonym registration or presentation transaction executed through the Wallet Unit, the log SHALL contain at least: a) the date and time of the transaction, b) identifying information about the Relying Party, if known to the Wallet Unit, c) whether it is a pseudonym registration or pseudonym presentation transaction, d) in the case of non-completed transactions, the reason for such non-completion.;Regarding point b), see PA_20 in [Topic 11](./annex-2.02-high-level-requirements-by-topic.md#a238-topic-11---pseudonyms).
AS-WP-19-010;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_04;For a signature or seal creation transaction executed through the Wallet Unit, the log SHALL contain at least: a) the date and time of the transaction, b) the document or data signed or sealed (if available to the Wallet Unit), c) in the case of non-completed transactions, the reason for such non-completion.;
AS-WP-19-011;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_05;For a PID or attestation issuance or re-issuance transaction executed through the Wallet Unit, the log SHALL contain at least: a) the date and time of the transaction, b) the name, contact details (if available), and unique identifier of the corresponding PID Provider or Attestation Provider, c) the attestation type requested, as well as the attestation type issued, d) the number of attestations requested and issued (i.e., the size of the batch in case of batch issuance). d) in the case of non-completed transactions, the reason for such non-completion. e) for a re-issuance transaction, whether it was triggered by the User or by the Wallet Unit without involvement of the User, f) the URL of the associated Registrar's online service.;this URL can be retrieved from the access certificate.
AS-WP-19-012;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_05a;For the deletion of a PID or attestation by the User, the log SHALL contain at least: a) the date and time of the deletion event, b) the attestation type of the deleted PID or attestation. c) The name and unique identifier of the corresponding PID Provider or Attestation Provider.;This requirement is not about deletion of transactions from the log, as per DASH_06a.
AS-WP-19-013;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_06;The Wallet Provider SHALL ensure the confidentiality, integrity, and authenticity of all transactions included in the log.;
AS-WP-19-014;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_06a;Via the dashboard, the Wallet Unit SHALL enable the User to delete any transaction in the log. Before deleting any transactions, the Wallet Unit SHALL indicate to the User the potential consequences for the User's data protection rights.;This requirement applies even in case the minimum retention period specified in applicable legislation (see DASH_02a) is not yet over.
AS-WP-19-015;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_06b;The Wallet Unit SHALL ensure that no entity other than the User can delete transactions from the log, except possibly for the reason mentioned in DASH_02a.;
AS-WP-19-016;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_07;The dashboard SHALL allow the User to export the details of one or more transactions in the log to a file, using the common format specified according to DASH_02c, while ensuring their confidentiality, authenticity and integrity. The file SHALL be stored in an external storage or remote storage location of the User's choice, from among the storage options supported by the Wallet Unit and SHALL use the common format and security measures specified according to DASH_02c.;
AS-WP-19-017;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_08;For a natural-person User, a Wallet Instance SHALL provide a User interface.;
AS-WP-19-018;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_09;The User interface referred to in DASH_08 SHALL provide a view with - the EU Digital Identity Wallet Trust Mark, - accompanying general information on the certification of Wallet Solutions, - links to the certification status information as defined in the [Technical Specification 1](../../technical-specifications/ts1-eudi-wallet-trust-mark.md).;
AS-WP-19-019;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_09a;Positioning of the view meant in DASH_09 in the Wallet UI navigation SHALL follow design guidelines provided by the European Commission.;
AS-WP-19-020;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_09b;Wallet Providers and Wallet Units SHALL comply with all relevant requirements in [Technical Specification 1](../../technical-specifications/ts1-eudi-wallet-trust-mark.md) for the EUDI Wallet Trust Mark.;
AS-WP-19-021;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_10;Empty.;See requirement WIAM_12a in [Topic 40](./annex-2.02-high-level-requirements-by-topic.md#a2323-topic-40---wallet-instance-installation-and-wallet-unit-activation-and-management).
AS-WP-19-022;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_11;A Wallet Unit issued to a legal person SHALL allow the legal person to interact with the Wallet Unit in the appropriate interface provided by the Wallet Provider.;
AS-WP-19-023;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_12;The User interface referred to in DASH_08 SHALL enable the User, for each presentation transaction in the log, to easily request the Relying Party to delete any or all attributes presented to it in that transaction, or to send a report about that particular transaction to a DPA.;
AS-WP-20-001;Actor-Specific Requirements;Wallet Providers;Topic 20 - Strong User authentication for electronic payments;20;Strong User authentication for electronic payments;;SUA_01;The Wallet Units SHALL be able to process the transactional data included in a presentation request for that an attestation, according to all requirements in the associated Attestation Rulebook.;
AS-WP-20-002;Actor-Specific Requirements;Wallet Providers;Topic 20 - Strong User authentication for electronic payments;20;Strong User authentication for electronic payments;;SUA_02;The Attestation Rulebook (see [Topic 12](./annex-2.02-high-level-requirements-by-topic.md#a239-topic-12---attestation-rulebooks) of a SUA attestation SHALL specify the syntax and semantics of the transactional data associated with that attestation, as well as all necessary requirements for Wallet Units to process that transactional data, at least regarding a) displaying the data to the User when obtaining consent for signing the data, b) processing (e.g., hashing) the data for inclusion in the device binding signature, and c) the scope of information to be logged about a SUA attestation presentation transaction by a Wallet Unit.;
AS-WP-20-003;Actor-Specific Requirements;Wallet Providers;Topic 20 - Strong User authentication for electronic payments;20;Strong User authentication for electronic payments;;SUA_03;The Attestation Provider of a SUA attestation SHALL NOT issue such an attestation to a Wallet Unit that does not comply with all relevant requirements in the Attestation Rulebook for that attestation.;
AS-WP-20-004;Actor-Specific Requirements;Wallet Providers;Topic 20 - Strong User authentication for electronic payments;20;Strong User authentication for electronic payments;;SUA_04;In the response to a presentation request that includes transactional data, a Wallet Unit SHALL include (a representation of) that data, according to requirements included in the Attestation Rulebook or in information provided to the Wallet Unit in the presentation request. In the latter case, the rules to interpret such information SHALL be included in the Attestation Rulebook.;This requirement, as well as SUA_05, only applies if the requested SUA attestation is present on the Wallet Unit and if the User consents to signing the transactional data and presenting the requested attributes.
AS-WP-20-005;Actor-Specific Requirements;Wallet Providers;Topic 20 - Strong User authentication for electronic payments;20;Strong User authentication for electronic payments;;SUA_05;The Wallet Unit SHALL include (a representation of) the transactional data received in a presentation request in the signature creation process used for device binding, using the private key of the requested SUA attestation, using the mechanisms provided for key binding in [SD-JWT-VC] and mdoc authentication in [ISO/IEC 18013-5], and complying with the applicable requirements in the Attestation Rulebook, see SUA_02.;a) The resulting signature value constitutes a proof of transaction and fulfils the requirement of the authentication code required in [PSD2]. b) See also requirement OIA_02 in [Topic 1](./annex-2.02-high-level-requirements-by-topic.md#a231-topic-1---accessing-online-services-with-a-wallet-unit).
AS-WP-20-006;Actor-Specific Requirements;Wallet Providers;Topic 20 - Strong User authentication for electronic payments;20;Strong User authentication for electronic payments;;SUA_06;The Wallet Unit SHALL be able to adapt the dialogue message(s) displayed to the User (like font size and colour, background colour, text position, labels in the buttons to 'approve' or 'reject' a transaction), according to requirements in an Attestation Rulebook or in information provided to the Wallet Unit in the presentation request. In the latter case, the rules to interpret such information SHALL be included in the Attestation Rulebook.;
EW-PIO-24-001;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 24 - User identification in proximity scenarios;24;User identification in proximity scenarios;;ProxId_01;To enable identification using proximity flows, Wallet Units SHALL support device retrieval as specified in ISO/IEC 18013-5 for presenting PID or attestation attributes. Wallet Units SHALL comply with the requirements for mDLs and mdocs ISO/IEC 18013-5.;Nominally, ISO/IEC 18013-5 is intended only for mDLs and mDL readers. The corresponding standard for mobile documents in general (including Wallet Units with the EUDI Wallet ecosystem) will be ISO/IEC 23220-4, which is based on ISO/IEC 18013-5. However, the latter standard is not finished yet and therefore cannot be referenced at the moment. To guarantee interoperability between Wallet Units and Relying Party Instances in proximity scenarios, it is necessary to make choices from among the possibilities specified in ISO/IEC 18013-5. Making the same choices as for mDLs ensure this.
EW-PIO-24-002;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 24 - User identification in proximity scenarios;24;User identification in proximity scenarios;;ProxId_01a;If a Relying Party supports using proximity flows, its Relying Party Instances SHALL support device retrieval as specified in ISO/IEC 18013-5 for requesting PID or attestation attributes. Such Relying Party Instances SHALL comply with the requirements for mDL readers and mdoc readers in ISO/IEC 18013-5.;See note to ProxId_01. Support for proximity flows by Relying Parties is not mandatory.
EW-PIO-24-003;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 24 - User identification in proximity scenarios;24;User identification in proximity scenarios;;ProxId_02;Wallet Units, PID Providers, Attestation Providers, Wallet Providers, and Relying Parties SHALL NOT support server retrieval as specified in ISO/IEC 18013-5 for requesting and presenting PID or attestation attributes.;Using server retrieval, a Relying Party would request User attributes directly from a PID Provider or Attestation Provider, after having received an authentication and/or authorisation token from the User's Wallet Unit.
EW-PIO-24-004;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 24 - User identification in proximity scenarios;24;User identification in proximity scenarios;;ProxId_03;A Wallet Unit SHALL present the presentation request and the identity of the Relying Party to the User when processing the request.;
EW-PIO-24-005;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 24 - User identification in proximity scenarios;24;User identification in proximity scenarios;;ProxId_04;A Wallet Unit SHALL request its User to approve the presentation of attributes from their Wallet Unit for proximity identification before presenting them to the Relying Party.;
EW-PIO-24-006;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 24 - User identification in proximity scenarios;24;User identification in proximity scenarios;;ProxId_05;A Wallet Unit SHALL transmit the requested User attributes to the requesting Relying Party Instance securely in accordance with ISO/IEC 18013-5 for proximity flows.;
EW-PIO-24-007;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 24 - User identification in proximity scenarios;24;User identification in proximity scenarios;;ProxId_06;Empty;
AS-MS-25-001;Actor-Specific Requirements;Member States & Registrars;Topic 25 - Unified definition and controlled vocabularies for attributes;25;Unified definition and controlled vocabularies for attributes (Catalogue of attributes);;CAT_01;Empty;
AS-MS-25-002;Actor-Specific Requirements;Member States & Registrars;Topic 25 - Unified definition and controlled vocabularies for attributes;25;Unified definition and controlled vocabularies for attributes (Catalogue of attributes);;CAT_01a;Empty;
AS-MS-25-003;Actor-Specific Requirements;Member States & Registrars;Topic 25 - Unified definition and controlled vocabularies for attributes;25;Unified definition and controlled vocabularies for attributes (Catalogue of attributes);;CAT_01b;Empty;
AS-MS-25-004;Actor-Specific Requirements;Member States & Registrars;Topic 25 - Unified definition and controlled vocabularies for attributes;25;Unified definition and controlled vocabularies for attributes (Catalogue of attributes);;CAT_02;Empty;
AS-MS-25-005;Actor-Specific Requirements;Member States & Registrars;Topic 25 - Unified definition and controlled vocabularies for attributes;25;Unified definition and controlled vocabularies for attributes (Catalogue of attributes);;CAT_03;Empty;
AS-MS-25-006;Actor-Specific Requirements;Member States & Registrars;Topic 25 - Unified definition and controlled vocabularies for attributes;25;Unified definition and controlled vocabularies for attributes (Catalogue of attributes);;CAT_03b;Empty;
AS-MS-25-007;Actor-Specific Requirements;Member States & Registrars;Topic 25 - Unified definition and controlled vocabularies for attributes;25;Unified definition and controlled vocabularies for attributes (Catalogue of attributes);;CAT_04;A request to include or to modify an attribute in the catalogue of attributes SHALL indicate how a QTSP can use the verification point for that attribute.;This could be, for instance, in the form of (a reference to) an endpoint description text.
AS-MS-27-001;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;A. General requirements for Member State registration processes;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.;Member States may choose to implement a single registry for all these roles, or a separate registry for each of these roles.
AS-MS-27-002;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;A. General requirements for Member State registration processes;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](../../technical-specifications/ts6-common-set-of-rp-information-to-be-registered.md).;For PID Providers, QEAA Providers, PuB-EAA Providers, and non-qualified EAA Providers, the common set of data specified in [Technical Specification 6] include the attestation type(s) that the provider intends to issue to Wallet Units.
AS-MS-27-003;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;A. General requirements for Member State registration processes;Reg_01b;Empty;
AS-MS-27-004;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;A. General requirements for Member State registration processes;Reg_02;Member States SHALL make publicly available all necessary details and documentation about the registration processes for their registry.;
AS-MS-27-005;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;A. General requirements for Member State registration processes;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](../../technical-specifications/ts5-common-formats-and-api-for-rp-registration-information.md), for the purpose of transparency to Users and other stakeholders.;
AS-MS-27-006;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;A. General requirements for Member State registration processes;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.;
AS-MS-27-007;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;A. General requirements for Member State registration processes;Reg_05;Empty;
AS-MS-27-008;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;A. General requirements for Member State registration processes;Reg_06;Member States SHALL support the common API specified in [Technical Specification 5](../../technical-specifications/ts5-common-formats-and-api-for-rp-registration-information.md) for to enable automated retrieval of registry entries from the Member States' registries.;[Technical Specification 5] specifies the use of a secure channel protecting the authenticity and integrity of the information in the registry during transport, and does not require authentication or prior registration and authorisation of any entity wishing to retrieve the information in the registry.
AS-MS-27-009;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;A. General requirements for Member State registration processes;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.;
AS-MS-27-010;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;A. General requirements for Member State registration processes;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.;
AS-MS-27-011;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;A. General requirements for Member State registration processes;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.;
AS-MS-27-012;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;B. General requirements for the issuance of access certificates;Reg_10;A Member State SHALL ensure that an Access Certificate Authority notified according to [[Topic 31](./annex-2.02-high-level-requirements-by-topic.md#a2320-topic-31---notification-and-publication-of-pid-provider-wallet-provider-attestation-provider-access-certificate-authority-and-provider-of-registration-certificates)] issues an access certificate to all PID Providers, QEAA Providers, PuB-EAA Providers, non-qualified EAA Providers, and Relying Parties registered in one of the Member State's registries.;
AS-MS-27-013;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;B. General requirements for the issuance of access certificates;Reg_11;A Member State SHALL ensure that the issuance process of access certificates by their notified Access Certificate Authority(s) complies with a common Certificate Policy for Access Certificate Authority.;
AS-MS-27-014;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;B. General requirements for the issuance of access certificates;Reg_12;The Commission SHALL provide technical specifications establishing the common Access Certificate Authority Certificate Policy mentioned in Reg_11.;
AS-MS-27-015;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;B. General requirements for the issuance of access certificates;Reg_13;The common Certificate Policy mentioned in Reg_12 SHALL require that an Access Certificate Authority logs all issued access certificates for Certificate Transparency (CT), according to all requirements in [Topic 55](./annex-2.02-high-level-requirements-by-topic.md#a2333-topic-55---certificate-transparency).;
AS-MS-27-016;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;B. General requirements for the issuance of access certificates;Reg_14;The common Certificate Policy mentioned in Reg_12 SHALL require that an Access Certificate Authority provides one or more method(s) to revoke the access certificates it issued.;
AS-MS-27-017;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;B. General requirements for the issuance of access certificates;Reg_15;The common Certificate Policy mentioned in Reg_12 SHALL include a policy for revocation, which SHALL require that an Access Certificate Authority revokes an access certificate at least when: - the certificate subject which is a Relying Party is suspended or cancelled by the respective Registrar, - the certificate subject which is a PID Provider, QEAA Provider, PuB-EAA Provider, or non-qualified EAA Provider is suspended or cancelled by the respective Registrar, - on request of the certificate subject, or - on request of a competent national authority.;
AS-MS-27-018;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;B. General requirements for the issuance of access certificates;Reg_16;The common Certificate Policy mentioned in Reg_12 SHALL specify the profile of access certificates in detail.;
AS-MS-27-019;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;B. General requirements for the issuance of access certificates;Reg_17;Empty;
AS-MS-27-020;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;B. General requirements for the issuance of access certificates;Reg_18;The common Certificate Policy mentioned in Reg_12 SHALL define the minimum change history information to be stored for resolving possible disputes regarding registration.;
AS-MS-27-021;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;C. Requirements for the registration of PID Providers;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.;
AS-MS-27-022;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;C. Requirements for the registration of PID Providers;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.;
AS-MS-27-023;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;C. Requirements for the registration of PID Providers;Reg_20a;A Registrar SHALL provide a method to suspend or cancel a registered PID Provider.;
AS-MS-27-024;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;C. Requirements for the registration of PID Providers;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.;
AS-MS-27-025;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;D. Requirements for the registration of Attestation Providers;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.;
AS-MS-27-026;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;D. Requirements for the registration of Attestation Providers;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.;
AS-MS-27-027;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;D. Requirements for the registration of Attestation Providers;Reg_22a;A Registrar SHALL provide a method to suspend or cancel a registered Attestation Provider.;
AS-MS-27-028;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;D. Requirements for the registration of Attestation Providers;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.;
AS-MS-27-029;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;E. Requirements for the registration of Relying Parties;Reg_23;Empty;
AS-MS-27-030;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;E. Requirements for the registration of Relying Parties;Reg_24;A Member State SHALL enable a Relying Party to register remotely, using an API or user interface.;
AS-MS-27-031;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;E. Requirements for the registration of Relying Parties;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.;
AS-MS-27-032;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;E. Requirements for the registration of Relying Parties;Reg_26;With respect to Reg_25, a Member State SHALL consider whether a registering entity intends to act as an intermediary.;According to the [European Digital Identity Regulation], an intermediary is a Relying Party.
AS-MS-27-033;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;E. Requirements for the registration of Relying Parties;Reg_27;Empty;
AS-MS-27-034;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;E. Requirements for the registration of Relying Parties;Reg_28;Empty;
AS-MS-27-035;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;E. Requirements for the registration of Relying Parties;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.;
AS-MS-27-036;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;E. Requirements for the registration of Relying Parties;Reg_30;Empty;
AS-MS-27-037;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;F. Requirements for the contents of access certificates;Reg_31;The common Certificate Policy mentioned in Reg_12 SHALL require that an access certificate contains a name for the PID Provider, QEAA Provider, PuB-EAA Provider, non-qualified EAA Provider, or Relying Party, in a format suitable for presenting to a User.;
AS-MS-27-038;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;F. Requirements for the contents of access certificates;Reg_32;The common Certificate Policy mentioned in Reg_12 SHALL require that an access certificate contains an EU-wide unique identifier for the PID Provider, QEAA Provider, PuB-EAA Provider, non-qualified EAA Provider, or Relying Party, and SHALL specify a method for deriving such identifiers.;a) The EU-wide unique identifier could, for example, be a composition of a unique identifier of the Registrar, defined in the policy, and a unique identifier for the Relying Party allocated by this Registrar. b) This Relying Party identifier is identical in all access certificates issued to a given entity.
AS-MS-27-039;Actor-Specific Requirements;Member States & Registrars;Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;27;Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;F. Requirements for the contents of access certificates;Reg_33;Empty;
AS-MS-28-001;Actor-Specific Requirements;Member States & Registrars;Topic 28 - Wallet Unit for legal persons;28;Wallet Unit for legal persons;;LP_01;The Commission SHALL develop a Legal-person PID Rulebook to specify the attestation scheme and other technical details applicable for legal-person PIDs.;
AS-AP-28-001;Actor-Specific Requirements;Attestation & PID Providers;Topic 28 - Wallet Unit for legal persons;28;Wallet Unit for legal persons;;LP_02;The attestation type of a legal-person PID SHALL be different from the attestation type of a natural person PID.;See [[Topic 12](./annex-2.02-high-level-requirements-by-topic.md#a239-topic-12---attestation-rulebooks)] for an explanation of the concept of attestation type.
EW-DM-28-001;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 28 - Wallet Unit for legal persons;28;Wallet Unit for legal persons;;LP_03;A legal-person PID SHALL comply with all requirements in the Legal-person PID Rulebook mentioned in LP_01.;
AS-MS-29-001;Actor-Specific Requirements;Member States & Registrars;Topic 29 - Representation paradigm;29;Representation paradigm;;RP_01;The Commission SHALL create an Attestation Rulebook for representation attestations issued to a natural person representing another natural person. The Rulebook SHALL specify the unique attestation type of these representation attestations. The Rulebook SHALL also specify attributes used for defining a validity period, the nature of the representation, and the operations the representative is authorised to perform, thereby limiting the scope of its authorisation.;
EW-PIO-29-001;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 29 - Representation paradigm;29;Representation paradigm;;RP_02;An Attestation Provider issuing representation attestations to a natural person representing another natural person SHALL ensure that either the attestations are short-lived or that all entities which, according to applicable law, must have the ability to request revocation of such attestations, are able to do so.;
AS-WP-30-001;Actor-Specific Requirements;Wallet Providers;Topic 30 - Interaction between Wallet Units;30;Interaction between Wallet Units;;W2W_01;A Wallet Unit SHALL be able to act as a Holder Wallet Unit, in accordance with all requirements in this Topic.;
AS-WP-30-002;Actor-Specific Requirements;Wallet Providers;Topic 30 - Interaction between Wallet Units;30;Interaction between Wallet Units;;W2W_02;When acting as a Holder Wallet Unit, if there is a contradiction between a requirement for Holder Wallet Units in this Topic and any requirement for Wallet Units in other Topics in this document, the requirement in this Topic SHALL take precedence. However, when acting as a Holder Wallet Unit, a Wallet Unit SHALL comply with all requirements for Wallet Units in other Topics in this document that do not contradict any requirement in this Topic.;
AS-WP-30-003;Actor-Specific Requirements;Wallet Providers;Topic 30 - Interaction between Wallet Units;30;Interaction between Wallet Units;;W2W_03;A Wallet Unit SHALL be able to act as a Verifier Wallet Unit, in accordance with all requirements in this Topic.;
AS-WP-30-004;Actor-Specific Requirements;Wallet Providers;Topic 30 - Interaction between Wallet Units;30;Interaction between Wallet Units;;W2W_04;When acting as a Verifier Wallet Unit, a Wallet Unit SHALL NOT comply with any requirement for Wallet Units in other Topics in this document.;
AS-WP-30-005;Actor-Specific Requirements;Wallet Providers;Topic 30 - Interaction between Wallet Units;30;Interaction between Wallet Units;;W2W_05;A Wallet Unit SHALL act as a Holder Wallet Unit only if the User selects a 'Holder Wallet Unit mode'. If the User closes the Wallet Unit, or after a period of non-activity, the Wallet Unit SHALL return to 'normal' mode.;
AS-WP-30-006;Actor-Specific Requirements;Wallet Providers;Topic 30 - Interaction between Wallet Units;30;Interaction between Wallet Units;;W2W_06;When entering the Holder Wallet Unit mode, a Wallet Unit SHALL inform its User that this mode should only be used for interactions with natural persons using a Wallet Unit, and that the User should not proceed if they are in fact interacting with a Relying Party.;
AS-WP-30-007;Actor-Specific Requirements;Wallet Providers;Topic 30 - Interaction between Wallet Units;30;Interaction between Wallet Units;;W2W_07;A Wallet Unit SHALL act as a Verifier Wallet Unit only if the User selects a 'Verifier Wallet Unit mode'. If the User closes the Wallet Unit, or after a period of non-activity, the Wallet Unit SHALL return to 'normal' mode.;
EW-PIO-30-001;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 30 - Interaction between Wallet Units;30;Interaction between Wallet Units;;W2W_08;A Verifier Wallet Unit and a Holder Wallet Unit SHALL support attestation presentation only in proximity, meaning they SHALL support only [ISO/IEC 18013-5] to communicate.;
AS-WP-30-008;Actor-Specific Requirements;Wallet Providers;Topic 30 - Interaction between Wallet Units;30;Interaction between Wallet Units;;W2W_09;Holder Wallet Units SHALL comply with the requirements for mDLs and for mdocs in ISO/IEC 18013-5, unless specified differently in [Technical Specification 9](../../technical-specifications/ts9-wallet-to-wallet-interactions.md).;
AS-WP-30-009;Actor-Specific Requirements;Wallet Providers;Topic 30 - Interaction between Wallet Units;30;Interaction between Wallet Units;;W2W_10;Verifier Wallet Units SHALL comply with the requirements for mDL readers and for mdoc readers in ISO/IEC 18013-5, unless specified differently in [Technical Specification 9](../../technical-specifications/ts9-wallet-to-wallet-interactions.md).;
AS-WP-30-010;Actor-Specific Requirements;Wallet Providers;Topic 30 - Interaction between Wallet Units;30;Interaction between Wallet Units;;W2W_11;A Holder Wallet Unit SHOULD provide the Holder, through a user-friendly UI, with the option to inform the Verifier Wallet Unit about the attributes which the Verifier should include in the presentation request, by sending a presentation offer. If the Holder creates a presentation offer, the Holder Wallet Unit SHALL transfer it to the Verifier Wallet Unit as specified in [Technical Specification 9](../../technical-specifications/ts9-wallet-to-wallet-interactions.md).;TS9 specifies an extension of the device engagement structure specified in ISO/IEC 18013-5.
AS-WP-30-011;Actor-Specific Requirements;Wallet Providers;Topic 30 - Interaction between Wallet Units;30;Interaction between Wallet Units;;W2W_12;A Holder Wallet Unit SHALL recommend the Holder to create a presentation offer, as this will increase the chance of success of the use case.;
AS-WP-30-012;Actor-Specific Requirements;Wallet Providers;Topic 30 - Interaction between Wallet Units;30;Interaction between Wallet Units;;W2W_13;A Verifier Wallet Unit SHALL provide the Verifier, through a user-friendly UI, with the possibility to select the attributes that will be included in the presentation request.;
AS-WP-30-013;Actor-Specific Requirements;Wallet Providers;Topic 30 - Interaction between Wallet Units;30;Interaction between Wallet Units;;W2W_14;For the purposes of W2W_07, if the Verifier Wallet Unit received a presentation offer, it SHALL present this offer to the Verifier, and enable the Verifier to include one or more of the attributes in the offer into the presentation request. However, the Verifier Wallet Unit SHALL NOT allow the Verifier to include any attribute not present in the offer.;
AS-WP-30-014;Actor-Specific Requirements;Wallet Providers;Topic 30 - Interaction between Wallet Units;30;Interaction between Wallet Units;;W2W_15;For the purposes of W2W_07, if the Verifier Wallet Unit did not receive a presentation offer, it SHALL present the Verifier with a list of attributes that can be included in the presentation request. The Verifier Wallet Unit MAY ask the Verifier some questions about the purpose of the use case to narrow down the list.;
AS-WP-30-015;Actor-Specific Requirements;Wallet Providers;Topic 30 - Interaction between Wallet Units;30;Interaction between Wallet Units;;W2W_16;A Verifier Wallet Unit SHALL authenticate the Verifier and SHALL obtain the Verifier's approval prior to sending a presentation request to a Holder Wallet Unit.;
AS-WP-30-016;Actor-Specific Requirements;Wallet Providers;Topic 30 - Interaction between Wallet Units;30;Interaction between Wallet Units;;W2W_17;A Verifier Wallet Unit SHALL implement measures to limit the number of presentation requests it can send per unit of time, to prevent abuse of the Wallet-to-Wallet functionality by Relying Parties. The limitation strategy, for instance exponential backoff time between subsequent presentation requests or hard limits for the number of requests, SHALL be decided by the Wallet Provider, based on applicable requirements in [Technical Specification 9](../../technical-specifications/ts9-wallet-to-wallet-interactions.md).;
AS-WP-30-017;Actor-Specific Requirements;Wallet Providers;Topic 30 - Interaction between Wallet Units;30;Interaction between Wallet Units;;W2W_18;When receiving a presentation request, a Holder Wallet Unit SHOULD verify the validity of the Verifier Wallet Unit before presenting a received request to the Holder, provided [Technical Specification 9](../../technical-specifications/ts9-wallet-to-wallet-interactions.md) specifies a suitable mechanism for doing so.;
AS-WP-30-018;Actor-Specific Requirements;Wallet Providers;Topic 30 - Interaction between Wallet Units;30;Interaction between Wallet Units;;W2W_19;When receiving a presentation response, a Verifier Wallet SHALL verify the received attestation according to requirements OIA_12 - OIA_15 in [Topic 1](./annex-2.02-high-level-requirements-by-topic.md#a231-topic-1---accessing-online-services-with-a-wallet-unit).;
AS-WP-30-019;Actor-Specific Requirements;Wallet Providers;Topic 30 - Interaction between Wallet Units;30;Interaction between Wallet Units;;W2W_20;A Verifier Wallet Unit SHALL display all verified attributes to the Verifier.;
AS-WP-30-020;Actor-Specific Requirements;Wallet Providers;Topic 30 - Interaction between Wallet Units;30;Interaction between Wallet Units;;W2W_21;A Verifier Wallet Unit SHALL NOT persistently store any attestations or attributes received. A Verifier Wallet Unit SHOULD minimize the time the received presentation is stored in memory. A Verifier Wallet Unit SHALL comply with OIA_16 in [Topic 1](./annex-2.02-high-level-requirements-by-topic.md#a231-topic-1---accessing-online-services-with-a-wallet-unit).;
AS-WP-30-021;Actor-Specific Requirements;Wallet Providers;Topic 30 - Interaction between Wallet Units;30;Interaction between Wallet Units;;W2W_22;Wallet Providers SHOULD take measures to prevent a User from taking screenshots while their Wallet Unit is acting as a Verifier Wallet Unit.;
AS-MS-31-001;Actor-Specific Requirements;Member States & Registrars;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;A. Generic requirements for notification;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, according all relevant requirements in [Technical Specification 2](../../technical-specifications/ts2-notification-publication-provider-information.md).;
AS-MS-31-002;Actor-Specific Requirements;Member States & Registrars;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;A. Generic requirements for notification;GenNot_02;As part of [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.;The outcome of the notification procedure is the publication of the information notified by the Member State according to [Article 5a](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e1347-1-1) (18) in a machine and human readable manner using the common system mentioned in Section H, TLPub_01.
AS-MS-31-003;Actor-Specific Requirements;Member States & Registrars;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;A. Generic requirements for notification;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 and in a human-readable format, manually and/or automatically using e.g. a web service and/or API.;
AS-MS-31-004;Actor-Specific Requirements;Member States & Registrars;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;A. Generic requirements for notification;GenNot_04;As regard to GenNot_03, second bullet, the Commission SHALL verify whether the notified data is complete and meets the technical specifications, while the Member States SHALL be responsible for the correctness of the notified information.;
AS-MS-31-005;Actor-Specific Requirements;Member States & Registrars;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;A. Generic requirements for notification;GenNot_05;As part of the specifications 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 Trusted List SHALL be changed to Invalid.;
AS-MS-31-006;Actor-Specific Requirements;Member States & Registrars;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;B. Requirements for the notification of PID Providers;PPNot_01;The European Commission SHALL establish technical specifications for the common set of information to be notified about PID Providers.;
AS-WP-31-001;Actor-Specific Requirements;Wallet Providers;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;B. Requirements for the notification of PID Providers;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.;a) Relating to point 3. above: PID Provider Access Certificate Authority trust anchors are notified separately from the Access Certificate Authority for Relying Parties (see Section G below), since PID Providers are -legally speaking- not Relying Parties. b) For the concept of an Access Certificate Authority, see also [[Topic 27](./annex-2.02-high-level-requirements-by-topic.md#a2316-topic-27---registration-of-pid-providers-providers-of-qeaas-pub-eaas-and-non-qualified-eaas-and-relying-parties)] and [Section 6.3.2 of the ARF main document](../../architecture-and-reference-framework-main.md#632-pid-provider-or-attestation-provider-registration-and-notification).
AS-MS-31-007;Actor-Specific Requirements;Member States & Registrars;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;B. Requirements for the notification of PID Providers;PPNot_03;PID Providers SHALL ensure that all PIDs they issue can be authenticated using the PID Provider trust anchors notified to the Commission.;
AS-MS-31-008;Actor-Specific Requirements;Member States & Registrars;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;B. Requirements for the notification of PID Providers;PPNot_04;PID Providers SHALL ensure that their PID Provider access certificates can be authenticated using the applicable Access Certificate Authority trust anchors notified to the Commission.;[[Topic 6](./annex-2.02-high-level-requirements-by-topic.md#a234-topic-6---relying-party-authentication-and-user-approval)] describes how access certificates will be used.
AS-MS-31-009;Actor-Specific Requirements;Member States & Registrars;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;B. Requirements for the notification of PID Providers;PPNot_05;PID Provider trust anchors SHALL be accepted because of their secure notification by the Member States to the Commission and by their publication in the corresponding Commission-compiled PID Provider Trusted List which is sealed by the Commission.;
AS-MS-31-010;Actor-Specific Requirements;Member States & Registrars;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;B. Requirements for the notification of PID Providers;PPNot_06;Access Certificate Authority trust anchors SHALL be accepted because of their secure notification by the Member States to the Commission and by their publication in the corresponding Commission-compiled Access Certificate Authority Trusted List which is signed or sealed by the Commission.;
AS-MS-31-011;Actor-Specific Requirements;Member States & Registrars;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;B. Requirements for the notification of PID Providers;PPNot_07;The format of the PID Provider Trusted List SHALL comply with ETSI TS 119 612 v2.1.1 or with a suitable profile similarly derived from ETSI TS 102 231.;
AS-WP-31-002;Actor-Specific Requirements;Wallet Providers;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;C. Requirements for the notification of Wallet Providers;WPNot_01;The European Commission SHALL establish technical specifications for the common set of information to be notified about Wallet Providers.;
AS-WP-31-003;Actor-Specific Requirements;Wallet Providers;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;C. Requirements for the notification of Wallet Providers;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 Wallet Unit Attestations issued by the Wallet Provider.;a) See [[Topic 9](./annex-2.02-high-level-requirements-by-topic.md#a236-topic-9---wallet-unit-attestation)] and [[Topic 38](./annex-2.02-high-level-requirements-by-topic.md#a2322-topic-38---wallet-unit-revocation)] for the definition of the WUA. b) A Wallet Provider does not need an access certificate to interact with Wallet Units.
AS-WP-31-004;Actor-Specific Requirements;Wallet Providers;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;C. Requirements for the notification of Wallet Providers;WPNot_03;Wallet Providers SHALL ensure that all WUAs they issue can be authenticated using the trust anchors notified to the Commission.;
AS-WP-31-005;Actor-Specific Requirements;Wallet Providers;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;C. Requirements for the notification of Wallet Providers;WPNot_04;Wallet Provider trust anchors SHALL be accepted because of their secure notification by the Member States to the Commission and by their publication in the corresponding Commission-compiled Wallet Provider Trusted List which is sealed by the Commission.;
AS-WP-31-006;Actor-Specific Requirements;Wallet Providers;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;C. Requirements for the notification of Wallet Providers;WPNot_05;The format of the Wallet Provider Trusted List SHALL comply with ETSI TS 119 612 v2.1.1 or with a suitable profile similarly derived from ETSI TS 102 231.;
AS-WP-31-007;Actor-Specific Requirements;Wallet Providers;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;C. Requirements for the notification of Wallet Providers;WPNot_06;If a Wallet Provider is cancelled (see requirement GenNot_05 above), that Wallet Provider SHALL immediately revoke all of its valid WUAs, in accordance with the requirements in [Topic 38](./annex-2.02-high-level-requirements-by-topic.md#a2322-topic-38---wallet-unit-revocation). 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 all or some of its valid WUAs.;
AS-MS-31-012;Actor-Specific Requirements;Member States & Registrars;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;D. Requirements for the notification of PuB-EAA Providers;PuBPNot_01;The European Commission SHALL establish technical specifications for the common set of information to be notified about PuB-EAA Providers.;
AS-WP-31-008;Actor-Specific Requirements;Wallet Providers;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;D. Requirements for the notification of PuB-EAA Providers;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](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e3902-1-1) are met. 2. 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.;
AS-MS-31-013;Actor-Specific Requirements;Member States & Registrars;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;D. Requirements for the notification of PuB-EAA Providers;PuBPNot_03;The format of the PuB-EAA Provider Trusted List SHALL comply with ETSI TS 119 612 v2.1.1 or with a suitable profile similarly derived from ETSI TS 102 231.;
AS-MS-31-014;Actor-Specific Requirements;Member States & Registrars;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;E. Requirements for the notification of Access Certificate Authorities and Providers of registration certificates;RPACANot_01;The European Commission SHALL establish technical specifications for the common set of information to be notified about Access Certificate Authorities and Providers of registration certificates.;
AS-WP-31-009;Actor-Specific Requirements;Wallet Providers;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;E. Requirements for the notification of Access Certificate Authorities and Providers of registration certificates;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 Relying Parties, PID Providers, QEAA Providers, PuB-EAA Providers, and non-qualified EAA Providers by Wallet Units.;
AS-MS-31-015;Actor-Specific Requirements;Member States & Registrars;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;E. Requirements for the notification of Access Certificate Authorities and Providers of registration certificates;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.;
AS-MS-31-016;Actor-Specific Requirements;Member States & Registrars;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;E. Requirements for the notification of Access Certificate Authorities and Providers of registration certificates;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.;
AS-MS-31-017;Actor-Specific Requirements;Member States & Registrars;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;E. Requirements for the notification of Access Certificate Authorities and Providers of registration certificates;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 Trusted Lists, which are signed or sealed by the Commission.;
AS-MS-31-018;Actor-Specific Requirements;Member States & Registrars;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;E. Requirements for the notification of Access Certificate Authorities and Providers of registration certificates;RPACANot_05;The format of the Trusted Lists mentioned in RPACANot_04 SHALL comply with ETSI TS 119 612 v2.1.1 or with a suitable profile similarly derived from ETSI TS 102 231.;
EW-DM-31-001;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;E. Requirements for the notification of Access Certificate Authorities and Providers of registration certificates;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.;This implies that if an intermediary obtained its access certificates from an Access Certificate Authority that is suspended or cancelled, any intermediated Relying Parties depending on that intermediary will not be able to request attributes from Wallet Units, even though it has valid registration certificates. Such an intermediated Relying Party will either have to transit to another intermediary (which has access certificates issued by an active Access Certification Authority) or wait until the original intermediary obtains new access certificates either from another Access CA or from the original one, once that CA can continue its operations.
AS-MS-31-019;Actor-Specific Requirements;Member States & Registrars;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;E. Requirements for the notification of Access Certificate Authorities and Providers of registration certificates;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.;
AS-WP-31-010;Actor-Specific Requirements;Wallet Providers;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;F. Requirements for the publication of Trusted Lists compiled by the;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.;
AS-WP-31-011;Actor-Specific Requirements;Wallet Providers;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;F. Requirements for the publication of Trusted Lists compiled by the;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.;The information to be published MAY be different from the information to be notified per requirements PPNot_01, WPNot_01, PuBPNot_01, and RPACANot_01 above, respectively.
EW-DM-31-002;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;F. Requirements for the publication of Trusted Lists compiled by the;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.;
EW-DM-31-003;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;F. Requirements for the publication of Trusted Lists compiled by the;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.;
EW-DM-31-004;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;F. Requirements for the publication of Trusted Lists compiled by the;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.;
AS-WP-31-012;Actor-Specific Requirements;Wallet Providers;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;F. Requirements for the publication of Trusted Lists compiled by the;TLPub_06;The Commission SHALL publish in the OJEU the locations of the Trusted Lists for PID Providers, Wallet Providers, PuB-EAA Providers, Access Certificate Authorities, and Providers of registration certificates.;
AS-MS-31-020;Actor-Specific Requirements;Member States & Registrars;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;F. Requirements for the publication of Trusted Lists compiled by the;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.;
AS-WP-31-013;Actor-Specific Requirements;Wallet Providers;Topic 31 - Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;31;Notification and publication of PID Provider, Wallet Provider, Attestation Provider, Access Certificate Authority, and Provider of registration certificates;F. Requirements for the publication of Trusted Lists compiled by the;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.;
AS-WP-34-001;Actor-Specific Requirements;Wallet Providers;Topic 34 - Migrate to a different Wallet Solution;34;Migrate to a different Wallet Solution;A. Back-up requirements;Mig_01;A Wallet Unit SHALL include and keep up-to-date a Migration Object, containing the following information: - The contents of the log for all transactions executed through the Wallet Unit, as listed in requirement DASH_02. - A list of PIDs and attestations, except Wallet Unit Attestations, present in the Wallet Unit, according to the requirements in this Topic.;
AS-WP-34-002;Actor-Specific Requirements;Wallet Providers;Topic 34 - Migrate to a different Wallet Solution;34;Migrate to a different Wallet Solution;A. Back-up requirements;Mig_02;The Migration Object SHALL comply with all requirements in [Technical Specification 10](../../technical-specifications/ts10-data-portability-and-download-(export).md).;
AS-WP-34-003;Actor-Specific Requirements;Wallet Providers;Topic 34 - Migrate to a different Wallet Solution;34;Migrate to a different Wallet Solution;A. Back-up requirements;Mig_03;For each PID or device-bound attestation that is issued to it, a Wallet Unit SHALL add to the Migration Object all data necessary to request issuance of that PID or attestation once again. This SHALL include at least the attestation type and the PID Provider or Attestation Provider that issued the PID or attestation, as well as their service supply points. However, the Migration Object SHALL NOT contain attribute identifiers or attribute values, and SHALL NOT contain any private keys of the PID or device-bound attestation.;
AS-WP-34-004;Actor-Specific Requirements;Wallet Providers;Topic 34 - Migrate to a different Wallet Solution;34;Migrate to a different Wallet Solution;A. Back-up requirements;Mig_03a;For each non-device bound attestation that is issued to it, a Wallet Unit SHALL add to the Migration Object one of the following: either all data necessary to request issuance of that attestation once again, as listed in Mig_03, or all data necessary to transfer the attestation to a new device without involvement of the Attestation Provider, including attribute identifiers and attribute values. The Wallet Unit SHALL enable the User to indicate if they want to store attribute identifiers and values in the Migration Object.;
AS-WP-34-005;Actor-Specific Requirements;Wallet Providers;Topic 34 - Migrate to a different Wallet Solution;34;Migrate to a different Wallet Solution;A. Back-up requirements;Mig_03b;If the User deletes a PID or attestation from their Wallet Unit, the Wallet Unit SHALL delete the corresponding entry from the Migration Object.;
AS-WP-34-006;Actor-Specific Requirements;Wallet Providers;Topic 34 - Migrate to a different Wallet Solution;34;Migrate to a different Wallet Solution;A. Back-up requirements;Mig_04;The Wallet Unit SHALL store the Migration Object in an external storage or remote storage location of the User's choice, from among the storage options supported by the Wallet Unit, in such a way that the User can still retrieve the object from a new Wallet Unit in case the existing Wallet Unit becomes unavailable.;a) It is up to the Wallet Provider to decide which external storage options or remote storage locations the Wallet Unit supports for storing the Migration Object. b) The new Wallet Unit may be either an instance of the same Wallet Solution as the old one, or an instance of a different Wallet Solution.
AS-WP-34-007;Actor-Specific Requirements;Wallet Providers;Topic 34 - Migrate to a different Wallet Solution;34;Migrate to a different Wallet Solution;A. Back-up requirements;Mig_05;The Wallet Unit SHALL store the Migration Object in such a way that its confidentiality, integrity, and authenticity is protected and that it is protected against use by others than the User.;This could be done, for example, by using password-based cryptography to encrypt the object.
AS-WP-34-008;Actor-Specific Requirements;Wallet Providers;Topic 34 - Migrate to a different Wallet Solution;34;Migrate to a different Wallet Solution;B. Restore Requirements;Mig_06;Directly after installation of a new Wallet Instance, the Wallet Instance SHALL enable the User to import a Migration Object from an external storage or remote storage location indicated by the User, from among the storage options supported by the Wallet Unit.;
AS-WP-34-009;Actor-Specific Requirements;Wallet Providers;Topic 34 - Migrate to a different Wallet Solution;34;Migrate to a different Wallet Solution;B. Restore Requirements;Mig_07;When importing a Migration Object, for each PID and device-bound attestation listed in the Migration Object, the Wallet Unit SHALL enable the User to select that PID or attestation. When a PID or device-bound attestation is selected, the Wallet Unit SHALL request the respective PID Provider or Attestation Provider to re-issue that PID or attestation. If the User selects a PID, the PID SHALL be the first to be restored.;
AS-WP-34-010;Actor-Specific Requirements;Wallet Providers;Topic 34 - Migrate to a different Wallet Solution;34;Migrate to a different Wallet Solution;B. Restore Requirements;Mig_07a;When importing a Migration Object, for each non device-bound attestation listed in the Migration Object, the Wallet Unit SHALL enable the User to select that attestation. When an attestation is selected, the Wallet Unit SHALL, depending on whether the Migration Object contains attribute identifiers and attribute values (see Mig_03a), either restore the attestation or request the respective Attestation Provider to re-issue it.;
AS-WP-34-011;Actor-Specific Requirements;Wallet Providers;Topic 34 - Migrate to a different Wallet Solution;34;Migrate to a different Wallet Solution;B. Restore Requirements;Mig_07b;When importing a Migration Object, the Wallet Unit SHALL ask the User whether they want to restore the log from the Migration Object. When the User agrees, the Wallet Unit SHALL restore the log, and SHALL append future transactions to this log according to the requirements in [Topic 19](./annex-2.02-high-level-requirements-by-topic.md#a2312-topic-19---user-navigation-requirements-dashboard-logs-for-transparency).;
AS-WP-34-012;Actor-Specific Requirements;Wallet Providers;Topic 34 - Migrate to a different Wallet Solution;34;Migrate to a different Wallet Solution;B. Restore Requirements;Mig_08;Empty;
AS-WP-34-013;Actor-Specific Requirements;Wallet Providers;Topic 34 - Migrate to a different Wallet Solution;34;Migrate to a different Wallet Solution;B. Restore Requirements;Mig_09;Empty;
AS-WP-34-014;Actor-Specific Requirements;Wallet Providers;Topic 34 - Migrate to a different Wallet Solution;34;Migrate to a different Wallet Solution;B. Restore Requirements;Mig_10;Empty;
AS-WP-34-015;Actor-Specific Requirements;Wallet Providers;Topic 34 - Migrate to a different Wallet Solution;34;Migrate to a different Wallet Solution;B. Restore Requirements;Mig_11;The processes and interfaces used for issuance of a PID or attestation as part of a migration process SHALL be the same as those used for a 'normal' issuance process, as specified in [Topic 10](./annex-2.02-high-level-requirements-by-topic.md#a237-topic-10---issuing-a-pid-or-attestation-to-a-wallet-unit).;
AS-WP-34-016;Actor-Specific Requirements;Wallet Providers;Topic 34 - Migrate to a different Wallet Solution;34;Migrate to a different Wallet Solution;B. Restore Requirements;Mig_12;Empty;
AS-WP-34-017;Actor-Specific Requirements;Wallet Providers;Topic 34 - Migrate to a different Wallet Solution;34;Migrate to a different Wallet Solution;B. Restore Requirements;Mig_13;Empty;
AS-WP-34-018;Actor-Specific Requirements;Wallet Providers;Topic 34 - Migrate to a different Wallet Solution;34;Migrate to a different Wallet Solution;B. Restore Requirements;Mig_14;Empty;
AS-WP-34-019;Actor-Specific Requirements;Wallet Providers;Topic 34 - Migrate to a different Wallet Solution;34;Migrate to a different Wallet Solution;B. Restore Requirements;Mig_15;Empty;
AS-WP-34-020;Actor-Specific Requirements;Wallet Providers;Topic 34 - Migrate to a different Wallet Solution;34;Migrate to a different Wallet Solution;B. Restore Requirements;Mig_16;Empty;
AS-WP-38-001;Actor-Specific Requirements;Wallet Providers;Topic 38 - Wallet Unit revocation;38;Wallet Unit revocation;A. Issuing a Wallet Unit Attestation;WURevocation_01;To enable a PID Provider or an Attestation Provider to verify the authenticity and the revocation status of a Wallet Unit it is interacting with, a Wallet Provider SHALL issue one or more Wallet Unit Attestations to the Wallet Unit, as specified in Topic 9.;The first of these WUAs will be issued during the activation phase of a Wallet Unit. During the lifetime of the Wallet Unit, the Wallet Provider will re-issue WUAs as needed.
AS-WP-38-002;Actor-Specific Requirements;Wallet Providers;Topic 38 - Wallet Unit revocation;38;Wallet Unit revocation;A. Issuing a Wallet Unit Attestation;WURevocation_02;During the lifetime of the Wallet Unit, the Wallet Provider SHALL ensure that the Wallet Unit at all times is in possession of at least one valid WUA.;
EW-DM-38-001;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 38 - Wallet Unit revocation;38;Wallet Unit revocation;A. Issuing a Wallet Unit Attestation;WURevocation_03;Empty;
EW-DM-38-002;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 38 - Wallet Unit revocation;38;Wallet Unit revocation;A. Issuing a Wallet Unit Attestation;WURevocation_04;Empty;
EW-DM-38-003;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 38 - Wallet Unit revocation;38;Wallet Unit revocation;A. Issuing a Wallet Unit Attestation;WURevocation_05;Empty;
EW-DM-38-004;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 38 - Wallet Unit revocation;38;Wallet Unit revocation;A. Revoking a Wallet Unit;WURevocation_06;Empty;
AS-WP-38-003;Actor-Specific Requirements;Wallet Providers;Topic 38 - Wallet Unit revocation;38;Wallet Unit revocation;A. Revoking a Wallet Unit;WURevocation_07;A Wallet Provider SHALL be able to revoke a Wallet Unit by revoking its WUA(s), as specified in [[Topic 7](./annex-2.02-high-level-requirements-by-topic.md#a235-topic-7---attestation-revocation-and-revocation-checking)].*;
EW-DM-38-005;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 38 - Wallet Unit revocation;38;Wallet Unit revocation;A. Revoking a Wallet Unit;WURevocation_08;Empty;
AS-WP-38-004;Actor-Specific Requirements;Wallet Providers;Topic 38 - Wallet Unit revocation;38;Wallet Unit revocation;A. Revoking a Wallet Unit;WURevocation_09;During the lifetime of a Wallet Unit, the Wallet Provider SHALL regularly verify that the security of the Wallet Unit is not breached or compromised. If the Wallet Provider detects a security breach or compromise, the Wallet Provider SHALL analyse its cause(s) and impact(s). If the breach or compromise affects the trustworthiness or reliability of the Wallet Unit, the Wallet Provider SHALL administratively revoke or suspend the Wallet Unit and SHALL immediately revoke the corresponding WUA(s). The Wallet Provider SHALL do so at least in the following circumstances: - If the security of the Wallet Unit, or the security of the mobile device and OS on which the corresponding Wallet Instance is installed, or the security of the WSCA/WSCD or a keystore it uses for managing cryptographic assets, is breached or compromised in a manner that affects its trustworthiness or reliability. - If the security of the Wallet Solution is breached or compromised in a manner that affects the trustworthiness or reliability of all corresponding Wallet Units. - If the security of the common authentication and data protection mechanisms used by the Wallet Unit is breached or compromised in a manner that affects their trustworthiness or reliability. - If the security of the electronic identification scheme under which the Wallet Unit is provided is breached or compromised in a manner that affects its trustworthiness or reliability.;
AS-WP-38-005;Actor-Specific Requirements;Wallet Providers;Topic 38 - Wallet Unit revocation;38;Wallet Unit revocation;A. Revoking a Wallet Unit;WURevocation_9b;If within three months from an administrative suspension of a Wallet Unit the security breach or compromise is remedied, the Wallet Provider SHALL issue one or more WUAs to the Wallet Unit, such that the User can again use it.;
AS-WP-38-006;Actor-Specific Requirements;Wallet Providers;Topic 38 - Wallet Unit revocation;38;Wallet Unit revocation;A. Revoking a Wallet Unit;WURevocation_10;A Wallet Provider SHALL revoke a Wallet Unit upon the explicit request of the User registered during the Wallet Unit activation process, see [Topic 40](./annex-2.02-high-level-requirements-by-topic.md#a2323-topic-40---wallet-instance-installation-and-wallet-unit-activation-and-management). To do so, the Wallet Provider SHALL revoke all valid WUA(s) for that Wallet Unit. The Wallet Provider SHALL authenticate the User before accepting a request to revoke the Wallet Unit.;
AS-WP-38-007;Actor-Specific Requirements;Wallet Providers;Topic 38 - Wallet Unit revocation;38;Wallet Unit revocation;A. Revoking a Wallet Unit;WURevocation_11;A Wallet Provider SHALL revoke a Wallet Unit upon the explicit request of a PID Provider, in case the natural person using the Wallet Unit has died or the legal person using the Wallet Unit has ceased operations. To do so, the Wallet Provider SHALL revoke all valid WUA(s) for that Wallet Unit. To identify the Wallet Unit that is to be revoked, the PID Provider SHALL use a Wallet Unit identifier provided by the Wallet Provider in the WUA during PID issuance.;See the notes to WUA_08.
AS-WP-38-008;Actor-Specific Requirements;Wallet Providers;Topic 38 - Wallet Unit revocation;38;Wallet Unit revocation;A. Revoking a Wallet Unit;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 Trusted List of PID Providers.;
AS-WP-38-009;Actor-Specific Requirements;Wallet Providers;Topic 38 - Wallet Unit revocation;38;Wallet Unit revocation;A. Revoking a Wallet Unit;WURevocation_13;Before requesting a Wallet Provider to revoke a Wallet Unit per WURevocation_11, the PID Provider SHALL ensure that the revocation does not harm the interests of any of the stakeholders. The PID Provider SHALL have (and follow) a documented policy to ensure that this is the case.;
AS-WP-38-010;Actor-Specific Requirements;Wallet Providers;Topic 38 - Wallet Unit revocation;38;Wallet Unit revocation;B. Informing the User;WURevocation_14;A Wallet Provider SHALL inform a User without delay, and within 24 hours at most, in case the Wallet Provider decided to revoke the User's Wallet Unit. The Wallet Provider SHALL also inform the User about the reason(s) for the revocation. This information SHALL be understandable for the general public. It SHALL include (a reference to) technical details about any security breach if applicable.;
EW-DM-38-006;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 38 - Wallet Unit revocation;38;Wallet Unit revocation;B. Informing the User;WURevocation_15;Empty;
AS-WP-38-011;Actor-Specific Requirements;Wallet Providers;Topic 38 - Wallet Unit revocation;38;Wallet Unit revocation;B. Informing the User;WURevocation_16;To inform a User about the revocation of their Wallet Unit, the Wallet Provider SHALL use a communication channel that is independent of the Wallet Unit. In addition, the Wallet Provider MAY use the Wallet Unit itself to inform the User.;
EW-DM-38-007;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 38 - Wallet Unit revocation;38;Wallet Unit revocation;C. Verifying the revocation status of a Wallet Unit;WURevocation_17;Empty;
AS-WP-38-012;Actor-Specific Requirements;Wallet Providers;Topic 38 - Wallet Unit revocation;38;Wallet Unit revocation;C. Verifying the revocation status of a Wallet Unit;WURevocation_18;A PID Provider issuing revocable PIDs SHALL, for each of its valid PIDs, regularly verify whether the Wallet Provider revoked the Wallet Unit on which that PID is residing, using the revocation information in the WUA it received during issuance of that PID. If it turns out that the Wallet Unit is revoked, the PID Provider SHALL immediately revoke the respective PID in accordance with all requirements in [[Topic 7](./annex-2.02-high-level-requirements-by-topic.md#a235-topic-7---attestation-revocation-and-revocation-checking)].;a) This is a consequence of the legal requirement in [CIR 2024/2977], Article 5, 4.(b). b) See [Technical Specification 3](../../technical-specifications/ts3-wallet-unit-attestation.md) for how the PID Provider can do this verification. c) The reverse is not true: When a PID is revoked, this does not imply that the Wallet Unit on which it is residing should also be revoked. Instead, the Wallet Unit moves to the Operational state. See [ARF main document Section 4.6.3](../../architecture-and-reference-framework-main.md#463-wallet-unit).
AS-WP-38-013;Actor-Specific Requirements;Wallet Providers;Topic 38 - Wallet Unit revocation;38;Wallet Unit revocation;C. Verifying the revocation status of a Wallet Unit;WURevocation_19;An Attestation Provider issuing revocable attestations MAY decide to revoke an attestation if the Wallet Provider revoked the Wallet Unit on which that attestation is residing, in the same manner as described in WURevocation_18. An Attestation Provider SHALL publish its policy in this regard.;Publishing its policy regarding revocation allows a Relying Party to decide if it can put sufficient trust in the attestations issued by that Attestation Provider.
EW-DM-38-008;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 38 - Wallet Unit revocation;38;Wallet Unit revocation;C. Verifying the revocation status of a Wallet Unit;WURevocation_19a;Empty;
EW-DM-38-009;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 38 - Wallet Unit revocation;38;Wallet Unit revocation;C. Verifying the revocation status of a Wallet Unit;WURevocation_19b;Empty;
EW-DM-38-010;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 38 - Wallet Unit revocation;38;Wallet Unit revocation;C. Verifying the revocation status of a Wallet Unit;WURevocation_20;Empty;
EW-DM-38-011;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 38 - Wallet Unit revocation;38;Wallet Unit revocation;C. Verifying the revocation status of a Wallet Unit;WURevocation_21;Empty;
AS-WP-40-001;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;A. HLRs for Wallet Instance installation;WIAM_01;To ensure that the User can trust the Wallet Solution, a Wallet Provider SHOULD make its certified Wallet Solution available for installation only via the official app store of the relevant operating system (e.g., Android, iOS).;This allows the operating system of the device to perform relevant checks regarding the authenticity of the Wallet Unit.
AS-WP-40-002;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;A. HLRs for Wallet Instance installation;WIAM_02;If a Wallet Provider makes its certified Wallet Solution available for installation through other means than the official OS app store, it SHALL implement a mechanism allowing the User to verify the authenticity of the Wallet Unit. Moreover, it SHALL provide clear instructions to the User on how to install the Wallet Instance, including at least: - instructions on the verification of the authenticity of the Wallet Instance to be installed, - instructions on bypassing of any operating system limitations on side-loading of apps, if applicable, and ensuring that these limitations are restored after the Wallet Instance has been installed.;This requirement also applies for the installation of a Wallet Instance on a User device that is not a mobile device, and for which no official operating system app store may exist.
AS-WP-40-003;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;B. HLRs for Wallet Unit activation;WIAM_03;A Wallet Provider SHALL ensure that a Wallet Instance starts a process to activate the new Wallet Unit with the Wallet Provider immediately after installation or when the User first opens the Wallet Instance. The Wallet Provider SHALL ensure that the Wallet Instance starts this process only with a secure backend of the Wallet Provider.;
AS-WP-40-004;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;B. HLRs for Wallet Unit activation;WIAM_04;During the activation process of a new Wallet Unit, the Wallet Provider SHALL verify that the new Wallet Instance is a genuine instance of its Wallet Solution.;
AS-WP-40-005;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;B. HLRs for Wallet Unit activation;WIAM_05;During the activation process of a new Wallet Unit, the Wallet Provider SHALL process information about the User device and the available WSCA/WSCD and keystore(s), as far as necessary to issue a Wallet Unit Attestation to the Wallet Unit conform all requirements in [Topic 9](./annex-2.02-high-level-requirements-by-topic.md#a236-topic-9---wallet-unit-attestation) section A. The Wallet Provider MAY process additional information necessary for managing the Wallet Unit, but it SHALL NOT process more information than it reasonably needs for legitimate purposes. The Wallet Provider SHALL request User consent (through the Wallet Instance) for all information and data it will process, both during activation and throughout the lifetime of the Wallet Unit. The Wallet Provider SHALL inform the User about the purposes of data processing, in accordance with the General Data Protection Regulation.;
AS-WP-40-006;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;B. HLRs for Wallet Unit activation;WIAM_06;The Wallet Provider SHALL request the User, through the new Wallet Instance, to set up a User account at the Wallet Provider. The Wallet Provider SHALL explain to the User that this is necessary to enable the User to request revocation of the Wallet Unit in case of theft or loss. The Wallet Provider SHALL register one or more User authentication methods that the Wallet Provider will use to authenticate the User in the future. These methods SHALL be independent of the Wallet Unit and the User device. The Wallet Provider SHALL allow the User to register using an alias instead of true identity data. The Wallet Provider SHALL NOT use any registered User data for purposes other than User authentication, unless the User gives explicit consent to do so. The Wallet Provider SHALL register the relationship between the Wallet Unit and the corresponding User account.;
AS-WP-40-007;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;B. HLRs for Wallet Unit activation;WIAM_07;A Wallet Provider SHALL activate a new Wallet Unit before a User can use it to have issued an PID or attestation.;The WUA is issued as part of the activation.
AS-WP-40-008;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;B. HLRs for Wallet Unit activation;WIAM_08;A Wallet Provider SHALL only activate a new Wallet Unit if it has verified that: - The Wallet Unit includes a WSCA/WSCD that is certified to be compliant with applicable requirements in this Topic. In addition, the Wallet Unit MAY include one or more keystores. - The private key corresponding to the public key in the WUA (see WUA_09) is protected by the respective WSCA/WSCD under control of the User. ;A WSCA/WSCD by definition complies with requirements for Level of Assurance High, see WIAM_14.
AS-WP-40-009;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;B. HLRs for Wallet Unit activation;WIAM_09;If a WSCA/WSCD contains cryptographic assets related to multiple Wallet Units, the Wallet Provider SHALL ensure that a Wallet Unit can only access keys that are related to that Wallet Unit. ;
AS-WP-40-010;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;B. HLRs for Wallet Unit activation;WIAM_10;During the activation process of a new Wallet Unit, a Wallet Provider SHALL create and sign at least one Wallet Unit Attestation, and issue them to the Wallet Unit.;
AS-WP-40-011;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;B. HLRs for Wallet Unit activation;WIAM_10a;During the activation process of a new Wallet Unit, the Wallet Provider SHALL offer the User a means to verify the formal certification information of their Wallet Solution.;
AS-WP-40-012;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;C. HLRs for Wallet Unit management;WIAM_11;During the lifetime of the Wallet Unit, the Wallet Provider SHALL update the Wallet Unit as necessary to ensure its continued security and functionality. ;
AS-WP-40-013;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;C. HLRs for Wallet Unit management;WIAM_12;All communication between the Wallet Provider and the Wallet Unit SHALL be mutually authenticated and SHOULD be encrypted.;
AS-WP-40-014;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;C. HLRs for Wallet Unit management;WIAM_12a;The Wallet Unit SHALL ensure that the Wallet Provider cannot access the contents of the Wallet Unit, in particular to learn a) which attestations are present on the Wallet Unit, b) the status of these attestations, c) the value of attributes in these attestations, and d) the contents of the Wallet Unit log meant in DASH_02.;
AS-WP-40-015;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;C. HLRs for Wallet Unit management;WIAM_13;If the User uninstalls the Wallet Unit, the Wallet Unit SHALL ensure that all cryptographic assets related to the Wallet Unit in the WSCA/WSCD and the keystore(s) is securely destroyed. This includes all keys of the WUAs, PIDs and device-bound attestations stored in the Wallet Unit.;Deletion of PID or WUA cryptographic assets User authentication, as specified in requirement WIAM_14.
AS-WP-40-016;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;C. HLRs for Wallet Unit management;WIAM_13a;If a Wallet Unit supports the [W3C Digital Credentials API] and the User uninstalls the Wallet Unit, the Wallet Unit SHALL disclose the fact that it  no longer stores any previously disclosed PID(s) or attestation(s) to the Digital Credentials API framework.;
AS-WP-40-017;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;C. HLRs for Wallet Unit management;WIAM_14;A WSCA/WSCD managing the critical assets of a PID, such as private or secret cryptographic keys, SHALL authenticate the User before performing any cryptographic operation involving any of these assets.;a) [CIR 2024/2981], Annex IV, section 2 (3) states As a prerequisite to the certification under national certification schemes, the WSCD shall be assessed against the requirements of assurance level high as set out in Implementing Regulation (EU) 2015/1502. Therefore, a WSCA/WSCD by legal definition complies with requirements of LoA High. b) Note to WIAM_14 - WIAM_14b: Many actions of the Wallet Unit, such as processing a Relying Party presentation request and presenting an attestation, require multiple cryptographic operations, for example ephemeral key generation followed by key agreement and presentation signing and encryption. These requirements does not imply that a separate User authentication is necessary before each of these operations. Rather, a successful User authentication will be valid for all cryptographic operations necessary for a Wallet Unit action. It is up to the Wallet Provider to determine what constitutes a 'Wallet Unit action', finding a balance between security (more User authentications) and User convenience (fewer User authentications). During certification of the Wallet Solution, it will be verified that the solution provides an adequate level of security.
AS-WP-40-018;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;C. HLRs for Wallet Unit management;WIAM_14a;A WSCA/WSCD managing the critical assets of a WUA SHALL authenticate the User before performing any cryptographic operation involving any of these keys. ;Since the WUA authenticates the Wallet Unit towards the PID Provider during PID issuance, WUAs must be managed at LoA High, and consequently WUA keys must be managed in the WSCA/WSCD.
AS-WP-40-019;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;C. HLRs for Wallet Unit management;WIAM_14b; 	A WSCA/WSCD managing the cryptographic assets of an attestation having a level of security High SHALL authenticate the User before performing any cryptographic operation involving any of these keys. ;a) The term 'Level of Assurance', as used in the European Digital Identity Regulation and in Implementing Regulation (EU) 2015/1502, is only applicable to electronic identity means, which in the context of the EUDI Wallet means only the PID. For that reason, this requirement uses the term 'level of security'. b) During issuance of an attestation, the Attestation Provider in its Credential Issuer metadata indicates the level of security it requires for the key storage and user authentication for this type of attestation; see [OpenID4VCI] section 12.2.4 and Appendix D.2.
AS-WP-40-020;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;C. HLRs for Wallet Unit management;WIAM_14c;A Wallet Unit SHALL use a key store to manage any cryptographic assets that are not considered to be critical assets.;a) The ARF uses the term 'key store' to refer to a hardware-backed repository and service in which non-critical cryptographic assets are generated, stored, and used exclusively inside a dedicated hardware security boundary. b) Examples of non-critical cryptographic assets are private and secret keys of attestations having a level of security lower than High. c) As mentioned in WIAM_14 and WIAM_14b, the private and secret keys of PIDs and WUAs are critical assets and therefore are stored in a WSCA/WSCD.
AS-WP-40-021;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;C. HLRs for Wallet Unit management;WIAM_15;Before performing any operation, a Wallet Instance SHALL securely authenticate the User using a multi-factor authentication mechanism provided by the User device. ;One of the authentication factors is the possession of the User device.
AS-WP-40-022;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;C. HLRs for Wallet Unit management;WIAM_15a;For the purpose of WIAM_15, the Wallet Instance SHALL enforce the activation of an OS-level User authentication mechanism with adequate security policies. ;'Adequate' here means adequate for any operation excluding the issuance or presentation of PIDs, WUAs, and potentially other attestations at level of security High. This includes but is not limited to generating pseudonyms, accessing the transaction log (dashboard), data export and migration, requesting the erasure of personal data by a Relying Party, and reporting a Relying Party to a DPA.
AS-WP-40-023;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;C. HLRs for Wallet Unit management;WIAM_15b;The Wallet Instance SHALL enable the User to optionally use a Wallet Instance-specific PIN for User authentication, in addition to the User authentication mechanism provided by the User device.;
AS-WP-40-024;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;C. HLRs for Wallet Unit management;WIAM_15c;The Wallet Instance SHALL also use the User authentication mechanism provided by the User device to unlock the keystore mentioned in WIAM_14c, where applicable.;
AS-WP-40-025;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;C. HLRs for Wallet Unit management;WIAM_16; For the User authentication mechanism provided by the User device, the Wallet Instance SHALL force the User device to enable a time-based control (e.g., a session timeout or re-authentication interval), to ensure that access is automatically revoked after a defined period of inactivity.;
AS-WP-40-026;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;C. HLRs for Wallet Unit management;WIAM_17;A WSCA/WSCD SHALL be able to authenticate a User in accordance with the requirements in [Commission Implementing Regulation (EU) 2015/1502](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32015R1502) section 2.2.1.;
AS-WP-40-027;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;C. HLRs for Wallet Unit management;WIAM_18;Empty;
AS-WP-40-028;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;C. HLRs for Wallet Unit management;WIAM_19;A WSCA/WSCD and a keystore SHALL be able to prove possession of the private key corresponding to a public key on request of a Wallet Instance, for example by signing a challenge with that private key.;
AS-WP-40-029;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;C. HLRs for Wallet Unit management;WIAM_20;A WSCA/WSCD SHALL protect a private key it generated during the entire lifetime of the key. This protection SHALL at least imply that the WSCA/WSCD prevents the private key from being extracted in the clear. If a WSCA/WSCD is able to export a private key in encrypted format, the resulting level of protection SHALL be equivalent to the protection level of the private key when stored in the WSCA.;
AS-WP-40-030;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;C. HLRs for Wallet Unit management;WIAM_21;Whenever the WSCA/WSCD successfully authenticated the User, the Wallet Unit SHOULD check if the WSCD contains cryptographic assets for PIDs or attestations that cannot be presented any longer to Relying Parties, for example because they have expired or because a once-only attestation (see [Topic 10](./annex-2.02-high-level-requirements-by-topic.md#a237-topic-10---issuing-a-pid-or-attestation-to-a-wallet-unit), section D, method A) was presented to a Relying Party already. The Wallet Unit SHOULD then request the WSCA/WSCD to destroy all cryptographic assets related to these PIDs or attestations.;The reason for this recommendation is that probably, Wallet Providers will want to prevent an accumulation of unused private keys in the WSCA/WSCD, given that such devices typically do not have much storage space. However, deletion of private keys (and potentially other cryptographic assets) is a cryptographic key operation and cannot be done without User authentication; see WIAM_14. At the same time, for usability reasons the User must not be involved in such 'cleaning up' processes, see also ISSU_42. The recommended solution is to take advantage of a User authentication event to also carry out any necessary cleaning operations.
AS-AP-42-001;Actor-Specific Requirements;Attestation & PID Providers;Topic 42 - Requirements for QTSPs to access Authentic Sources;42;Requirements for QTSPs to access Authentic Sources;;QTSPAS_01;In accordance with technical specifications referred to in QTSPAS_07, Member States SHALL define: - discovery mechanisms that enable QTSPs to request information about Authentic Sources or designated intermediaries recognised at the national level. This includes information regarding the attributes of a natural or legal person for which the Authentic Source or designated intermediary is considered a primary source, or for which it is recognised as authentic in accordance with Union law or national law, including administrative practices. - procedures for QTSPs to request the verification of attributes from Authentic Sources.;
AS-AP-42-002;Actor-Specific Requirements;Attestation & PID Providers;Topic 42 - Requirements for QTSPs to access Authentic Sources;42;Requirements for QTSPs to access Authentic Sources;;QTSPAS_02;An Authentic Source in the public sector, or its designated intermediary, SHALL implement an interface complying with the technical specification mentioned in QTSPAS_07 for receiving verification requests and sending responses. For each received request, the Authentic Source SHALL - identify and authenticate the requestor in such a way that it can subsequently determine whether the requestor is a QTSP issuing qualified electronic attestation of attributes, for example by means of a lookup in the QTSP Trusted List. - authenticate the User and obtain their approval, if it is legally obliged to do so, in addition to the User authentication and approval already performed by the QTSP according to QTSPAS_08. - verify whether the attribute values claimed by the QTSP match the values held by the Authentic Source; and, finally, - respond with one of the following for each attribute: +'match', if the attribute value held for this User by the Authentic Source is identical to the value claimed by the QTSP, + 'no match', if the attribute value held for this User by the Authentic Source is not identical to the value claimed by the QTSP, including if the Authentic Source is the authentic source for this attribute but does not hold a value for this User, +'unknown', if the Authentic Source is not the authentic source for this attribute.;
AS-AP-42-003;Actor-Specific Requirements;Attestation & PID Providers;Topic 42 - Requirements for QTSPs to access Authentic Sources;42;Requirements for QTSPs to access Authentic Sources;;QTSPAS_03;An Authentic Source or designated intermediary SHALL respond to a verification request for attributes by any QTSP issuing qualified electronic attestation of attributes.;
AS-AP-42-004;Actor-Specific Requirements;Attestation & PID Providers;Topic 42 - Requirements for QTSPs to access Authentic Sources;42;Requirements for QTSPs to access Authentic Sources;;QTSPAS_04;An Authentic Source or designated intermediary SHALL implement the technical specifications mentioned in QTSPAS_01, so that the QTSP will receive the result of the verification of the requested attributes as described in QTSPAS_02. If the verification is deferred, the response to the QTSP SHALL include the maximum time that it will take to verify the requested attributes, and a unique identifier that the QTSP SHALL use to obtain the result of the verification.;
AS-AP-42-005;Actor-Specific Requirements;Attestation & PID Providers;Topic 42 - Requirements for QTSPs to access Authentic Sources;42;Requirements for QTSPs to access Authentic Sources;;QTSPAS_05;A QTSP SHALL send an attribute verification request directly to the Authentic Source or designated intermediary recognised at national level, after discovering it using the mechanisms mentioned in QTSPAS_01.;
AS-AP-42-006;Actor-Specific Requirements;Attestation & PID Providers;Topic 42 - Requirements for QTSPs to access Authentic Sources;42;Requirements for QTSPs to access Authentic Sources;;QTSPAS_06;Member States SHALL specify the processes and mechanisms to designate the Authentic Sources or intermediaries recognised at national level in accordance with Union or national law, allowing these Authentic Sources or intermediaries to verify the attributes presented to them by QTSPs.;
AS-AP-42-007;Actor-Specific Requirements;Attestation & PID Providers;Topic 42 - Requirements for QTSPs to access Authentic Sources;42;Requirements for QTSPs to access Authentic Sources;;QTSPAS_07;The Commission SHALL publish, in cooperation with the European Digital Identity Cooperation Group, a technical specification, referring to applicable standards, specifications and procedures, that will cover at least the attributes specified in Annex VI, wherever those attributes rely on Authentic Sources within the public sector, for which Member States must ensure that measures are taken to allow qualified providers of electronic attestations of attributes to verify by electronic means, at the request of the User, their authenticity against the relevant authentic source.;
AS-AP-42-008;Actor-Specific Requirements;Attestation & PID Providers;Topic 42 - Requirements for QTSPs to access Authentic Sources;42;Requirements for QTSPs to access Authentic Sources;;QTSPAS_07a;The standards and procedures mentioned in QTSPAS_07 SHOULD, whenever possible, be aligned and compatible with those used for the platforms implementing the Once Only Technical System (OOTS).;There is a clear synergy of both of these data exchange approaches. In fact, the national OOTS node would be a candidate for acting as an intermediary between QTSPs issuing QEAAs and the Authentic Sources.
AS-AP-42-009;Actor-Specific Requirements;Attestation & PID Providers;Topic 42 - Requirements for QTSPs to access Authentic Sources;42;Requirements for QTSPs to access Authentic Sources;;QTSPAS_08;A QTSP SHALL obtain approval from the User to verify the authenticity of the attributes, before requesting the verification of those attributes by the relevant Authentic Source or designated intermediary.;
AS-WP-43-001;Actor-Specific Requirements;Wallet Providers;Topic 43 - Embedded disclosure policies;43;Embedded disclosure policies;;EDP_01;A Wallet Unit SHALL enable an Attestation Provider to optionally express an embedded disclosure policy for a QEAA, PuB-EAA, or non-qualified EAA.;The [European Digital Identity Regulation] does not contain a requirement for PIDs to be able to contain an embedded disclosure policy.
AS-WP-43-002;Actor-Specific Requirements;Wallet Providers;Topic 43 - Embedded disclosure policies;43;Embedded disclosure policies;;EDP_02;A Wallet Unit SHALL support embedded disclosure policies implementing the 'Authorised relying parties only policy' described in Annex III of Implementing Regulation (EU) 2024/2979. If present, such an embedded disclosure policy SHALL contain a list of EU-wide unique identifiers of Relying Parties, as specified in Reg_32. The Wallet Unit SHALL retrieve the Relying Party identifier from the access certificate presented by the Relying Party, and compare it to the list of authorised identifiers in the policy, unless the Relying Party is an intermediary. If the Relying Party is an intermediary, the Wallet Unit SHALL retrieve the unique identifier of the intermediated Relying Party from the presentation request or from the registration certificate of the intermediated Relying Party and compare this identifier to the list of authorised identifiers in the policy.;See RPI_07 for how the Wallet Unit can see if the Relying Party is an intermediary.
AS-WP-43-003;Actor-Specific Requirements;Wallet Providers;Topic 43 - Embedded disclosure policies;43;Embedded disclosure policies;;EDP_03;A Wallet Unit SHALL support embedded disclosure policies implementing the 'Specific root of trust' policy described in Annex III of Implementing Regulation (EU) 2024/2979. If present, such an embedded disclosure policy SHALL contain a list of root or intermediate certificates used for signing Relying Party access certificates. The Wallet Unit SHALL compare the certificate chain that was used to sign the access certificate provided by the Relying Party to the list of authorised root or intermediate certificates in the policy, unless the Relying Party is an intermediary. If the Relying Party is an intermediary, the Wallet Unit SHALL retrieve the root certificate of the Provider of registration certificates of the intermediated Relying Party from the presentation request or from the Registrar's online service (as applicable) and compare this certificate to the list of authorised certificates in the policy.;See RPI_07 for how the Wallet Unit can see if the Relying Party is an intermediary.
EW-DM-43-001;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 43 - Embedded disclosure policies;43;Embedded disclosure policies;;EDP_04;Empty;
AS-WP-43-004;Actor-Specific Requirements;Wallet Providers;Topic 43 - Embedded disclosure policies;43;Embedded disclosure policies;;EDP_05;An embedded disclosure policy SHOULD contain a link to a website of the Attestation Provider explaining the disclosure policy in layman's terms. If this is the case, the Wallet Unit SHALL display the link to the User and allow them to navigate to that website.;
AS-WP-43-005;Actor-Specific Requirements;Wallet Providers;Topic 43 - Embedded disclosure policies;43;Embedded disclosure policies;;EDP_06;The Wallet Unit SHALL evaluate an embedded disclosure policy in conjunction with the information received from the requesting Relying Party, in order to determine if the Relying Party has permission from the Attestation Provider to access the requested attestation.;
AS-WP-43-006;Actor-Specific Requirements;Wallet Providers;Topic 43 - Embedded disclosure policies;43;Embedded disclosure policies;;EDP_07;The Wallet Unit SHALL enable the User, based on the outcome of the evaluation of the applicable embedded disclosure policy(s), to deny or allow the presentation of the requested attestation to the Relying Party.;
AS-WP-43-007;Actor-Specific Requirements;Wallet Providers;Topic 43 - Embedded disclosure policies;43;Embedded disclosure policies;;EDP_08;The Commission SHALL take measures to ensure a technical specification is created establishing common mechanisms for the specification of embedded disclosure policies by Attestation Providers, and for the evaluation of such policies by Wallet Units.;
EW-PIO-43-001;Ecosystem-Wide Rules;Protocols & Interoperability;Topic 43 - Embedded disclosure policies;43;Embedded disclosure policies;;EDP_09;An Attestation Provider SHALL include an embedded disclosure policy (if any) by value in the Issuer metadata related to the attestation, in compliance with the [OpenID4VCI] issuance protocol or an extension thereof specified in the technical specification mentioned in EDP_08.;
AS-WP-43-008;Actor-Specific Requirements;Wallet Providers;Topic 43 - Embedded disclosure policies;43;Embedded disclosure policies;;EDP_10;During attestation issuance, a Wallet Unit SHALL retrieve and store locally the corresponding embedded disclosure policy, if any.;
AS-AP-43-001;Actor-Specific Requirements;Attestation & PID Providers;Topic 43 - Embedded disclosure policies;43;Embedded disclosure policies;;EDP_11;An Attestation Provider SHALL revoke an attestation if a corresponding embedded disclosure policy is added, changed, or deleted.;
EW-DM-44-001;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;A. Generic requirements on the specification and contents of registration certificates;RPRC_01;The Commission SHALL provide a technical specification establishing a common Certificate Policy for registration certificates, covering at least management and selection of signing keys, revocation and lifecycle management of registration certificates on individual intended use level.;The technical specification may require the Provider of registration certificates to follow applicable parts of technical standards such as EN 319 401 (for General Policy Requirements for TSPs) and TS 119 461 (for identity proofing of Relying Party representatives).
EW-DM-44-002;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;A. Generic requirements on the specification and contents of registration certificates;RPRC_02;The Commission SHALL ensure that a technical specification is created, describing at least 1. the contents and format of registration certificates for Relying Parties, see the other requirements in this section below. 2. the signing method(s) used to ensure the authenticity of the registration certificate. 3. the trust infrastructure necessary for signing registration certificates and for verifying these signatures, including the use of Trusted Lists to establish trust in Providers of registration certificates and to distribute their trust anchors to Wallet Units. 4. the method used for binding each registration certificate to the access certificate that will be used in the same presentation request. This binding method SHALL enable a Wallet Unit to verify that the registration certificate is bound to the entity that authenticated itself using the access certificate. The binding method SHALL consider situations in which a Relying Party uses the services of an intermediary (see [Topic 52](./annex-2.02-high-level-requirements-by-topic.md#a2330-topic-52-relying-party-intermediaries)) to connect to the Wallet Unit. 5. whether or not a registration certificate must have a validity period. 6. the method to be used for revocation of registration certificates. Moreover, the technical specification SHALL describe the impact of revocation, especially compared to the impact of revocation of the access certificate(s) of the same entity.;
EW-DM-44-003;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;A. Generic requirements on the specification and contents of registration certificates;RPRC_03;The contents of a registration certificate SHALL include at least the information required in Annex V of the [CIR 2025/848](https://data.europa.eu/eli/reg_impl/2025/848/oj) regarding registration of wallet-relying parties.;
EW-DM-44-004;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;A. Generic requirements on the specification and contents of registration certificates;RPRC_04;If the subject of the registration certificate uses the services of an intermediary (see [Topic 52](./annex-2.02-high-level-requirements-by-topic.md#a2330-topic-52-relying-party-intermediaries)), 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.;This name and identifier are identical to those in the access certificate of the intermediary.
EW-DM-44-005;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;A. Generic requirements on the specification and contents of registration certificates;RPRC_04a;Empty;
EW-DM-44-006;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;A. Generic requirements on the specification and contents of registration certificates;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.;A PID Provider or Attestation Provider may request attributes from the Wallet Unit during issuance. If so, it registers as both a Service Provider and an Attestation Provider, and consequently its registration certificate contains its intended use.
EW-DM-44-007;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;A. Generic requirements on the specification and contents of registration certificates;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.;A Wallet Unit needs the name of a Relying Party at least when requesting User approval according to [[Topic 6](./annex-2.02-high-level-requirements-by-topic.md#a234-topic-6---relying-party-authentication-and-user-approval)]
EW-DM-44-008;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;A. Generic requirements on the specification and contents of registration certificates;RPRC_07;The contents of a registration certificate SHALL include an EU-wide unique identifier for the subject of the certificate.;a) A Wallet Unit needs an identifier for a Relying Party at least to allow the User to send a report of suspicious Relying Party presentation requests to a data protection authority according to [Topic 50](./annex-2.02-high-level-requirements-by-topic.md#a2328-topic-50---blueprint-to-report-unlawful-or-suspicious-request-of-data). b) The EU-wide unique identifier could, for example, be a concatenated list of one or more registered official Relying Party identifiers listed in Annex I(3) of the [CIR 2025/848](https://data.europa.eu/eli/reg_impl/2025/848/oj) regarding registration of Wallet Relying Parties, expressed in the semantic form defined in [ETSI EN 319 412-1] sections 5.1.4 or 5.1.5.
EW-DM-44-009;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;A. Generic requirements on the specification and contents of registration certificates;RPRC_08;The EU-wide unique identifier meant in RPRC_07 SHALL be identical in all registration certificates issued for a given entity.;In case the registration certificates issued to an intermediated Relying Party are held and presented by an intermediary, the entity meant in this requirement is the intermediated Relying Party. An intermediary may obtain and hold registration certificates with a different unique identifier for other intermediated Relying Parties.
EW-DM-44-010;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;B Requirements on the issuance of registration certificates to Relying Parties;RPRC_09;A Member State Registrar MAY decide that, during the registration process for Relying Parties, as specified in [Topic 27](./annex-2.02-high-level-requirements-by-topic.md#a2316-topic-27---registration-of-pid-providers-providers-of-qeaas-pub-eaas-and-non-qualified-eaas-and-relying-parties), 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. ;See also [Topic 52](./annex-2.02-high-level-requirements-by-topic.md#a2330-topic-52-relying-party-intermediaries).
EW-DM-44-011;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;B Requirements on the issuance of registration certificates to Relying Parties;RPRC_10;If, during registration, a Relying Party received one or more registration certificates, it SHALL distribute these to all its Relying Party Instances.;
EW-DM-44-012;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;B Requirements on the issuance of registration certificates to Relying Parties;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.;See [Topic 48](./annex-2.02-high-level-requirements-by-topic.md#a2327-topic-48---blueprint-for-requesting-data-deletion-to-relying-parties) for more information about data deletion requests.
EW-DM-44-013;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;B Requirements on the issuance of registration certificates to Relying Parties;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. c) 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.;See [Topic 50](./annex-2.02-high-level-requirements-by-topic.md#a2328-topic-50---blueprint-to-report-unlawful-or-suspicious-request-of-data) for more information about reporting suspicious attribute presentation requests.
AS-AP-44-001;Actor-Specific Requirements;Attestation & PID Providers;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;C. Requirements on the issuance of registration certificates to PID Providers and Attestation Providers;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](./annex-2.02-high-level-requirements-by-topic.md#a2316-topic-27---registration-of-pid-providers-providers-of-qeaas-pub-eaas-and-non-qualified-eaas-and-relying-parties), 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.;
AS-AP-44-002;Actor-Specific Requirements;Attestation & PID Providers;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;C. Requirements on the issuance of registration certificates to PID Providers and Attestation Providers;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.;A service supply point is a system at which a Wallet Unit can start the process of requesting and obtaining a PID or attestation.
AS-AP-44-003;Actor-Specific Requirements;Attestation & PID Providers;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;C. Requirements on the issuance of registration certificates to PID Providers and Attestation Providers;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.;
EW-DM-44-014;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;D. Requirements on the presentation and verification of registration certificates of Relying Parties;RPRC_16;Either after receiving a presentation request or as a general User setting, a Wallet Unit SHALL offer the User the possibility to indicate whether the User wants to verify the information registered by the competent Registrar about the Relying Party the User is interacting with.;
EW-DM-44-015;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;D. Requirements on the presentation and verification of registration certificates of Relying Parties;RPRC_17;If the User indicated that they want to verify the information registered about the Relying Party and the Relying Party sent a registration certificate to the Wallet Unit, the Wallet Unit SHALL verify the authenticity and validity of the registration certificate according to the technical specification meant in RPRC_02. If the outcome of the verification is negative, 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.;
EW-DM-44-016;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;D. Requirements on the presentation and verification of registration certificates of Relying Parties;RPRC_18;If the User indicated that they want to verify the information registered about the Relying Party, but 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.;The URL of the Registrar is included in the extension of the presentation request, see RPRC_19a.
EW-DM-44-017;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;D. Requirements on the presentation and verification of registration certificates of Relying Parties;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.; This ensures that no external requests are necessary to validate the Relying Party.
EW-DM-44-018;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;D. Requirements on the presentation and verification of registration certificates of Relying Parties;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.;Including items a) and b) enables the Wallet Unit to show to the User the name of the Relying Party. Including c) enables the Wallet Unit to inform the User about the intended use. Including c) and d) enables the Wallet Unit, if desired by the User, to request from the Registrar the attributes registered by the Relying Party for this intended use, as well as the corresponding privacy policy and other registered information. See [Technical Specification 5](../../technical-specifications/ts5-common-formats-and-api-for-rp-registration-information.md) for the definition of this information. Note that in case the Relying Party Instance is operated by an intermediary, items a) - e) pertain to the intermediated Relying Party, see also RPI_06.
EW-DM-44-019;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;D. Requirements on the presentation and verification of registration certificates of Relying Parties;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.;The correct CIR will be referenced here when it is published.
EW-DM-44-020;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;D. Requirements on the presentation and verification of registration certificates of Relying Parties;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.;The correct CIR will be referenced here when it is published.
EW-DM-44-021;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;D. Requirements on the presentation and verification of registration certificates of Relying Parties;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.;
AS-AP-44-004;Actor-Specific Requirements;Attestation & PID Providers;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;E. Requirements on the presentation and verification of registration certificates of PID Providers and Attestation Providers;RPRC_22;If a PID Provider or Attestation Provider received a registration certificate (see RPRC_14), it SHALL include the registration certificate in its Issuer metadata used in the common OpenID4VCI protocol referenced in ISSU_01. The registration certificate SHALL be included in the metadata by value, not by reference.;a) This ensures that no external requests are necessary to validate the PID Provider or Attestation Provider, and that issuance transactions are atomic and self-contained. b) See also ISSU_22 - ISSU_22b and ISSU_32 - ISSU_32b.
AS-AP-44-005;Actor-Specific Requirements;Attestation & PID Providers;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;E. Requirements on the presentation and verification of registration certificates of PID Providers and Attestation Providers;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.;Unlike for Relying Parties, see RPRC_21, the Wallet Unit always carries out this verification, regardless of the preference of the User set as per RPRC_16.
AS-WP-48-001;Actor-Specific Requirements;Wallet Providers;Topic 48 - Blueprint for requesting data deletion to Relying Parties;48;Blueprint for requesting data deletion to Relying Parties;;DATA_DLT_01;A Wallet Provider SHALL ensure that its Wallet Units support the possibilities mentioned in DATA_DLT_02, allowing a User to request from a Relying Party the erasure of their attributes that were presented by that Wallet Unit to that Relying Party, in accordance with Article 17 of Regulation (EU) 2016/679.;
AS-RP-48-001;Actor-Specific Requirements;Relying Parties;Topic 48 - Blueprint for requesting data deletion to Relying Parties;48;Blueprint for requesting data deletion to Relying Parties;;DATA_DLT_02;A Wallet Unit SHALL support at least the following possibilities to send a data erasure request to a Relying Party: a) Open a URL in an external browser to ask for the deletion of data in a web form provided by the Relying Party, b) Open an external mail client and start a draft e-mail to the Relying Party, with a suitable template text, c) open an external phone client and start a phone call. Depending on whether a Relying Party URL, e-mail address, and/or phone number was logged for the relevant attestation presentation transaction (see requirement DASH_03 in [Topic 19](./annex-2.02-high-level-requirements-by-topic.md#a2312-topic-19---user-navigation-requirements-dashboard-logs-for-transparency)), the Wallet Unit SHALL offer the User to use one or more of these possibilities.;
AS-RP-48-002;Actor-Specific Requirements;Relying Parties;Topic 48 - Blueprint for requesting data deletion to Relying Parties;48;Blueprint for requesting data deletion to Relying Parties;;DATA_DLT_02a;If the User initiates sending a data erasure request for a particular attestation presentation transaction, but no Relying Party URL, e-mail address, or telephone number is available in the log for that transaction, the Wallet Unit SHALL connect to the URL of the online service of the Registrar indicated in the log to obtain this information. The Wallet Unit SHALL inform the User that it must connect to the Registrar to look up the contact information it needs to send a data deletion request.;This situation may occur if there was no registration certificate in the presentation request and the User did not request the Wallet Unit to obtain the information registered about the Relying Party from the Registrar. See RPRC_16 - RPRC_18 in [Topic 44](./annex-2.02-high-level-requirements-by-topic.md#a2326-topic-44---registration-certificates-for-pid-providers-providers-of-qeaas-pub-eaas-and-non-qualified-eaas-and-relying-parties).
AS-RP-48-003;Actor-Specific Requirements;Relying Parties;Topic 48 - Blueprint for requesting data deletion to Relying Parties;48;Blueprint for requesting data deletion to Relying Parties;;DATA_DLT_03;A Wallet Instance SHALL provide a function where the User may select one Relying Party to which a data deletion request must be submitted.;
AS-WP-48-002;Actor-Specific Requirements;Wallet Providers;Topic 48 - Blueprint for requesting data deletion to Relying Parties;48;Blueprint for requesting data deletion to Relying Parties;;DATA_DLT_04;Empty;
AS-WP-48-003;Actor-Specific Requirements;Wallet Providers;Topic 48 - Blueprint for requesting data deletion to Relying Parties;48;Blueprint for requesting data deletion to Relying Parties;;DATA_DLT_05;A Wallet Unit SHALL include the initiation of a data deletion request in a log, so it can be displayed to the User via the dashboard as specified in [Topic 19](./annex-2.02-high-level-requirements-by-topic.md#a2312-topic-19---user-navigation-requirements-dashboard-logs-for-transparency).;Because the request is sent by an external web browser, e-mail client, or phone client (see DATA_DLT_02), the Wallet Unit can only log the initiation of the request.
AS-RP-48-004;Actor-Specific Requirements;Relying Parties;Topic 48 - Blueprint for requesting data deletion to Relying Parties;48;Blueprint for requesting data deletion to Relying Parties;;DATA_DLT_06;For the initiation of a data deletion request, the log SHALL contain at least: - Date and time of the initiation of the request, - Name and unique identifier of the Relying Party to which the request was made, - Attributes requested to be deleted.;
AS-RP-48-005;Actor-Specific Requirements;Relying Parties;Topic 48 - Blueprint for requesting data deletion to Relying Parties;48;Blueprint for requesting data deletion to Relying Parties;;DATA_DLT_07;Before executing a data deletion request, a Relying Party SHALL authenticate the requesting User (or the request itself), using appropriate authentication mechanisms of its own choosing. The Relying Party SHOULD use the authentication or signature facilities offered by the User's Wallet Unit for this purpose.;
AS-WP-48-004;Actor-Specific Requirements;Wallet Providers;Topic 48 - Blueprint for requesting data deletion to Relying Parties;48;Blueprint for requesting data deletion to Relying Parties;;DATA_DLT_08;Wallet Units, Relying Parties, and Registrars SHALL comply with the relevant requirements in [Technical Specification 7](../../technical-specifications/ts7-common-interface-for-data-deletion-request.md).;
AS-WP-50-001;Actor-Specific Requirements;Wallet Providers;Topic 50 - Blueprint to report unlawful or suspicious request of data;50;Blueprint to report unlawful or suspicious request of data;;RPT_DPA_01;A Wallet Unit SHALL enable the User to start the process of reporting a suspicious presentation request to a DPA. When prompted by the User, a Wallet Unit SHALL provide the contact details of the DPA which supervises the Relying Party that made the suspicious request, if available in the log for that request (see DASH_03). If the contact details of the supervising DPA are not available in the log, the Wallet Unit SHALL provide the contact details of the DPA of the region in which the Wallet Provider is residing. In addition, the Wallet Unit MAY also provide the contact details of other DPAs, taken from the European Data Protection Board website (<https://www.edpb.europa.eu/about-edpb/about-edpb/members_en>).;The DPA contact details may be unavailable in the log if there was no registration certificate in the presentation request and the User did not request the Wallet Unit to obtain the information registered about the Relying Party from the Registrar. See RPRC_16 - RPRC_18 in [Topic 44](./annex-2.02-high-level-requirements-by-topic.md#a2326-topic-44---registration-certificates-for-pid-providers-providers-of-qeaas-pub-eaas-and-non-qualified-eaas-and-relying-parties).
AS-WP-50-002;Actor-Specific Requirements;Wallet Providers;Topic 50 - Blueprint to report unlawful or suspicious request of data;50;Blueprint to report unlawful or suspicious request of data;;RPT_DPA_02;The Wallet Unit SHALL offer the User the option to report a suspicious request to a DPA via the transaction log presented in the dashboard, see [Topic 19](./annex-2.02-high-level-requirements-by-topic.md#a2312-topic-19---user-navigation-requirements-dashboard-logs-for-transparency).;
AS-WP-50-003;Actor-Specific Requirements;Wallet Providers;Topic 50 - Blueprint to report unlawful or suspicious request of data;50;Blueprint to report unlawful or suspicious request of data;;RPT_DPA_02a;A Wallet Unit SHALL support at least the following possibilities to report a suspicious presentation request to a DPA, depending on what contact details are available for the DPA: a) Open a URL in an external browser to report the request in a web form provided by the DPA. b) Open an external e-mail client and start a draft e-mail to the DPA, with a suitable template text, c) open an external phone client and start a phone call.;
EW-DM-50-001;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 50 - Blueprint to report unlawful or suspicious request of data;50;Blueprint to report unlawful or suspicious request of data;;RPT_DPA_03;Empty;
AS-WP-50-004;Actor-Specific Requirements;Wallet Providers;Topic 50 - Blueprint to report unlawful or suspicious request of data;50;Blueprint to report unlawful or suspicious request of data;;RPT_DPA_04;A Wallet Provider SHALL ensure that a Wallet Unit allows its User to substantiate a report sent to a DPA, including by attaching relevant information to identify the Relying Party and the Users' claims in a machine-readable format.;The log kept by the Wallet Unit will be standardized and is machine-readable in order to enable data portability. An excerpt from this log therefore can be used to substantiate the report.
AS-WP-50-005;Actor-Specific Requirements;Wallet Providers;Topic 50 - Blueprint to report unlawful or suspicious request of data;50;Blueprint to report unlawful or suspicious request of data;;RPT_DPA_05;A Wallet Unit SHALL log the fact that it initiated the sending of a report to a DPA (see RPT_DPA_02a), as specified in [Topic 19](./annex-2.02-high-level-requirements-by-topic.md#a2312-topic-19---user-navigation-requirements-dashboard-logs-for-transparency).;
EW-DM-50-002;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 50 - Blueprint to report unlawful or suspicious request of data;50;Blueprint to report unlawful or suspicious request of data;;RPT_DPA_05a;For a report sent to a DPA, the log SHALL contain at least: a) the date and time when the report was sent, b) the name and country of the DPA, and c) the channel and contact information used for initiating sending the report, i.e., the URL, e-mail address, or phone number of the DPA.;
AS-WP-50-006;Actor-Specific Requirements;Wallet Providers;Topic 50 - Blueprint to report unlawful or suspicious request of data;50;Blueprint to report unlawful or suspicious request of data;;RPT_DPA_06;Wallet Units, Data Protection Authorities, and Registrars SHALL comply with the relevant requirements in [Technical Specification 8](../../technical-specifications/ts8-common-interface-for-reporting-of-wrp-to-dpa.md).;
AS-WP-51-001;Actor-Specific Requirements;Wallet Providers;Topic 51 - PID or attestation deletion;51;PID or attestation deletion;;PAD_01;A Wallet Unit SHALL at any time enable the User to delete any PID or attestation from their Wallet Unit.;
AS-WP-51-002;Actor-Specific Requirements;Wallet Providers;Topic 51 - PID or attestation deletion;51;PID or attestation deletion;;PAD_02;If the User indicates that a PID or attestation must be deleted, and the Wallet Unit contains multiple PIDs or attestation having the corresponding attestation type and Provider, a Wallet Unit SHALL delete all of these PIDs and attestations simultaneously.;This situation may occur if the PID Provider or Attestation Provider issued a batch of attestations to the Wallet Unit, rather than a single one.
AS-WP-51-003;Actor-Specific Requirements;Wallet Providers;Topic 51 - PID or attestation deletion;51;PID or attestation deletion;;PAD_03;If the Wallet Unit deletes a PID or attestation on the User's request, the Wallet Unit SHALL NOT notify the respective PID Provider or Attestation Provider.;This is a matter of User privacy.
AS-WP-51-004;Actor-Specific Requirements;Wallet Providers;Topic 51 - PID or attestation deletion;51;PID or attestation deletion;;PAD_04;If the Wallet Unit deletes a PID or device-bound attestation on the User's request, the Wallet Unit SHALL ensure that all cryptographic assets in the WSCA/WSCD related to this PID, or in a keystore related to this attestation, are securely destroyed.;Key deletion for a PID key is a cryptographic key operation and requires User authentication, as specified in requirement WIAM_14.
AS-WP-51-005;Actor-Specific Requirements;Wallet Providers;Topic 51 - PID or attestation deletion;51;PID or attestation deletion;;PAD_05;If a Wallet Unit supports the [W3C Digital Credentials API] and it deletes, on the User's request, a PID or attestation previously disclosed to the Digital Credentials API framework, the Wallet Instance SHALL disclose the fact that it no longer stores this PID or attestation to the Digital Credentials API framework.;
AS-WP-51-006;Actor-Specific Requirements;Wallet Providers;Topic 51 - PID or attestation deletion;51;PID or attestation deletion;;PAD_06;If the User uninstalls the Wallet Instance, the Wallet Instance SHALL request the associated WSCA/WSCD and keystore(s) to delete all cryptographic assets related to the Wallet Unit and to all PIDs and device-bound attestations on the Wallet Unit, if the WSCA/WSCD and keystore(s) are connected to the User device at the moment the Wallet Instance is uninstalled.;It may happen there is no connection to the WSCA/WSCD or to a keystore at the moment the User uninstalls the Wallet Instance; for instance, in case the WSCA/WSCD is an external smart card and the User does not present that card to the User device. Another example occurs when the WSCA/WSCD is a remote HSM and the User device is offline at the moment the User uninstalls the Wallet Instance. In such cases, the cryptographic assets will probably remain present on the WSCA/WSCD or on the keystore, even though they will never be used again. If needed, it is up to the Wallet Provider to define how the Wallet Unit should handle such situations. For example, an HSM manager could address such cases by deciding to delete cryptographic keys in the HSM that are too old or haven't been used for too long, while being aware of the risks in doing so.
AS-RP-51-001;Actor-Specific Requirements;Relying Parties;Topic 52 Relying Party intermediaries;52;Relying Party intermediaries;;RPI_01;An intermediary SHALL register as a Relying Party, in accordance with all requirements in [Topic 27](./annex-2.02-high-level-requirements-by-topic.md#a2316-topic-27---registration-of-pid-providers-providers-of-qeaas-pub-eaas-and-non-qualified-eaas-and-relying-parties), while indicating it intends to act as an intermediary.;a) This implies that an intermediary obtains an access certificate containing its own name and unique Relying Party identifier. b) An intermediary may also obtain a registration certificate according to [Topic 44](./annex-2.02-high-level-requirements-by-topic.md#a2326-topic-44---registration-certificates-for-pid-providers-providers-of-qeaas-pub-eaas-and-non-qualified-eaas-and-relying-parties), but this certificate will not be used for intermediated transactions. c) An entity that registered as an intermediary may also register as a Relying Party in its own capacity. In such a case, it will receive one or more registration certificates for its intended use(s), and will use one of these certificates when interacting with a Wallet Unit.
AS-RP-51-002;Actor-Specific Requirements;Relying Parties;Topic 52 Relying Party intermediaries;52;Relying Party intermediaries;;RPI_02;Empty;
AS-RP-51-003;Actor-Specific Requirements;Relying Parties;Topic 52 Relying Party intermediaries;52;Relying Party intermediaries;;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](./annex-2.02-high-level-requirements-by-topic.md#a2326-topic-44---registration-certificates-for-pid-providers-providers-of-qeaas-pub-eaas-and-non-qualified-eaas-and-relying-parties). 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.;
AS-RP-51-004;Actor-Specific Requirements;Relying Parties;Topic 52 Relying Party intermediaries;52;Relying Party intermediaries;;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.;Such evidence may, for instance, be a contract between the intermediary and the intermediated Relying Party.
AS-RP-51-005;Actor-Specific Requirements;Relying Parties;Topic 52 Relying Party intermediaries;52;Relying Party intermediaries;;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.;a) See RPRC_19a for why the intermediary needs this information. b)  Since a), b) and c) will not change for each request, specification of this information can be done once. The same is true for d) and e) if the intermediated Relying Party has only one registered intended use.
AS-RP-51-006;Actor-Specific Requirements;Relying Parties;Topic 52 Relying Party intermediaries;52;Relying Party intermediaries;;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.;
AS-RP-51-007;Actor-Specific Requirements;Relying Parties;Topic 52 Relying Party intermediaries;52;Relying Party intermediaries;;RPI_06a;Empty;
AS-RP-51-008;Actor-Specific Requirements;Relying Parties;Topic 52 Relying Party intermediaries;52;Relying Party intermediaries;;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 names and identifiers of both the intermediary and the intermediated Relying Party to the User when asking for User approval, as described in RPA_07.;In this case, the name and identifier of the intermediary are included in the access certificate presented by the Relying Party Instance, whereas the name and identifier of the intermediated Relying Party are included in the extension of the presentation  request (see RPRC_19a), and in the registration certificate if available. If these names and identifiers are different, the Wallet Unit knows that the presentation request is from an intermediary on behalf of an intermediated Relying Party.
AS-RP-51-009;Actor-Specific Requirements;Relying Parties;Topic 52 Relying Party intermediaries;52;Relying Party intermediaries;;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.;The Wallet Unit can either do this by inspecting the registration certificate (if available) or by querying the Registrar.
AS-RP-51-010;Actor-Specific Requirements;Relying Parties;Topic 52 Relying Party intermediaries;52;Relying Party intermediaries;;RPI_07b;Empty;
AS-RP-51-011;Actor-Specific Requirements;Relying Parties;Topic 52 Relying Party intermediaries;52;Relying Party intermediaries;;RPI_08;When a Wallet Unit presents to an intermediary any User attributes from a PID or attestation, the intermediary SHALL, after successfully carrying out the verifications in RPI_09, forward these attributes (only) to the Relying Party on behalf of which the presentation request was made. If any of the verifications in RPI_09 fail, the intermediary SHALL NOT forward any attributes to the Relying Party.;
AS-RP-51-012;Actor-Specific Requirements;Relying Parties;Topic 52 Relying Party intermediaries;52;Relying Party intermediaries;;RPI_09;When a Wallet Unit presents to an intermediary any attributes from a PID or attestation, the intermediary SHALL verify the authenticity of the PID or attestation, its revocation status, device binding, and User binding, as well as any combined presentation of attributes, if applicable, as specified in this ARF and if agreed with the Relying Party. Furthermore, the intermediary SHALL verify the authenticity of the Wallet Unit and its revocation status, as specified in this ARF, if agreed with the Relying Party.;This ARF does not mandate that a Relying Party must carry out all of these verifications. Therefore, the intermediary and any Relying Party using its services must agree on what verifications the intermediary will carry out.
AS-RP-51-013;Actor-Specific Requirements;Relying Parties;Topic 52 Relying Party intermediaries;52;Relying Party intermediaries;;RPI_10;The intermediary SHALL delete any PIDs or attestations it obtained from the Wallet Unit, including any User attributes, completely and immediately after it has sent the User attributes to the intermediated Relying Party. If the intermediary does not send any User attributes to the intermediated Relying Party, for example because one of the verifications in the previous step failed, the intermediary SHALL delete the PIDs, attestations, or WUAs completely and immediately as soon as it has completed all necessary verifications.;
EW-DM-51-001;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 53 Zero-Knowledge Proofs;53;Topic 53 Zero-Knowledge Proofs;;ZKP_01;A ZKP scheme SHALL provide support for the following generic functions, while hiding all attributes of PIDs or attestations: (i) generation of a proof that an (some) attribute(s) having a specific value is (are) included in a PID or attestation, (ii) generation of a proof that a PID or attestation is within its validity period, (iii) generation of a proof that a PID or attestation has not been revoked, and (iv) generation of a proof that a PID or device-bound attestation is bound to a key stored in the WSCA/WSCD or in a keystore of the Wallet Unit. Additionally, a ZKP scheme SHOULD provide support for the following function, which SHOULD be used only when hiding the PID Provider or Attestation Provider is necessary: (v) generation of a proof that a PID or attestation has been issued by a trusted PID Provider or Attestation Provider, without revealing the PID Provider or Attestation Provider.;See section 4.1.1 of the Discussion Paper for Topic G.
EW-DM-51-002;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 53 Zero-Knowledge Proofs;53;Topic 53 Zero-Knowledge Proofs;;ZKP_02;A ZKP scheme SHALL support proving possession of attestation of a given type.;See section 4.1.2 and 4.1.3 of the Discussion Paper for Topic G.
EW-DM-51-003;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 53 Zero-Knowledge Proofs;53;Topic 53 Zero-Knowledge Proofs;;ZKP_03;A ZKP scheme SHOULD support the privacy-preserving binding of an attestation to a PID. In addition to the generic functions defined in ZKP_01, for this use case, a ZKP scheme SHALL provide support for the following functions: (i) generation of a proof that the Wallet Unit stores an attestation and a PID and that the attestation includes a specific attribute, having a specific value, which is also present in the PID.;See section 4.1.4 of the Discussion Paper for Topic G.
AS-AP-51-001;Actor-Specific Requirements;Attestation & PID Providers;Topic 53 Zero-Knowledge Proofs;53;Topic 53 Zero-Knowledge Proofs;;ZKP_04;A ZKP scheme SHOULD support the derivation of a verifiable User pseudonym, by combining an attribute value that is unique for the User with Relying Party-specific context (e.g., the Relying Party identifier) In addition to the generic functions defined in ZKP_01, for this use case, a ZKP scheme SHALL provide support for the following functions: (i) generation of a request for the issuance of an attestation that includes a secret attribute unique to the User, without revealing this attribute to the Attestation Provider, (ii) generation of an attestation presentation that includes a verifiable pseudonym derived from the secret attribute, a Relying Party identifier, and context-related information.;See section 4.1.5 of the Discussion Paper for Topic G.
EW-DM-51-004;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 53 Zero-Knowledge Proofs;53;Topic 53 Zero-Knowledge Proofs;;ZKP_05;A ZKP scheme SHALL be usable in both remote and proximity presentation flows. While the inclusion of ZKP will introduce computational and verification delays, these delays SHALL NOT critically undermine or defeat the purpose of the Relying Party service (e.g. because of a critical impact on the User experience of the Wallet Unit).;
EW-DM-51-005;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 53 Zero-Knowledge Proofs;53;Topic 53 Zero-Knowledge Proofs;;ZKP_06;A ZKP scheme SHOULD be able to generate proofs for already issued PIDs and attestations in the formats specified in [ISO/IEC 18013-5] or [SD-JWT VC].;
EW-DM-51-006;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 53 Zero-Knowledge Proofs;53;Topic 53 Zero-Knowledge Proofs;;ZKP_07;A ZKP scheme SHALL NOT introduce any additional communication or information that could be used to track or link User activity during, before, or after proof generation.;
EW-DM-51-007;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 53 Zero-Knowledge Proofs;53;Topic 53 Zero-Knowledge Proofs;;ZKP_08;A ZKP scheme SHALL rely solely on algorithms standardised by a standardisation organisation recognised by the Commission or in a standard recognised by the Commission.;
EW-DM-51-008;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 53 Zero-Knowledge Proofs;53;Topic 53 Zero-Knowledge Proofs;;ZKP_09;Use of a ZKP scheme SHALL NOT prevent the Wallet Unit's ability to provide User authentication with Level of Assurance High.;
AS-WP-54-001;Actor-Specific Requirements;Wallet Providers;Topic 54 - Accessibility;54;Accessibility;;ACC_01;Wallet Providers SHALL ensure that their Wallet Units comply with applicable requirements and standards in [Directive 2016/2012 on the accessibility of websites and mobile applications of public sector bodies](http://data.europa.eu/eli/dir/2016/2102/oj).;Compliance with the European Standard [ETSI EN 301 549 V1.1.2](https://www.etsi.org/deliver/etsi_en/301500_301599/301549/01.01.02_60/en_301549v010102p.pdf) (2015-04) provides a presumption of conformity to the Accessibility Directive.
AS-WP-54-002;Actor-Specific Requirements;Wallet Providers;Topic 54 - Accessibility;54;Accessibility;;ACC_02;Wallet Providers SHALL ensure that their Wallet Units comply with accessibility requirements for products and services established under [Directive (EU) 2019/882](http://data.europa.eu/eli/dir/2019/882/oj).;Compliance with the European Standard [ETSI EN 301 549 V1.1.2](https://www.etsi.org/deliver/etsi_en/301500_301599/301549/01.01.02_60/en_301549v010102p.pdf) (2015-04) potentially provides a presumption of conformity to this Directive.
AS-MS-55-001;Actor-Specific Requirements;Member States & Registrars;Topic 55 - Certificate Transparency;55;Certificate Transparency;;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.;
AS-MS-55-002;Actor-Specific Requirements;Member States & Registrars;Topic 55 - Certificate Transparency;55;Certificate Transparency;;CT_02;An Access CA issuing access certificates SHALL describe in its CPS how it logs all access certificates.;
AS-MS-55-003;Actor-Specific Requirements;Member States & Registrars;Topic 55 - Certificate Transparency;55;Certificate Transparency;;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.;
AS-MS-55-004;Actor-Specific Requirements;Member States & Registrars;Topic 55 - Certificate Transparency;55;Certificate Transparency;;CT_04; An Access CA SHALL include at least one Signed Certificate Timestamp (SCT) in each access certificate.;
AS-MS-55-005;Actor-Specific Requirements;Member States & Registrars;Topic 55 - Certificate Transparency;55;Certificate Transparency;;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).;
AS-MS-55-006;Actor-Specific Requirements;Member States & Registrars;Topic 55 - Certificate Transparency;55;Certificate Transparency;;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](./annex-2.02-high-level-requirements-by-topic.md#a234-topic-6---relying-party-authentication-and-user-approval)] and in particular requirement RPA_06a.;