ANNEX 2 - High-Level Requirements
A.2 High-level requirements
A.2.1 Introduction
A.2.1.1 Overview
This annex to the ARF 1.5.0 includes high-level requirements (HLRs) related to the EUDI Wallet ecosystem. The requirements define the responsible actor that should implement each requirement. There are no requirements imposed on the Users.
All requirements in this Annex only apply in the context of the EUDI Wallet ecosystem. Attestations that are not bound to Wallet Units, as described in section 6.6.3.8 of the ARF, are not included in the scope of this Annex.
A.2.1.2 Key words
This Annex uses the capitalised key words 'SHALL', 'SHOULD' and 'MAY' as specified in RFC 2119, i.e., to indicate requirements, recommendations and options specified in this annex.
In addition, 'must' (non-capitalised) is used to indicate an external constraint, i.e., a requirement that is not mandated by this document, but, for instance, by an external standard or specification. The word 'can' indicates a capability, whereas other words, such as 'will', and 'is' or 'are', are intended as statements of fact.
A.2.2 Structure and order of presentation of the HLRs
Topics presented in Section A.2.3 are ordered by a Topic number.
Each Topic includes a short description, followed by the High-Level Requirements (HLRs), identified by a unique identifier. The identifier includes a prefix which signifies the context of the HLRs (e.g. ISSU for issuance), an underscore and a numerator, e.g. ISSU_10.
A.2.3 High-Level Requirements
A.2.3.1 Topic 1 - Accessing Public and Private Online Services with a Wallet Unit
Short description
The primary purpose of the EUDI Wallet ecosystem is to enable Users to access online services and to enable Relying Parties offering such services to identify and authenticate Users with a high level of assurance. This essential functionality ensures that Relying Parties can confidently verify that they are interacting with the correct User.
In this use case, a User is using their Wallet Unit to present attributes related to their identity. The User accesses online services that require authentication. The User is concerned about sharing Person Identification Data (PID) during online interactions. Their objectives include identifying themselves with services requiring User identification and maintaining control over personal data sharing.
This Topic contains high-level requirements related to online identification and authentication of a User using their Wallet Unit.
HLRs
Index | Requirement specification |
---|---|
OIA_01 | A Wallet Unit SHALL support technical specifications to respond to person identification data (PID) and attestation presentation requests by Relying Parties. |
OIA_02 | A Wallet Unit SHALL support proving cryptographic binding between a WSCA included in the Wallet Unit and a PID or attestation, in accordance with [SD-JWT VC] or [ISO/IEC 18013-5]. Note: Such a mechanism is called device binding in [ISO/IEC 18013-5] and key binding in [SD-JWT VC]. |
OIA_03 | The Commission SHALL adopt the technical specifications for the PID or attestation presentation request-response protocol and for the device binding mechanism, according to the protocols and interfaces specified in [OpenID4VP] for remote flows, and [ISO 18013-5] for proximity flows. |
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 future technical specifications created by or on behalf of the Commission. |
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 [ISO/IEC 18013-7] Annex B. |
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 OpenID4VP profile for [SD-JWT VC] specified in [HAIP]. |
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. |
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. |
OIA_06 | A Wallet Unit SHALL transmit the requested attributes only after having received the User's authorisation. See also OIA_07. |
OIA_07 | A Wallet Unit SHALL support selective disclosure of attributes from PIDs and attestations to be released to the requesting Relying Parties. |
OIA_08 | Empty |
OIA_09 | Empty |
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. |
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. Note: Attestation types are explained in [Topic 12]. |
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]. |
OIA_13 | For both proximity and remote presentation flows, a Relying Party SHALL validate the qualified signature of a QEAA in accordance with Art.32 of the [European Digital Identity Regulation]. For the verification, the Relying Party SHALL use a trust anchor provided in a QEAA Provider Trusted List made available in accordance with Art. 22 of the [European Digital Identity Regulation]. |
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 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 of the [European Digital Identity Regulation]. The Relying Party SHALL also verify the certified attributes of the qualified certificate, as specified in Article 45f. |
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]. Notes: - 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. - 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. |
A.2.3.2 Topic 2 - Mobile Driving Licence within the EUDI Wallet ecoystem
Short description
A User can obtain their mobile Driver's Licence (mDL) from an mDL Provider and store it in an Wallet Unit. The User can then present the mDL to a Relying Party upon request to prove their driving rights conveniently, securely, and in compliance with the Driving Licences Directive, once it is adopted.
This Topic contains high-level requirements related to a User presenting a mobile Driver's Licence (mDL) to a Relying Party in a supervised or unsupervised scenario, and also in an unsupervised scenario, in proximity mode.
HLRs
No high-level requirements are identified for this Topic, as the mDL is an attestation that must comply with all relevant requirements in other Topics.
A.2.3.3 Topic 3 - PID Rulebook
Short description
The Person Identification Data (PID) Rulebook contains requirements specific to the PID within the EUDI Wallet ecosystem.
The PID Rule Book contains the following main topics:
- The PID attribute schema: This describes the structure, the type, the entity identifiers, and the logical organisation of the mandatory and optional attributes and metadata of the PID, as specified in Commission Implementing Regulation (EU) 2024/2977. It also describes how Member States can specify any possible national attributes. Two encodings for these attributes are specified, one compliant with [ISO/IEC 18013-5], the other compliant with [SD-JWT VC]. 2.The trust infrastructure necessary for PIDs, for both ISO/IEC 18013-5-compliant and SD-JWT VC-compliant encodings.
For more information, see Annex 3 - [PID Rulebook].
HLRs
Index | Requirement specification |
---|---|
PID_01 | PIDs and PID Providers SHALL comply with all requirements in [PID Rulebook]. |
A.2.3.4 Topic 4 - mDL Rulebook
Short description
The mobile driving licence (mDL) Rulebook contains requirements specific to the mDL use case within the EUDI Wallet ecosystem.
Mobile driving licences are legally specified in the proposed EC Regulation 2023_127 (4th Driving Licence Regulation). This Regulation specifies that mDLs must comply with the ISO/IEC 18013-5 standard. It does not mention any other standards, in particular not [SD-JWT VC]. Consequently, mDLs issued to a Wallet Unit will not be implemented as [SD JWT VC]- compliant documents. The mDL Rulebook therefore specifies only an ISO/IEC 18013-5 compliant encoding.
For more information, see Annex 3 - [mDL Rulebook].
HLRs
Index | Requirement specification |
---|---|
mDL_01 | mDLs and mDL Providers SHALL comply with all requirements in [mDL Rulebook]. |
A.2.3.5 Topic 5 - Wallet Unit Design Guide
There are no HLRs for this Topic.
A.2.3.6 Topic 6 - Relying Party authentication and User approval
Short description
Relying Party authentication is a process whereby a Relying Party proves its identity to a Wallet Unit, in the context of a transaction in which the Relying Party requests the Wallet Unit to release some attributes.
To perform Relying Party authentication, the Wallet Unit verifies a Relying Party Instance access certificate offered by the entity with which it communicates, which is called a "Relying Party Instance". Note that there could be multiple Relying Party Instances for each Relying Party.
The Wallet Unit communicates the outcome of Relying Party authentication to the User when it requests the User for approval to present the requested attributes. High-level requirements for User approval are also included in this Topic. The Wallet Unit also communicates the outcome of the verification of the Relying Party registration certificate, see Topic 44, and the outcome of the evaluation of an embedded disclosure policy, if present, see Topic 43.
HLRs
A. Relying Party authentication
Index | Requirement specification |
---|---|
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. 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]. |
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. |
RPA_03 | A Wallet Unit and a Relying Party Instance SHALL perform Relying Party authentication in all use cases, whether proximity or remote, using a Relying Party Instance access certificate. Note: 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. |
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. Note: For more information about Relying Party Access Certificate Authorities, please see [Topic 31]. |
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. |
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 registration certificate (see Topic 44), 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. |
RPA_06a | If the registration certificate indicates that the Relying Party is using the services of an intermediary, as described in Topic 52, the Wallet Unit SHALL verify that the name and the unique identifier of the intermediary included in the registration certificate are identical to the name and unique identifier included in the Relying Party Instance access certificate. If this verification fails, the Wallet Unit SHALL treat this as a Relying Party authentication failure. If this verification succeeds, the Wallet Instance SHALL display to the User the name of the intermediary. |
RPA_06b | If Relying Party authentication fails for any reason, 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. Note: It is up to the Wallet Provider to make a choice for one of the two options above. |
B. User approval
Index | Requirement specification |
---|---|
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 attribute. A Wallet Unit SHALL always allow the User to refuse releasing an attribute requested by the Relying Party. |
RPA_08 | A Wallet Unit SHALL ensure that (one of) its WSCA(s) has authenticated the User before allowing the User to give or refuse approval for releasing any attributes. Note: See [Topic 09] for information about the WSCA. |
RPA_09 | A Relying Party SHOULD communicate in the request which attributes are needed for which purpose (use case, service), if this is supported by the protocol used for communication with the Wallet Unit. Notes: - This could be done, for instance, by grouping the attributes and describing the use case, service, or purpose of each group. - The purpose of this recommendation is that a Relying Party makes clear to the User what the intended use, the service being accessed, or the specific purpose is of each requested attribute. For example, a service may legally require attributes for age verification (e.g., birthdate), but the Relying Party may additionally want a User address (e.g., street, location, PObox, country) in order to offer added-value services. Age verification attributes and address attributes should be grouped separately, and the purposes should be clearly distinguished. This allows the User to be better informed about the request, and also allows them to approve one purpose but deny the other; see RPA_10. |
RPA_10 | If a Wallet Unit receives a request indicating one or more purposes (use cases, services) for requesting attributes, the Wallet Instance SHOULD show these to the User when asking for User approval. Moreover, the Wallet Unit SHOULD ensure that for each purpose, the User gives approval either to release all attributes requested for that purpose, or none of them. Note: This means that a User should either approve the release of all attributes in a given group or to deny the entire group. The Wallet Unit should not allow partial approval within a group. Partial approval 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. |
A.2.3.7 Topic 7 - Attestation revocation and revocation checking
Short description
This Topic contains the high-level requirements (HLRs) relating to the (possible) revocation of PIDs, QEAAs, PuB-EAAs, non-qualified EEAs and WUAs by their providers. It also contains HLRs relating to the (possible) checking of the revocations status of a PID or attestation by a Relying Party.
Note: This Topic does not pertain to access certificates for Relying Parties, PID Providers or Attestation Providers as discussed in [Topic 31]. Neither does it apply to any intermediate certificates establishing trust between these certificates and the respective trust anchors. These certificates are part of a Public Key Infrastructure (or a similar trust framework), and rules for revoking these certificates will be established within the respective PKI or trust framework.
HLRs
Index | Requirement specification |
---|---|
VCR_01 | A PID Provider, QEAA Provider, PuB-EAA Provider, or Wallet Provider SHALL use one of the following methods for revocation of a PID, QEAA, PuB-EAA, or WUA: 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, orUse an Attestation Revocation List mechanism specified per VCR_11. Note: 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. |
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. |
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. Similarly, if a WUA is revocable, 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. Note: A PID Provider, Attestation Provider or Wallet Provider MAY outsource the operation of the revocation process to a third party. |
VCR_04 | A PID Provider, Attestation Provider or Wallet Provider that revoked a PID or attestation SHALL NOT reverse the revocation. |
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. |
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. |
VCR_07 | If a WUA is revocable, the Wallet Provider SHALL revoke that WUA upon the explicit request of the User to revoke their Wallet Unit. |
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 subject of the PID or the attestation. |
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 WU_Revocation 18 in Topic 38. |
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. |
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 and it is still valid for at least 24 hours. In this situation, the PID Provider, Attestation Provider, or Wallet Provider SHALL immediately issue a new PID, attestation, or WUA with the correct value for the changed attribute. Notes: - 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. - The topic of re-issuance of PIDs and attestations will be discussed with Member States for ARF 2.0. |
VCR_10 | Wallet Providers SHALL implement the attestation revocation mechanisms specified per VCR_11 in their Wallet Solution(s). |
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. Note: 'Attestation Status List' and 'Attestation Revocation List' are specific mechanisms, defined in Annex 1. Attestation Revocation Lists are sometimes referred to as 'Identifier Lists'. |
VCR_12 | If a Relying Party decides it needs to verify the revocation status of a PID, or attestation, it SHALL support both the Attestation Status List mechanism and the Attestation Revocation List mechanism specified per VCR_11. Note: Per VCR_13, it is not mandatory for a Relying Party to verify whether a PID, or attestation is revoked. |
VCR_13 | A Relying Party SHOULD verify the revocation status of a PID, attestation, or WUA upon obtaining it from a Wallet Unit, following the steps specified per VCR_11. |
VCR_14 | When no reliable information regarding the revocation status of a PID, attestation or WUA 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, attestation or WUA. |
A.2.3.8 Topic 8 - Design Solutions on Data Sharing scenarios
There are no HLRs for this Topic.
A.2.3.9 Topic 9 - Wallet Unit Attestation
Note to this Topic in version 1.5.0: The Commission received many comments on the ideas described in this Topic, particularly relating to key association. In response, the Commission decided to add the Wallet Unit Attestation to the list of open topics that need further discussion before publication of ARF 2.0. In these discussions, also the topic of key association will be discussed. In anticipation of the outcome of these discussions, nothing was changed in this Topic apart from some clarifications. In addition, changes were made to align the text with the Implemented Acts. In particular, the terms 'WTE' and 'WIA' were replaced by 'WUA'. Some further changes were needed to avoid creating contradictions, for instance, in places where 'WTE' and 'WIA' were both mentioned in a single sentence. Also, some changes were made to explain that the WUA fulfills two separate roles, namely the old WTE role and the old WIA role.
Short description
When a PID Provider or Attestation Provider receives a request from a User to issue a PID or attestation to the User's Wallet Unit, the PID Provider or Attestation Provider needs to decide whether it can comply with this request. To determine this, the PID Provider or Attestation Provider needs to know (among other things) if the Wallet Unit offers the functional capabilities required by the PID Provider or Attestation Provider in its PID or attestation issuing policy. In addition, the PID Provider or Attestation Provider needs to know if the Wallet Secure Cryptographic Application(s) (WSCA) and the corresponding Wallet Secure Cryptographic Device(s) (WSCD) that are part of the Wallet Unit offer the required level of security. Therefore, the PID Provider or Attestation Provider needs to receive trustworthy information about these capabilities and security posture.
This Topic introduces an information object that contains the necessary information. This object is called the Wallet Unit Attestation (WUA). The WUA also contains a public key. By including this public key in the WUA, the Wallet Provider attests that the corresponding private key is protected by a certified WSCA/WSCD that has the properties and security posture described in the WUA. Note that the information about the Wallet Unit and the WSCA(s) is selectively disclosable, meaning that the Wallet Unit can release the WUA either with or without this information.
The PID Provider or Attestation Provider then asks that WSCA to create a key pair for its new PID or attestation, and to prove that this new key is associated with the key in the WUA. Key association primarily means that the PID or attestation private key is protected by the same WSCA as the WUA private key. Therefore, the PID Provider or Attestation Provider can be sure that the security level of the new PID or attestation key is the same as the security level of the WUA key. At the moment of writing this version of the ARF, it is not fully clear how many WSCDs will support the cryptographic functionalities necessary to generate a proof of association. Therefore, the creation of a proof of association in a WSCA is recommended (SHOULD), not required (SHALL). In this way, once a Wallet Unit includes a WSCD/WSCA that supports the required cryptographic functionalities, proofs of association can be used as described in this Topic.
Please note that the scope of this Topic is limited to the question of how the WUA is issued during Wallet Unit activation and how it is used during attestation issuance. The role played by the WUA during the release of an attestation to a Relying Party is discussed in [Topic 18] (Combined presentation of attributes).
HLRs
A. Creating the WUA during Wallet Unit activation
Index | Requirement specification |
---|---|
WUA_01 | A Wallet Provider SHALL activate a new Wallet Unit before a User can use it to obtain an attestation. |
WUA_02 | A WSCA SHALL authenticate the User before performing any cryptographic operation involving a private or secret key of a Wallet Unit (i.e., a WUA key) or of a PID or an attestation in a Wallet Unit. For a PID key (which is part of the EUDI Wallet eID means), this WSCA SHALL be certified to be compliant with applicable requirements for level of assurance "high" in Commission Implementing Regulation (EU) 2015/1502 section 2.2.1. Note: Many actions of the Wallet Unit, such as processing a Relying Party request and presenting an attestation, require multiple cryptographic operations, for example ephemeral key generation followed by key agreement and message encryption. This requirement does not imply that separate User authentication is necessary before each of these. 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. |
WUA_03 | A Wallet Unit SHALL authenticate the User before performing any operation excluding cryptographic operations. The Wallet Unit MAY rely on a WSCA to do so, per WUA_02, but MAY also rely on a User authentication method implemented in the Wallet Instance. However, if implemented by the Wallet Instance, the User authentication mechanism SHALL be Wallet Instance-specific, meaning it SHALL be independent from any general User authentication mechanism for the User device, such as a lock screen. Notes:The goal of this requirement is to prevent any User interaction without User authentication, including, for example, using the user interface to see which attestations are present in the Wallet Unit or what are the values of specific User attributes.Cryptographic operations can only be performed by the WSCA after User authentication by the WSCA, according to WUA_02. |
WUA_03b | For User authentication according to WUA_03, a Wallet Unit SHALL implement an idle timeout of at most 5 minutes, after which User authentication SHALL again be required. The Wallet Unit SHOULD provide the User with the option to set the idle timeout to a duration shorter than 5 minutes. |
WUA_04 | Empty |
WUA_05 | Empty |
WUA_06 | A Wallet Provider SHALL only activate a new Wallet Unit if it has verified that: - The Wallet Unit includes at least one WSCA that is certified to be compliant with applicable requirements in this Topic, for level of assurance "high". In addition, the Wallet Unit MAY include one or more other WSCAs. - The private key corresponding to the public key in the WUA (see WUA_07) is protected by the respective WSCA. |
WUA_07 | During the activation of a new Wallet Unit, a Wallet Provider SHALL create and sign at least one Wallet Unit Attestation and issue it to the Wallet Unit. |
WUA_08 | The Commission SHALL take measures to ensure that the contents, format and encoding of the Wallet Unit Attestation is specified in a technical specification. This technical specification SHALL be a Rulebook complying with all requirements in Topic 12. Each WUA SHALL describe the Wallet Unit and a certified WSCA included in that Wallet Unit, in such a way that a PID Provider or Attestation Provider processing the WUA is able to take a well-grounded decision on whether to issue an attestation to that Wallet Unit. Note: In general, a PID Provider or Attestation Provider will also need information about the User. Such information is not contained in the WUA. |
WUA_09 | A Wallet Provider SHALL consider all relevant factors, including the risk of a WUA public key becoming a vector to track the User, when deciding on the validity period of a WUA. A Wallet Provider MAY use short-lived WUAs to mitigate such risks. |
WUA_10 | A WSCA SHALL generate a new key pair for a new WUA on request of the Wallet Provider via the Wallet Instance. The WSCA SHALL register the new key as a WUA key in an internal registry. The WSCA SHALL register the WUA key as an independent (i.e., non-associated) key in an internal registry. Note: A WUA key can be associated later with a PID or attestation key when that PID or attestation key is created, see WUA_13. |
WUA_11 | A WUA SHALL contain a public key, and the corresponding private key SHALL be generated by the WSCA described in the WUA. Note: A WUA key pair is generated as per WUA_10. |
WUA_12 | In case the Wallet Provider must update the WUA because the information in the WUA is outdated, the Wallet Provider SHALL ensure that the Wallet Unit only releases the latest version of a WUA to an Attestation Provider. |
B. Using the WUA during issuance of an attestation
Index | Requirement specification |
---|---|
WUA_13 | During PID or attestation issuance, a WSCA 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. The PID Provider or Attestation Provider SHALL indicate a single WUA public key (see WUA_10) with which the new PID or attestation key must be associated. This indication can either be direct, by providing the WUA public key value, or indirect, by providing a public key value that has been associated with the WUA key previously. In the latter case, the WSCA SHALL look up the associated WUA key in its internal registry. The WSCA SHALL register the new key in an internal registry as an attestation key. The WSCA SHALL register the association between the new private key and the WUA private key in an internal registry. Notes: Direct indication of the WUA is used in case a PID Provider or Attestation Provider indicates during issuing that the new PID or attestation must be associated with a WUA public key, see WUA_15 and WUA_16.Indirect indication of the WUA key is used in case an Attestation Provider indicates during issuing that the new attestation must be associated with an existing PID or attestation, see WUA_16.In case of re-issuance of an existing (short-lived) PID or attestation, or 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. Requirements regarding re-issuance processes will be added in a future version of this document. |
WUA_14 | During PID or attestation issuance, a WSCA SHALL prove possession of the private key corresponding to the new PID or attestation public key, on request of the PID Provider or Attestation Provider via the Wallet Instance, for example by signing a challenge with that private key. |
WUA_15 | A PID Provider SHALL indicate to a WSCA (via the Wallet Instance) the public key to which the new PID must be associated. This SHALL be a WUA public key. |
WUA_16 | An Attestation Provider SHALL indicate to a WSCA (via the Wallet Instance) the public key to which the new attestation must be associated. This SHALL be either a WUA public key or the public key of a PID or attestation that already exists in the Wallet Unit. Note: if the Attestation Provider indicates a PID or attestation public key, this is an indirect indication of a WUA key, see WUA_13. |
WUA_17 | During PID or attestation issuance, a WSCA SHALL prove possession of the private key corresponding to a WUA public key on request of a PID Provider or Attestation Provider via the Wallet Instance, for example by signing a challenge with that private key. |
WUA_18 | During PID or attestation issuance, a WSCA SHOULD generate a proof of association for two or more public keys on request of the PID Provider or Attestation Provider. The WSCA SHALL generate this proof only if the corresponding private keys are protected by the same WSCA and the WSCA has internally registered an association between these private keys. Notes: - It is possible that some private keys in a WSCA are not associated with each other, even though they are managed within the same WSCA. - If two keys are associated, this implies that they are both associated with the same WUA key. |
WUA_19 | During PID or attestation issuance, the PID Provider or Attestation Provider SHALL verify that the WSCA described in the WUA received from the Wallet Unit has proven possession of the private key corresponding to the public key in the WUA (see WUA_17). The PID Provider or Attestation Provider SHALL also verify that the WSCA has proven possession of the new PID or attestation private key (see WUA_14). In addition, the PID Provider or Attestation Provider SHOULD verify that the WSCA has proven association (see WUA_18) between the new PID or attestation public key and the public key requested by the PID Provider or Attestation Provider according to WUA_15 or WUA_16. Notes: - See also WUA_13. - These three proofs MAY be implemented as a single cryptographic proof. |
WUA_20 | During PID or attestation issuance, a Wallet Unit SHALL provide the PID Provider or Attestation Provider with information on all WSCAs it is able to use for private key management and that comply with the PID Provider's or Attestation Provider's requirements. |
WUA_21 | During PID or attestation issuance, a Wallet Unit SHALL provide the PID Provider or Attestation Provider with the WUA describing the properties of the WSCA that generated the new PID or attestation private key and protects it. |
WUA_22 | If a Wallet Unit contains multiple WSCAs, it SHALL register which PIDs and attestations are bound to each of these WSCAs. |
C. Miscellaneous
Index | Requirement specification |
---|---|
WUA_23 | The common OpenID4VCI protocol referenced in requirement ISSU_01, or an EUDI Wallet-specific extension or profile thereof, SHALL enable a Wallet Unit to transfer a WUA to a PID Provider or Attestation Provider. |
WUA_24 | A Wallet Unit SHALL release data related to the User device in a WUA only to a PID Provider or Attestation Provider, and not to a Relying Party or any other party. Note: The reason for this requirement is that the Relying Party does not need to know anything about the User's device. Therefore, such data must not be released to Relying Parties, as doing so might violate User privacy. |
WUA_25 | The common OpenID4VCI protocol referenced in requirement ISSU_01, or an EUDI Wallet-specific extension or profile thereof, SHALL enable a Wallet Unit to transfer the proofs of association and possession mentioned in WUA_19 to a PID Provider or Attestation Provider. Note: These three proofs MAY be implemented as a single cryptographic proof. |
WUA_26 | The common OpenID4VCI protocol referenced in requirement ISSU_01, or an EUDI Wallet-specific extension or profile thereof, SHALL enable a Wallet Unit to transfer a public key to a PID Provider or Attestation Provider, to be included in the new PID or attestation. |
WUA_27 | 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 indicate in the Token Response: the WSCA to which the new PID or attestation key must be bound, for example by referring to a WSCA identifier listed in the WUA,or, alternatively, the existing PID or attestation public key with which the new attestation key must be associated. |
D. Overview: Requirements for a WSCA
The technical requirements above imply the following requirements for a WSCA.
Index | Requirement specification |
---|---|
WUA_28 | A WSCA SHALL be able to verify the authentication factors of a User, in accordance with the requirements in Commission Implementing Regulation (EU) 2015/1502 section 2.2.1. |
WUA_29 | A WSCA SHALL be able to generate a new key pair on request of the Wallet Instance. |
WUA_30 | A WSCA 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. |
WUA_31 | A WSCA SHALL register each newly generated key pair as either a WUA key or an attestation key, depending on information provided by the Wallet Instance in the key generation request. The internal registry used by the WSCA for this purpose SHALL be protected against modification by external parties. |
WUA_32 | A WSCA SHALL protect a private key it generated during the entire lifetime of the key. This protection SHALL at least imply that the WSCA prevents the private key from being extracted in the clear. If a WSCA is able to export a private key in encrypted format, the key used for key encryption SHALL be properly protected, for example as multiple key shares controlled by multiple key custodians. |
WUA_33 | A WSCA SHALL associate each newly generated attestation key with a WUA key indicated by the Wallet Instance. The WSCA SHALL record the association between these keys in an internal registry, which SHALL be protected against modification by external parties. |
WUA_34 | For the purposes of WUA_33, a Wallet Instance SHALL indicate the WUA key either directly, by WUA public key value, or indirectly, by value of a public key that is already associated to the intended WUA key. In the latter case, the WSCA SHALL look up the intended WUA key in its registry. |
WUA_35 | A WSCA SHALL consider two keys to be associated if they are associated to a common WUA key. |
WUA_36 | A WSCA SHOULD be able to generate a proof of association for two or more public keys. The WSCA SHALL generate such a proof if and only if the corresponding private keys are protected by that WSCA, and the WSCA has internally registered an association between these private keys. |
A.2.3.10 Topic 10 - Issuing a PID or attestation to a Wallet Unit
Short description
PID Providers and Attestation Providers issue PIDs and attestations to Wallet Units. This Topic lists the high-level technical requirements related to PID and attestation issuance.
This Topic also contains the high-level requirements for Topic 23.
HLRs
A - Generic HLRs
Index | Requirement specification |
---|---|
ISSU_01 | Wallet Providers SHALL ensure that their Wallet Solution supports the OpenID4VCI protocol specified in [OpenID4VCI], with additions and changes as documented in this Annex (see e.g. this Topic and [Topic 9]) and in future technical specifications created by or on behalf of the Commission. |
ISSU_02 | Wallet Providers SHALL ensure that their Wallet Solution supports the attestation formats specified in ISO/IEC 18013-5, see [ISO18013-5], and in "SD-JWT-based Verifiable Credentials (SD-JWT VC)", see [SD-JWT-VC], with additions and changes as documented in this Annex and in future technical specifications created by or on behalf of the Commission. |
ISSU_03 | Empty |
ISSU_04 | The OpenID4VCI protocol referenced in requirement ISSU_01, or an EUDI Wallet-specific extension or profile thereof, SHALL enable PID Providers and Attestation Provider to issue to a Wallet Unit a batch of multiple PIDs or attestations that are simultaneously valid and contain the same attributes. |
ISSU_05 | A Wallet Unit SHALL support a process to activate a newly issued PID, in accordance with Commission Implementing Regulation (EU) 2015/1502 Section 2.2.2. The Wallet Unit SHALL NOT allow a User to use a non-activated PID. Notes: - The goal of the activation process is to verify that the PID was delivered into the Wallet Unit and WSCA of the User who is the subject of the PID. - This requirement is not applicable for QEAAs, PuB-EAAs or non-qualified EAAs, since these are not identity means in the sense of Commission Implementing Regulation (EU) 2015/1502. |
ISSU_06 | After a Wallet Unit receives a PID or an attestation from a PID Provider or Attestation Provider, it SHALL verify that the PID or attestation it received matches the PID or attestation requested by the Wallet Unit. |
ISSU_07 | After a Wallet Unit receives a PID from a PID Provider, it SHALL validate the signature of the PID using a trust anchor provided in a PID Provider Trusted List made available in accordance with [Topic 31]. Note: This signature validation may not be useful in architectures where the Wallet Provider is also the PID Provider and the validation of the PID signature would be done by the same component (namely, a remote HSM) that created the signature. However, in such a situation, additional measures SHALL be taken to ensure that any errors in the PID issuance process will be detected. |
ISSU_08 | After a Wallet Unit receives a QEAA from a QEAA Provider, it SHALL validate the qualified signature of the QEAA in accordance with Art.32 of the [European Digital Identity Regulation]. For the verification, the Wallet Unit SHALL use a trust anchor provided in a QEAA Provider Trusted List made available in accordance with Art. 22 of the [European Digital Identity Regulation]. |
ISSU_09 | After a Wallet Unit receives a PuB-EAA from a PUB-EAA Provider, it SHALL validate the qualified signature of the PuB-EAA in accordance with Art.32 of the [European Digital Identity Regulation]. For that verification, the Wallet Unit SHALL use the public key provided in the qualified certificate of the QTSP supporting the qualified signature. The Wallet Unit SHALL also validate the qualified certificate of the QTSP using a trust anchor provided in a Trusted List made available in accordance with Art. 22 of the [European Digital Identity Regulation]. Finally, the Wallet Unit SHALL also verify the certified attributes of the qualified certificate, as specified in Article 45f. |
ISSU_10 | After a Wallet Unit receives a non-qualified EAA from an EAA Provider, it SHALL validate the signature of the EAA using a trust anchor provided according to the mechanism(s) specified in the applicable Rulebook, see [Topic 12]. Notes: - Requirements ISSU_07 to ISSU_10 are equivalent to requirements OIA_12 to OIA_15 in [Topic 1]. 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. - 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. |
ISSU_11 | A Wallet Unit SHALL request the User's approval before storing a PID or attestation obtained from a PID Provider or Attestation Provider. When requesting approval, the Wallet Instance SHALL display the contents of the PID or attestation to the User. The Wallet Instance SHALL also inform the User about the identity of the PID Provider or Attestation Provider, using the subject information in the PID Provider's or Attestation Provider's access certificate. |
ISSU_11b | In case one or more of the verifications in ISSU_06 – ISSU_11 fail, the Wallet Unit SHALL immediately delete the PID or attestation it received. The Wallet Instance SHALL notify the User about the fact that issuance of the PID or attestation was not successful, including the reason for this failure. |
ISSU_12 | A PID Provider or Attestation Provider SHALL offer its PIDs or attestations in all formats required in the PID Rulebook or the applicable Attestation Rulebook, see [Topic 12]. Note: Examples include the mdoc format specified in [ISO/IEC 18013-5] and the SD-JWT VC-format specified in [SD-JWT VC]. |
ISSU_12a | A Wallet Provider SHALL ensure that, when a User instructs their Wallet Unit to request a PID or attestation from a PID Provider or Attestation Provider, the Wallet Unit requests that PID or attestation in all formats offered by the PID Provider or Attestation Provider. Note: Examples include the mdoc format specified in [ISO/IEC 18013-5] and the SD-JWT VC-format specified in [SD-JWT VC]. |
B - HLRs for PID issuance
Index | Requirement specification |
---|---|
ISSU_13 | A Wallet Provider SHALL ensure that at least one PID Provider is willing to issue a PID complying with [PID Rulebook] to Users of the Wallet Units it provides. |
ISSU_14 | A PID Provider SHALL ensure that all PIDs it issues to Wallet Units comply with the requirements specified in [PID Rulebook]. |
ISSU_15 | A PID Provider SHALL support the OpenID4VCI protocol referenced in ISSU_01 for issuing PIDs. |
ISSU_16 | Empty |
ISSU_17 | A PID Provider SHALL implement device binding for all PIDs it issues, meaning it SHALL ensure that a PID is cryptographically bound to a WSCA included in the Wallet Unit, as specified in requirement WUA_13 in [Topic 09]. Note: Device binding is called 'mdoc authentication' in [ISO/IEC 18013-5] and 'key binding' in [SD-JWT-VC]. |
ISSU_18 | A PID Provider SHALL verify the identity of the subject of the PID in compliance with Level of Assurance (LoA) High requirements. Note: These requirements will be determined by the relevant eID scheme. Note to ARF 1.5.0: In most cases, the subject of the PID is the same person as the User. However, it has not yet been ruled out that a Wallet Unit may contain multiple PIDs, for example in the case of a parent having their children's PIDs in their Wallet Unit. Another example is a natural person representing a legal person, who may hold a legal-person PID in their Wallet Unit next to their own natural-person PID. These topics will be further discussed with Member States. |
ISSU_18a | A PID Provider SHALL ensure that the attributes attested in the PID issued are valid for the identified PID subject at any point of time of PID validity. |
ISSU_19 | For the verification of a WUA, a PID Provider SHALL accept the trust anchors in the Wallet Provider Trusted List it needs. Notes: The Wallet Provider Trusted List are explained in [Topic 31].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. |
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. |
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. |
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. Notes: - For the WUA, see [Topic 9] and [Topic 38]. - CIR 2024/2977, Article 3 (9), also allows "another authentication mechanism in accordance with an electronic identity scheme notified at assurance level high." However, the ARF does not further specify such other authentication mechanisms, which means that in general they will not be interoperable. |
ISSU_22 | A PID Provider SHALL include its PID Provider access certificate in its Issuer metadata used in the common OpenID4VCI protocol referenced in ISSU_01. |
ISSU_22a | A PID Provider SHALL sign its metadata (as defined in OpenID4VCI) using the private key corresponding to its PID Provider access certificate. |
ISSU_23 | For the verification of PID Provider access certificates, a Wallet Unit SHALL accept the trust anchors in the Trusted List(s) of PID Provider Access Certificate Authorities it needs. Notes: - PID Provider Access Certificate Authority Trusted Lists are explained in [Topic 27]. -It is not mandatory for a Wallet Unit to accept all PID Provider Access Certificate Authority Trusted Lists, if there are multiple. Wallet Providers will choose which Trusted Lists they need to subscribe to, for example depending on the Member State(s) they are operating in. |
ISSU_23a | A Wallet Provider SHALL support at least one PID Provider, meaning that its Wallet Units SHALL be capable of requesting the issuance of a PID from these PID Provider(s), and that the Wallet Provider has agreed with the PID Provider(s) that the PID Provider(s) will process such a request according to the agreed rules and procedures. |
ISSU_23b | Prior to or during installation of a Wallet Instance, the Wallet Provider SHALL notify the User about the PID Provider(s) that are supported by the Wallet Unit. |
ISSU_24 | A Wallet Unit SHALL authenticate and validate the PID Provider access certificate before requesting the issuance of a PID. The Wallet Unit SHALL verify at least that the access certificate indicates that its subject is a PID Provider, 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 PID Provider Access Certificate Authority Trusted List. Note: The PID Provider Access Certificate Authority Trusted List is not the same as the PID Provider Trusted List mentioned in [Topic 31]. |
C - HLRs for Attestation Issuance
Index | Requirement specification |
---|---|
ISSU_25 | An Attestation Provider SHALL ensure all attestations issued to Wallet Units comply with the requirements specified in the applicable Rulebook, as described in [Topic 12]. |
ISSU_26 | An Attestation Provider SHALL support the OpenID4VCI protocol referenced in ISSU_01 for issuing attestations. |
ISSU_27 | An Attestation Provider SHALL implement device binding for all attestations it issues, meaning it SHALL ensure that an attestation is cryptographically bound to a WSCA included in the Wallet Unit, as specified in requirement WUA_13 in [Topic 9]. Note that device binding is called mdoc authentication in [ISO/IEC 18013-5] and key binding in [SD-JWT-VC]. |
ISSU_27a | If applicable, an Attestation Provider SHALL verify the identity of the subject of the attestation in compliance with applicable requirements, in accordance with relevant standards or Implementing Regulations. Note: Not every attestation has a subject. For example, a holiday voucher may be valid for any User that can present it to a Relying Party. This is comparable to the concept of a 'bearer token'. |
ISSU_27b | If applicable, an Attestation Provider SHALL ensure that the attributes attested in the attestation issued are valid for the identified attestation subject. |
ISSU_28 | For the verification of a WUA, an Attestation Provider SHALL accept the trust anchors in the Wallet Provider Trusted List. Note: The Wallet Provider Trusted List is explained in [Topic 31]. |
ISSU_29 | An Attestation Provider SHALL support all Wallet Solutions, meaning that they SHALL NOT discriminate between Wallet Solutions when processing a request for the issuance of an attestation. |
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. Note: For the WUA, see [Topic 9] and [Topic 38]. |
ISSU_31 | Empty |
ISSU_32 | An Attestation Provider SHALL include its Attestation Provider access certificate in its Issuer metadata used in the common OpenID4VCI protocol referenced in ISSU_01. |
ISSU_32a | An Attestation Provider SHALL sign its metadata (as defined in OpenID4VCI) using the private key corresponding to its Attestation Provider access certificate. |
ISSU_33 | For the verification of Attestation Provider access certificates, a Wallet Unit SHALL accept the trust anchors in all Attestation Provider Access Certificate Authority Trusted List(s). Note: Attestation Provider Access Certificate Authority Trusted Lists are explained in [Topic 27]. There may be separate Access Certificate Authority Trusted Lists for QEAA Providers, PuB-EAA Providers, and EAA Providers. |
ISSU_33a | A Wallet Provider SHALL support all Attestation Providers, meaning that its Wallet Units SHALL be capable of requesting the issuance of a QEAA, PuB-EAA, or non-qualified EAA from these Providers at the User's request. |
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 at least that the access certificate indicates that its subject is a QEAA Provider, Pub-EAA Provider, or EAA Provider, 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 the Attestation Provider Access Certificate Authority Trusted List, as documented in [Topic 27]. Note: 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 EAA from a non-qualified EAA Provider, a Wallet Unit may need to verify that that EAA Provider is authorised or registered to issue the type of EAA the Wallet Unit is requesting. Such verification requirements, as well as the mechanisms allowing to do this, may be defined in the applicable Rulebook. |
A.2.3.11 Topic 11 - Pseudonyms
Short description
Wallet Units will support generating pseudonyms for Users in compliance with the W3C WebAuthn API specification, [W3C WebAuthn]. On a high level, this means that the WSCD in the Wallet Unit will be able to create key pairs. The public keys of these pairs function as pseudonyms for the User. Only the User can use these pseudonyms, since the WSCD authenticates the User before allowing a pseudonym to be used, see requirement WUA_02. The Wallet Unit will keep an internal structure to associate each pseudonym (public key) with a specific Relying Party, based on the Relying Party unique identifier in the Relying Party Instance access certificate mentioned in requirement Reg_32.
Note to this Topic in version 1.5.0: The Commission received many comments on the Pseudonym Rulebook. In response, it decided to not publish the latest version of this Rulebook on the public GitHub repository for ARF 1.4.0. For ARF version 1.5.0, the Commission decided to drop the Pseudonym Rulebook and remove all references to it.
Moreover, pseudonyms were added to the list of topics to be discussed for ARF 2.0. These discussions will include the use cases for which Wallet Units must support pseudonyms and the way in which this support will be technically implemented. This Topic will be updated in ARF 2.0.
HLRs
Index | Requirement specification |
---|---|
PA_01 | A Wallet Unit SHALL be able to generate pseudonyms for its User, in compliance with the W3C WebAuthn API specification [W3C WebAuthn]. |
A.2.3.12 Topic 12 - Attestation Rulebooks
Short description
Article 45e of the [European Digital Identity Regulation] sets up the legal basis for the Commission to "where necessary, establish specifications and procedures for the catalogue of attributes and schemes for the attestation of attributes and verification procedures for qualified electronic attestations of attributes". As described in section 5.6 of [ARF], these 'schemes for the attestation of attributes' will be described in so-called Attestation Rulebooks. A separate Rulebook will be created for each type of attestation. This Topic describes the high-level requirements for the Attestation Rulebooks that will specify the details of new types of attestations.
Attestation Rulebooks will be written by Attribute Schema Providers, a role which can be assumed by different types of organisation. The goal of this Topic is to ensure that all Rulebooks that will be written in the future will contain the same type of information and the same level of detail, such that all attestations are interoperable.
Attestation Rulebooks may be registered and published in a publicly accessible catalogue, as described in Topic 25.
HLRs
A. Requirements regarding attestation formats
Index | Requirement specification |
---|---|
ARB_01 | The Schema 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]. |
ARB_01a | The Schema 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 v1.1] or [W3C VCDM v2.0]. |
ARB_02 | The Schema 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. Note: 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. |
ARB_03 | The Schema 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(1) of the [European Digital Identity Regulation]. |
ARB_04 | If an Attestation Rulebook specifies that a type of attestation can be issued in a format compliant with [W3C VCDM v1.1] or [W3C VCDM v2.0], the Schema 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(1) of the [European Digital Identity Regulation]. |
B. Requirements regarding attestation types
Index | Requirement specification |
---|---|
ARB_05 | The Schema 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. Notes: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 “id” property of an Input Descriptor 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. |
C. Requirements regarding attestation attribute schemas
Index | Requirement specification |
---|---|
ARB_06 | The Schema 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. |
ARB_06a | For ISO/IEC 1803-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. Note: In ISO/IEC 18013-5, namespaces are discussed and a method for generating unique namespace identifiers is recommended. |
ARB_06b | For [SD-JWT VC]-compliant attestations, the Schema Provider for the Attestation Rulebook SHALL ensure that each claim name is either included in the IANA registry for JWT claims, or is a Public Name as defined in RFC 7519. Note: [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. |
ARB_07 | When determining the attributes to be included in a new attestation type, the Schema Provider for the applicable Attestation Rulebook SHOULD consider referring to attributes that are already included in the catalogue specified in Topic 25 + 26, rather than unnecessarily re-defining all attributes within a new namespace. |
ARB_08 | The Schema 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. |
ARB_09 | The Schema Provider for an Attestation Rulebook SHALL specify, for each attribute in the attestation, whether the presence of that attribute is mandatory, optional, or conditional. |
ARB_10 | The Schema 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 also apply for domestic namespaces |
ARB_11 | The Schema 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 point a) and Annex VII point a) of the [European Digital Identity Regulation]. This attribute SHALL reference the technical specification meant in ARB_25. |
ARB_12 | The Schema 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 in an EAA. This attribute SHALL reference the technical specification meant in ARB_25. |
ARB_13 | The Schema 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 point b) of the [European Digital Identity Regulation]. |
ARB_14 | The Schema 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 point b) of the [European Digital Identity Regulation]. |
ARB_15 | The Schema 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 point b) of the [European Digital Identity Regulation]. |
ARB_16 | The Schema 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 point c) or Annex VII point c) of the [European Digital Identity Regulation]. |
ARB_17 | The Schema 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 point c) of the [European Digital Identity Regulation]. |
ARB_18 | The Schema 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 point e) or Annex VII point e) of the [European Digital Identity Regulation]. |
ARB_19 | The Schema 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 point e) of the [European Digital Identity Regulation]. |
ARB_20 | The Schema 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 point h) or Annex VII 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. |
ARB_21 | The Schema 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.Note: What this location indicates precisely is dependent on the nature of the mechanism used for distributing trust anchors; see requirement ARB_26. |
D. Miscellaneous requirements
Index | Requirement specification |
---|---|
ARB_22 | The Schema Provider for an Attestation Rulebook SHALL specify all technical details necessary to ensure interoperability, security, and privacy (including, possibly, an embedded disclosure policy as defined in Topic 43), of that attestation. Note: An Attestation Rulebook may also specify requirements regarding how the Wallet Unit must display the attestation and the attributes in it to the User. |
ARB_23 | The Schema 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 SHALL be supported by that attestation. |
ARB_24 | The Schema 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 SHALL be supported by that attestation. |
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 point a) and Annex VII 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. |
ARB_26 | The Schema Provider for an Attestation Rulebook describing a type of attestation that is an 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. |
ARB_27 | The Schema 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. Note: Relying Parties can only do so in a trustworthy manner if there is a proof of association between the attestation and the PID, in accordance with the requirements in Topic 18. |
A.2.3.13 Topic 13 - Developing a Wallet Unit architecture based on Secure Element
There are no HLRs for this Topic.
A.2.3.14 Topic 14 - Developing a Wallet Unit architecture based on External Token
There are no HLRs for this Topic.
A.2.3.15 Topic 15 - Developing a Wallet Unit architecture based on Remote HSM
There are no HLRs for this Topic.
A.2.3.16 Topic 16 - Signing documents with a Wallet Unit
Short description
A Wallet Unit SHALL enable its User to create qualified electronic signatures or seals. This goal can be reached by using signature or seal creation capabilities of the Wallet Unit as a part of a local QSCD, or by using a remote QSCD managed by a QTSP.
This Topic contains high-level requirements related to the creation of Qualified Electronic Signatures using a Wallet Unit.
HLRs
A. Requirement for Wallet Providers
Index | Requirement specification |
---|---|
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. |
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. *Notes: - Signature Creation Application (SCA): see definition in the ETSI TS 119 432 standard. -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. |
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. |
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. Note: 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. |
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. |
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. |
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 v.2. |
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). |
QES_09 | Empty |
QES_10 | Wallet Providers SHALL ensure that, where the Signature Creation Application is implemented as part of the Wallet Unit, the Wallet Unit presents the document or data to be signed or sealed to the User. |
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. |
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. Note: a local signing application is on-device. It may either be embedded in the Wallet Unit or be an external application. |
QES_13 | Wallet Providers SHALL ensure that a Wallet Unit provides a log of transactions related to qualified electronic signatures generated by or through the Wallet Unit, allowing the User to view the history of previously signed data or documents, according to the requirements in Topic 19. Note: 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. |
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. |
QES_15 | Wallet Providers SHALL ensure that a Wallet Unit can verify the registration of Qualified Trust Service Providers providing signatures services (in remote signature creation scenarios). |
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. |
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. Note: See also QES_17a. |
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. |
QES_18 | Wallet Providers SHALL configure at least one default qualified signing service in the Wallet Unit. |
QES_19 | Empty |
QES_20 | Empty |
QES_21 | Empty |
QES_22 | Empty |
B. Requirements for QTSPs
Index | Requirement specification |
---|---|
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). |
QES_24 | Empty |
C. Requirements for the Commission
Index | Requirement specification |
---|---|
QES_25 | Empty |
QES_26 | Empty |
A.2.3.17 Topic 17 - Identity matching
Short description
Users would like to use their PID in their Wallet Unit to access their existing online account(s), even if their PID attribute values are not exactly the same as those in their account(s). Users regularly need to log in to cross-border services offered by public sector bodies. Identity matching enables them to use their Wallet Unit to do so.
HLRs
There are no HLRs for this Topic.
A.2.3.18 Topic 18 - Combined presentations of attributes
Short description
This Topic discusses the combined presentation of attributes by a Wallet Instance to a Relying Party. 'Combined presentation' here refers to a transaction in which the Relying Party requests attributes of the same User from multiple attestations (PID and/or (Q)EAAs) in a single request and receives those attributes in a single response. These attestations can have been provided to the Wallet Unit by one or by multiple PID Providers or Attestation Providers.
This Topic answers the following questions:
- How can a Relying Party request for a combined presentation of attributes?
- How can a Wallet Unit receiving such a request present the attributes in a combined manner?
- How can the Relying Party verify the authenticity of all released attributes in a combined response?
- How can the Relying Party verify whether all released attributes were issued to the same User?
Regarding the last question:
- The subject may be either a natural person or a legal person.
- However, use cases such as delegation or legal representation, where the Relying Party may request attributes that are originally part of multiple distinct attestations that were not issued to the same User, are not combined presentations and are out of scope of this Topic.
Note to version 1.5.0: This Topic refers to a 'proof of association' repeatedly. For this concept, see Topic 9. This concept will be further discussed with Member States. As a result, the requirements mentioning proof of association may change in a future version of this document.
HLRs
A. Functional requirements for ecosystem components
Index | Requirement specification |
---|---|
ACP_01 | Wallet Units SHALL support the features in [ISO18013-5] and/or [OpenID4VP] (as applicable) that allow requesting and releasing attributes from multiple attestations in a single request and response. |
ACP_02 | Relying Parties SHOULD support the features in [ISO18013-5] and/or [OpenID4VP] (as applicable) that allow requesting and releasing attributes from multiple attestations in a single request and response. |
ACP_03 | Empty |
ACP_04 | If a Wallet Unit determines it must release multiple attestations to a Relying Party in a combined presentation of attributes, it SHALL request a proof of association between the public keys of these attestations from the WSCA. |
ACP_05 | If (as a result of ACP_04), the Wallet Unit receives a proof of association from the WSCA, it SHALL include this proof in the response message containing the combined presentation of attributes and send it to the Relying Party. |
ACP_06 | If a Relying Party receives a combined presentation of attributes including a proof of association, it SHOULD verify this proof to validate that the attestations in this presentation were issued to the same User. |
B. Process requirements
Index | Requirement specification |
---|---|
ACP_07 | During issuance of a (Q)EAA, an Attestation Provider SHALL be able to request the association of the new (Q)EAA to a PID or another (Q)EAA already existing on the Wallet Unit, provided that the Attestation Provider has verified during the issuance process that the new (Q)EAA indeed belongs to the User of that existing PID or (Q)EAA. Note: Also see requirement WUA_13 in [Epic 09]. |
ACP_08 | When receiving a combined presentation of attributes, a Relying Party SHOULD NOT refuse any attestation solely because a proof of association between these attestations is absent. |
C. Miscellaneous
Index | Requirement specification |
---|---|
ACP_09 | The common [ISO18013-5] and [OpenID4VP] protocols, or an EUDI Wallet-specific extension or profile thereof, SHALL enable a Wallet Unit to transfer a proof of association to a Relying Party. The Commission SHALL take measures to ensure that this is the case. |
A.2.3.19 Topic 19 - User navigation requirements (Dashboard logs for transparency)
Short description
In this use case, the User is accessing a dashboard of the Wallet Unit, which provides a record of all transactions executed through the Wallet Unit. The User is concerned about data privacy, and thus the function of a dashboard ensures a higher degree of transparency, privacy and control of the User over their personal data.
This Topic lists high-level requirements related to the functions of such a dashboard.
HLRs
Index | Requirement specification |
---|---|
DASH_01 | A Wallet Provider SHALL enable a User to access a dashboard functionality in their Wallet Unit. |
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: presentation transactions,signature creation transactions (see Topic 16),attribute deletion requests sent to a Relying Party (see Topic 48),complaints lodged with a Data Protection Authority (see Topic 50). Note: For the data to be logged for an attribute deletion request or a complaint, see Topic 48 and Topic 50, respectively. |
DASH_02a | The Wallet Unit SHALL retain transactions in the log at least for the time 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 and SHALL instruct the User how to export the transactions that are about to be deleted; see DASH_07. |
DASH_02b | The dashboard SHALL include a functionality to display to the User an overview of all transactions in the log. |
DASH_03 | For a presentation transaction executed through the Wallet Unit, the dashboard SHALL display to the User at least: the date and time of the transaction,the corresponding Relying Party or requesting Wallet Unit,the document type(s) requested and/or presented the identifier(s) of the attribute(s) requested and/or presented. |
DASH_04 | For a signature creation transaction executed through the Wallet Unit, the dashboard SHALL display to the User at least: the date and time of the transaction, the document or data signed (where possible) |
DASH_05 | Empty |
DASH_06 | The Wallet Provider SHALL ensure the integrity of all transactions included in the log. |
DASH_06a | Via the dashboard, the Wallet Unit SHALL enable the User to delete any transaction in the log. The Wallet Unit SHALL ensure that no other party can delete transactions from the log, except possibly for the reason mentioned in DASH_02a. |
DASH_07 | The dashboard SHALL allow the User to export the details of one or more transactions in the log to a file. |
DASH_08 | For a natural-person User, a Wallet Instance SHALL provide a User interface. |
DASH_09 | The User interface referred to in DASH_08 SHALL display an EU Digital Identity Wallet Trust Mark complying with technical specifications. Note: The Commission will develop technical specifications for this Trust Mark. |
DASH_10 | Empty |
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. |
DASH_12 | The User interface referred to in DASH_08 SHALL enable the User, for each presentation transaction in the dashboard, to easily request the Relying Party to delete any or all attributes presented to it in that transaction, or to lodge a complaint about that particular transaction to a DPA. |
A.2.3.20 Topic 20 - Strong User (Customer) authentication in the context of electronic payments
Short description
This topic deals with the requirement for Strong User (Customer) Authentication (SCA) in the context of authenticating a User as part of electronic payments.
Users would like to be able to authenticate themselves during online payments securely and conveniently using their Wallet Units, so that they can enjoy a seamless and protected shopping/ payment experience.
The goal is to implement Strong Customer Authentication (SCA) for electronic payments, ensuring a high level of security and compliance with Article 97 of the PSD2 (and with the future PSD3/PSR).
Commission Delegated Regulation (EU) 2018/389 lays down the requirements for strong customer authentication (SCA), which needs to be complied with when accessing a payment account online and for initiating electronic payments, or carrying out any action through a remote channel which may imply a risk of payment fraud or other abuses. The use of the wallet for SCA will be in full compliance with those requirements.
In the future, a Wallet Unit could also be used for payments with Central Bank Digital Currencies.
HLRs
There are no HLRs for this Topic.
A.2.3.21 Topic 21 - Diplomas within the EUDI Wallet ecosystem
There are no HLRs for this Topic.
A.2.3.22 Topic 22 - Digital Travel Credentials within the EUDI Wallet ecosystem
There are no HLRs for this Topic.
A.2.3.23 Topic 23 - PID issuance and (Q)EAA issuance
Short description
See Topic 10.
HLRs
See Topic 10.
A.2.3.24 Topic 24 - User identification in proximity scenarios
Short description
In this use case, the User is using their Wallet Unit for identification purposes in proximity scenarios. As explained in Section 4.4.1 of [ARF], in a proximity flow, the User and their Wallet Instance are physically near the Relying Part Instance. PIDs and attestations are exchanged using proximity technology (e.g., NFC, Bluetooth) between the Wallet Unit and the Relying Party Instance. Note that this definition does not imply that a Wallet Unit and a Relying Party have to use proximity technologies if they are close together. They are free to use a remote flow (acording to Topic 1). However, there may be situations where either the Wallet Unit or the Relying Party Instance does not have an internet connection. In such cases, they must be able to use a proximity flow, if they are close together.
The User is concerned about sharing personal data in proximity, while the User's objectives include identifying themselves to services requiring User identification and maintaining control over their personal data sharing.
This topic lists high-level requirements related to User identification in proximity use cases where Users utilise their Wallet Units.
HLRs
Index | Requirement specification |
---|---|
ProxId_01 | For enable identification using proximity flows, Wallet Units and Relying Party Instances SHALL support device retrieval as specified in ISO/IEC 18013-5 for requesting and presenting PID, attestation, or WUA attributes. |
ProxId_02 | Wallet Solutions, 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, attestation, or WUA attributes. Note: 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. |
ProxId_03 | A Wallet Unit SHALL present the presentation request and the identity of the Relying Party to the User when processing the request. |
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. |
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. |
ProxId_06 | Empty |
A.2.3.25 Topic 25 - Unified definition and controlled vocabularies for attributes
Short description
Topic 12 that describes the high-level requirements (HLR) for the minimal requirements Rulebooks that will specify the details of new types of attestations, including QEAAs, PuB-EAAs, and non-qualified EAAs, has already touched and defined high-level requirements regarding the attestation rulebook catalogue.
The following main concepts were defined in Topic 12 and developed in the current version of this Topic:
- Attestation Rulebooks for QEAAs and PuB-EAAs used within the EUDI Wallet ecosystem may be registered and published in a publicly accessible catalogue.
- The Attestation Rulebook catalogue may also include Attestation Rulebooks for non-qualified EAAs.
- The Commission will take measures to establish and maintain the Attestation Rulebooks catalogue.
- The Attestation Rulebooks catalogue will enable mainly Relying Parties, but also other actors in the EUDI Wallet ecosystem, to know which attestation types exist, and what is the identifier, syntax, and semantics of each attribute in a type of attestation.
The following points are emphasised:
- Registration of an Attestation Rulebook in the attestation catalogue is not mandatory.
- Registration in the Attestation Rulebook catalogue does not create any obligation of acceptance of the attestation by any Relying Party, nor does it necessarily imply cross-border recognition of that attestation.
- The Attestation Rulebooks catalogue can be hosted in the same environment as the catalogue of attributes.
HLRs
Index | Requirement specification |
---|---|
CAT_01 | The Commission SHALL establish a catalogue of attributes used within the EUDI Wallet ecosystem. Note: The catalogue of attributes does not need to be a separate catalogue, but could be combined with the Attestation Rulebooks catalogue mentioned in CAT_05. |
CAT_01a | The Commission SHALL enable any entity to request the registration in the catalogue of one or more attribute(s) of an attestation used within the EUDI Wallet ecosystem. |
CAT_01b | The Schema Provider for an Attestation Rulebook that is a QEAA or PuB-EAA SHOULD request the registration of all attributes in that QEAA or PuB-EAA in the catalogue of attributes. The Schema Provider for an Attestation Rulebook that is a non-qualified EEA MAY request the registration of the attributes in that EAA in the catalogue. |
CAT_02 | Empty |
CAT_03 | The Commission SHALL make the catalogue of attributes publicly available and machine-readable. Note: The requirement for availability implies setting up the required means for high availability and avoiding a single point of failure. |
CAT_03b | The Commission SHALL consider the following semantic artifacts for inclusion in the catalogue of attributes: Representation Powers and Mandates (RPaM) OntologySEMPER | DE4ASEMIC Core VocabulariesIANA Registry for JSON Web Token Claims (for JSON-based attributes only)ISO/IEC 23220-2 (for CBOR-based attributes only) |
CAT_04 | The Commission SHALL make publicly available the existence and maintenance of the catalogue of attributes mentioned in CAT_01, including processes to propose the registration to public and private parties, allowing to register attributes, and conditions for updating and/or removing attributes. These processes SHALL include archiving and logging changes of the history of the catalogue of attributes in an appropriate way, including versioning. Note: There are layers on top of the attributes that need maintenance as well. So, maintenance in this case is more generic and encompasses more than just the attribute itself. |
A.2.3.26 Topic 26 - Catalogue of attestations
Short description
See Topic 25.
HLRs
Index | Requirement specification |
---|---|
CAT_05 | The Commission SHALL establish a catalogue of Attestation Rulebooks used within the EUDI Wallet ecosystem. Note: For Attestation Rulebooks, see Topic 12. |
CAT_05a | The Commission SHALL enable any entity to register an Attestation Rulebook used within the EUDI Wallet ecosystem. |
CAT_05b | The Schema Provider for an Attestation Rulebook that is a QEAA or PuB-EAA SHOULD register its Rulebook in the catalogue of Attestation Rulebooks. The Schema Provider for an Attestation Rulebook that is a non-qualified EEA MAY register its Rulebook. |
CAT_06 | The Commission SHALL make the catalogue publicly available and machine-readable, by hosting the catalogue, or parts of it, including an e-discovery mechanism and/or by referencing to other catalogues. Note: The requirement for availability implies setting up the required means for high availability and avoiding a single point of failure. |
CAT_07 | The Commission SHALL enable a self-registration process of Attestation Rulebooks, without pre-approval by the registry, for both public and private entities. |
CAT_08 | The Commission SHALL specify and make publicly available three (3) Rulebooks for the following generic types of Attestations -- QEAA, PuB-EAA, and non-qualified EAA. |
CAT_09 | The Commission SHALL make publicly available the existence and maintenance of the Attestation Rulebooks catalogue mentioned in CAT_01, including processes to propose the registration to public and private parties, allowing to register an Attestation Rulebook, and conditions for updating and/or removing Attestation Rulebooks. These processes SHALL include archiving and logging changes of the history of the Attestation Rulebooks catalogue in an appropriate way, including versioning. |
CAT_10 | The body registering an Attestation Rulebook SHALL include a unique reference to this body and the way to contact it, or how to find information for doing so. Notes: Topic 12 describes an option for Member State-specific (i.e., domestic) Rulebooks, extending a EU-wide Rulebook. Rulebooks MAY be shared between interested parties in an out-of-band manner. |
CAT_11 | Empty |
A.2.3.27 Topic 27 - Registration of PID Providers, Providers of QEAAs, PuB-EAAs, and (non-qualified) EAAs, and Relying Parties
Short description
PID Providers, QEAA Providers, PuB-EAA Providers, (non-qualified) EAA Providers and Relying Parties SHALL register with a Registrar in their Member State. The main goal of the registration process is for the entity to receive an access certificate that Wallet Units can use to authenticate them.
This Topic specifies high-level requirements related to the registration of the abovementioned entities.
HLRs
A. General requirements for Member State registration processes
Index | Requirement specification |
---|---|
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. Note: Member States may choose to implement a single registry for all these roles, or a separate registry for each of these roles. |
Reg_02 | Member States SHALL make publicly available all necessary details and documentation about the registration processes for their registry. |
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 [European Digital Identity Regulation] Article 5b 5, for the purpose of transparency to Users and other stakeholders. |
Reg_04 | Member States SHALL make the registry available online, in a common human-readable format. |
Reg_05 | The Commission SHALL establish a technical specification for the common formats mentioned in Reg_03 and Reg_04. |
Reg_06 | The Commission SHALL provide specifications for a common API for retrieving registry entries from the Member States registries per Reg_03, defining the minimum requirements for interoperability. Note: Requirements for this API are defined in Reg_08 and Reg_09. |
Reg_07 | The Commission SHALL provide specifications for a common user interface for accessing the Member State registries per Reg_04. Note: Requirements for this user interface are defined in Reg_08 and Reg_09. |
Reg_08 | The API mentioned in Reg_06 and the user interface mentioned in Reg_07 SHALL use a secure channel protecting the authenticity and integrity of the information in the registry during transport. |
Reg_09 | The API mentioned in Reg_06 and the user interface mentioned in Reg_07 SHALL NOT require authentication or prior registration and authorisation of any entity wishing to retrieve the information in the registry. |
B. General requirements for the issuance of access certificates
Index | Requirement specification |
---|---|
Reg_10 | A Member State SHALL ensure that an Access Certificate Authority notified according to [Topic 31] issues an access certificate to all PID Providers, QEAA Providers, PuB-EAA Providers, (non-qualified) EAA Providers, and Relying Parties registered in one of the Member State's registries. |
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 Authoritys. |
Reg_12 | The Commission SHALL provide technical specifications establishing the common Access Certificate Authority Certificate Policy mentioned in Reg_11. |
Reg_13 | The common Certificate Policy mentioned in Reg_12 SHALL require that an Access Certificate Authority logs all issued certificates for Certificate Transparency (CT).Note added to ARF 1.5.0: This requirement is still under discussion and might be changed or removed in a future version of this ARF. |
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. |
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 de-registered by the respective Registrar,the certificate subject which is a PID Provider, QEAA Provider, PuB-EAA Provider, or (non-qualified) EAA Provider is withdrawn or suspended by the respective Registrar, on request of the certificate subject, or on request of a competent national authority. |
Reg_16 | The common Certificate Policy mentioned in Reg_12 SHALL specify the profile of access certificates in detail. |
Reg_17 | The common Certificate Policy mentioned in Reg_12 SHALL require that an access certificate indicates whether its subject is a PID Provider, a QEAA Provider, a PuB-EAA Provider, a (non-qualified) EAA Provider, or a Relying Party Instance. |
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. |
C. Requirements for the registration of PID Providers
Index | Requirement specification |
---|---|
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. |
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. |
Reg_20a | A Registrar SHALL provide a method to suspend or withdraw a registered PID Provider. |
Reg_20b | A Registrar SHALL have a policy for the suspension or withdrawal of a registered PID Provider, which SHALL specify that a PID Provider is suspended or withdrawn at least on request of the PID Provider or of a competent national authority. |
D. Requirements for the registration of Attestation Providers
Index | Requirement specification |
---|---|
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. |
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. |
Reg_22a | A Registrar SHALL provide a method to suspend or withdraw a registered Attestation Provider. |
Reg_22b | A Registrar SHALL have a policy for the suspension or withdrawal of a registered Attestation Provider, which SHALL specify that an Attestation Provider is suspended or withdrawn at least on request of the PID Provider or of a competent national authority. |
E. Requirements for the registration of Relying Parties
Index | Requirement specification |
---|---|
Reg_23 | The Commission SHALL establish a technical specification for a common set of Relying Party information to be registered in Member State registries. This set SHALL include at least the information defined in [European Digital Identity Regulation] article 5b 2 (c). |
Reg_24 | A Member State SHALL enable a Relying Party to register remotely, using an API or user interface. |
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. |
Reg_26 | A Member State SHALL enable a Relying Party to update the information registered on it using a process comparable to the original registration process, and using the API or user interface mentioned in Reg_24. |
Reg_27 | Relying Parties SHALL make any updates necessary to ensure the continued correctness of the registered information without undue delay. |
Reg_28 | A Member State's Registry SHALL log all changes made on the information regarding a Relying Party, including at least initial registration, updates, deletion of information, and suspension or withdrawal. |
Reg_29 | A Registrar SHALL have a policy for the withdrawal of a registered Relying Party, which SHALL specify that a Relying Party is withdrawn at least on request of the Relying Party or of a competent national authority. |
Reg_30 | Empty |
F. Requirements for the issuance of Relying Party Instance access certificates
Index | Requirement specification |
---|---|
Reg_31 | The common Certificate Policy mentioned in Reg_12 SHALL require that a Relying Party Instance access certificate contains a name for the Relying Party, in a format suitable for presenting to a User. Note: A Wallet Unit needs such a name when requesting User approval according to [Topic 6]. |
Reg_32 | The common Certificate Policy mentioned in Reg_12 SHALL require that a Relying Party Instance access certificate contains an EU-wide unique identifier for the Relying Party, and SHALL specify a method for deriving such identifiers. Notes: - The Wallet Instance needs such an identifier at least to lodge a complaint of suspicious Relying Party presentation requests to a data protection authority according to Topic 50. - 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. - This Relying Party identifier is identical in all Relying Party Instance access certificates issued to a given Relying Party. |
A.2.3.28 Topic 28 - Wallet Unit for legal persons
Note to this Topic in version 1.5.0: Legal-person PIDs and Wallet Units for legal persons were added to the list of topics to be discussed with Member States in the future. In ARF 1.5.0., no changes were made to this Topic.
Short description
This topic is focused on identifying high-level requirements for a legal-person Wallet Unit. All core capabilities of a Wallet Unit for a natural person are available for a legal person. There are some differences between a natural and legal person that accordingly leads to different requirements for issuing legal-person PIDs and the Wallet Units containing legal-person PIDs.
Notes:
- A legal-person PID is issued under an eID scheme.
- A legal-person PID is described in a legal-person PID Rulebook, which is different from the natural-person PID Rulebook in [PID Rulebook]. A legal-person PID has a different attestation type than a natural-person PID, and also contains different attributes. For example, date of birth or age are not relevant information for legal persons. Specifying a different Rulebook for legal-person PIDs allows Relying Parties and other Wallet Units to request these attributes.
- A legal-person Wallet Solution may be implemented in the same manner as a natural-person Wallet Solution, meaning chiefly that it is implemented on a mobile device operated by a single User, who is a natural person. However, a legal-person Wallet Solution may also be implemented as a server-based (web-based) application. In the latter case, a Wallet Unit can be used either by one or more natural persons appointed by the legal person, or by information systems of the legal persons that give an Wallet Unit commands in accordance with rules defined by the legal person.
HLRs
Index | Requirement specification |
---|---|
LP_01 | The Commission SHALL develop a Legal-person PID Rulebook to specify the attribute scheme and other technical details applicable for legal-person PIDs. |
LP_02 | The attestation type of a legal-person PID SHALL be different from the attestation type of a natural person PID. Note: See [Topic 12] for an explanation of the concept of attestation type. |
LP_03 | A legal-person PID SHALL comply with all requirements in the Legal-person PID Rulebook mentioned in LP_02. |
A.2.3.29 Topic 29 - Delegation paradigm
Short description
Topic 3 describes requirements for a rulebook of natural-person PIDs. Topic 28 does the same for legal-persons PIDs.
Article 5a.5.(f) of the [European Digital Identity Regulation] also mentions the possibility of issuing eIDs that also could attest a natural person representing the natural or legal person. At current time, this Topic proposes to not describe any requirements for such eID schemes without further Member State input for such eID schemes. The main reason is that there is no cross-border legal framework for mutual recognition of powers and mandates. Powers and mandates are generally legal system-specific and administrative system-specific.
Another use case for delegation is where the recognition of the power for a person to represent another person occurs on an ad hoc basis, based on a decision by the represented User and in the context of a specific Relying Party. The basis for such decisions is outside of the scope of eIDAS. Various scenarios can be considered:
- Natural person to natural person, based on the will of the
represented person: One individual authorises another individual to
represent them, for example:
- Picking up a prescription from the pharmacy or a package from the post office for a family member.
- Empowering a person to vote on your behalf.
- Empowering a notary to sell your house on your behalf to a certain party for a certain amount.
- Empowering your employer to apply for a residence permit on your behalf.
- Natural person to natural person, based on some decision by an authority, or also as a consequence of national, EU or international law.
- Legal guardian being able to take decisions on behalf of child, disabled person, or elderly person.
- Natural person to legal person: An individual authorising a legal
entity to represent them.
- A person empowering a law firm to be the executor of the trust upon their death.
- A person empowering a bank to invest on their behalf.
HLRs
There are no specific requirements in this Topic.
A.2.3.30 Topic 30 - Interaction between Wallet Units
Short description
A User can request another User to release an attestation of attributes, where both Users use their Wallet Unit. This can be done when their devices are close together (that is, in physical proximity) with internet connectivity for both devices (online), or without internet connectivity for either or both devices (offline).
This Topic lists the high-level requirements related to the interaction between two Wallet Units. This topic will be further discussed with Member States.
HLRs
Index | Requirement specification |
---|---|
W2W_01 | A Wallet Unit SHALL support an interface and protocol for: - Establishing a connection with another Wallet Unit, - Receiving PID and (Q)EAA presentation requests from another Wallet Unit, - Validating such requests, - Responding to such requests in accordance with the technical specifications as defined by [OpenID4VP] and [ISO/IEC 18013-5]. |
W2W_01a | In addition to W2W_01, a Wallet Unit SHALL support an interface and protocol for: - Sending PID and (Q)EAA presentation requests to another Wallet Unit, - Receiving and validating the corresponding presentation response, in accordance with the technical specifications as defined by [OpenID4VP] and [ISO/IEC 18013-5]. |
W2W_02 | The Commission SHALL develop technical specifications for exchanging PIDs and attestations between two Wallet Units in accordance with the technical specifications as defined by [OpenID4VP] and [ISO/IEC 18013-5]. |
W2W_03 | The Requestor Wallet Unit SHALL authenticate its User prior to requesting attestations presentation from another Wallet Unit. |
W2W_04 | The Requestee Wallet Unit SHALL request User approval, as specified in [Topic 6], before presenting requested attestations or attributes to another Wallet Unit. The Wallet Unit SHALL inform the User about the attributes that are being requested, and of the outcome of authentication and validation checks of the request and the requestor. |
W2W_05 | The Requestor Wallet Unit SHOULD have pre-defined a list of attributes of PID or attestations that can be requested from the Requestee Wallet Unit. |
W2W_06 | The Requestee Wallet Unit SHALL authenticate and validate the Requestor Wallet Unit, ensuring the validity of the Requestor Wallet Unit and the attribute request. |
W2W_07 | The Requestor Wallet Unit SHALL display the received attributes to its User. |
A.2.3.31 Topic 31 - PID Provider, Wallet Provider, Attestation Provider, and Access Certificate Authority notification and publication
Short description
PID Providers, PuB-EAA Providers, Wallet Providers and Access Certificate Authorities must be notified by a Member State to the Commission. As part of the notification process, the trust anchors of these parties must be included in a Trusted List. A trust anchor is the combination of a public key and an identifier for the associated entity. Trust anchors are required for the verification of the signatures of PIDs, attestations, WUAs, and access certificates that are issued by these parties.
This Topic contains High-Level Requirements for the notification of these parties by Member States, and for the publication of the notified information by the Commission.
HLRs
A. Generic requirements for notification
Index | Requirement specification |
---|---|
GenNot_01 | The European Commission SHALL establish technical specifications for a common system enabling the notification of PID Providers, PuB-EAA Providers, Wallet Providers, and Access Certificate Authorities by Member States to the Commission. Note: Notification does not apply to QEAA Providers and (non-qualified) EAA Providers, as explained in Sections D and F below, respectively. |
GenNot_02 | As part of the specifications 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 or Access Certificate Authorities to the Commission. Note: The outcome of the notification procedure is the publication of the information notified by the Member State according to Article 5a (18) in a machine and human readable manner using the common system mentioned in Section H, TLPub_01. |
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. |
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. |
GenNot_05 | As part of the specifications referred to in GenNot_01, the European Commission SHALL establish standard operating procedures for the suspension or withdrawal of a PID Provider, PuB-EAA Provider, Wallet Provider, or Relying Party Access Certificate Authority. These operating procedures SHALL include unambiguous conditions for suspension or withdrawal. As an outcome of the suspension or withdrawal procedure, the status of the suspended or withdrawn PID Provider, PuB-EAA Provider, Wallet Provider, or Relying Party Access Certificate Authority in the Trusted List SHALL be changed to Invalid. |
B. Requirements for the notification of PID Providers
Index | Requirement specification |
---|---|
PPNot_01 | The European Commission SHALL establish technical specifications for the common set of information to be notified about PID Providers. |
PPNot_02 | The common set of information to be notified about a PID Provider SHALL include: 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. PID Provider Access Certificate Authority trust anchors, 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. Notes: - Relating to point 3. above: PID Provider Access Certificate Authority trust anchors are notified separately from the Relying Party Access Certificate Authority (see Section G below), since PID Providers are -legally speaking- not Relying Parties. - For the concept of an Access Certificate Authority, see also [Topic 27] and Section 6.3.2 of [ARF]. |
PPNot_03 | PID Providers SHALL ensure that all PIDs they issue can be authenticated using the PID Provider trust anchors notified to the Commission. |
PPNot_04 | PID Providers SHALL ensure that their PID Provider access certificates can be authenticated using the PID Provider Access Certificate Authority trust anchors notified to the Commission. Note: [Topic 6] describes how access certificates will be used. |
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. |
PPNot_06 | PID Provider 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 PID Provider Access Certificate Authority Trusted List which is signed or sealed by the Commission. |
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. |
C. Requirements for the notification of Wallet Providers
Index | Requirement specification |
---|---|
WPNot_01 | The European Commission SHALL establish technical specifications for the common set of information to be notified about 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. Notes: - See [Topic 9] and [Topic 38] for the definition of the WUA. - A Wallet Provider does not need an access certificate to interact with Wallet Units. |
WPNot_03 | Wallet Providers SHALL ensure that all WUAs they issue can be authenticated using the trust anchors notified to the Commission. |
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. |
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. |
WPNot_06 | If a Wallet Provider is withdrawn (see requirement GenNot_05 above), that Wallet Provider SHALL immediately revoke all of its valid WUAs, in accordance with the requirements in Topic 38. If a Wallet Provider is suspended, that Wallet Provider and the Member State SHALL agree on the necessary precautionary measures that need to be taken, which MAY include the immediate revocation of all or some of its valid WUAs. |
D. Requirements for the notification of QEAA Providers
There is no notification of QEAA Provider foreseen by the [European Digital Identity Regulation], except for establishing the Art. 22 Trusted List once a qualified status is granted. QTSPs issuing QEAAs to Wallet Units SHALL abide by the Implementing Act to be adopted under Art. 45d(5).
E. Requirements for the notification of PuB-EAA Providers
This notification is pursuant to Art.45f(3) and to the implementing acts to be adopted pursuant to Art.45f(7). It should be noted that the purpose of this notification is mainly to the attention of QTSPs issuing qualified certificates for electronic signatures or seals to those public sector bodies referred to in Article 3, point (46), and identified as the issuer in the PuB-EAA. The Trusted List compiled by the Commission is deemed to be a constitutive list of such Art.3(46) bodies recognised for issuing PUB-EAAs. Consequently, QTSPs are expected to verify such lists prior to issuing a qualified certificate to any entity claiming to be a Art.3(46) body.
Index | Requirement specification |
---|---|
PuBPNot_01 | The European Commission SHALL establish technical specifications for the common set of information to be notified about 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 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. |
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. |
F. Requirements for the notification of (non-qualified) EAA Providers
There is no notification of (non-qualified) EAA Providers foreseen by the [European Digital Identity Regulation]. As stated in [Topic 12], the Schema Provider for an Attestation Rulebook describing a type of attestation that is an EAA defines in the Rulebook the mechanisms allowing a Relying Party to obtain, in a trustworthy manner, the trust anchor(s) of EAA Providers issuing this type of EAA.
G. Requirements for the notification of Access Certificate Authorities
Relying Party Access Certificate Authorities (CA) are TSPs responsible for signing access certificates they issue to Relying Parties. Legally speaking, Relying Parties in this context also include QEAA Providers, PuB-EAA Providers, and (non-qualified) EAA Providers, but for clarity these roles are mentioned separately in the requirements below. Where these requirements use the term 'Access Certificate Authorities' without further qualifications, this includes Access Certificate Authorities for QEAA Providers, PuB-EAA Providers, (non-qualified) EAA Providers, and Relying Parties.
For more information about Relying Party Access Certificate Authoritys, see [Topic 27].
Index | Requirement specification |
---|---|
RPACANot_01 | The European Commission SHALL establish technical specifications for the common set of information to be notified about Relying Party Access Certificate Authorities, QEAA Provider Access Certificate Authorities, PuB-EAA Provider Access Certificate Authorities, and (non-qualified) EAA Provider Access Certificate Authorities. |
RPACANot_02 | The common set of information to be notified about an Access Certificate Authority 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, - Identification data from that official record. 2. Access Certificate Authority trust anchors, i.e., public keys and name as per point 1) ii), supporting the authentication of Relying Parties, QEAA Providers, PuB-EAA Providers, and (non-qualified) EAA Providers by Wallet Units. |
RPACANot_03 | Relying Parties, QEAA Providers, PuB-EAA Providers, and (non-qualified) EAA Providers SHALL ensure that their access certificates can be authenticated using the Access Certificate Authority trust anchors notified to the Commission. |
RPACANot_04 | 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. |
RPACANot_05 | The format of an Access Certificate Authority Trusted List SHALL comply with ETSI TS 119 612 v2.1.1 or with a suitable profile similarly derived from ETSI TS 102 231. |
H. Requirements for the publication of Trusted Lists compiled by the Commission
Index | Requirement specification |
---|---|
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, and Relying Party Access Certificate Authorities. |
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, andAccess Certificate Authorities based on the information notified by the Member States. Note: 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. |
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. |
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. |
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. |
TLPub_06 | The Commission SHALL publish in the OJEU the locations of the Trusted Lists for PID Providers, Wallet Providers, PuB-EAA Providers, and Access Certificate Authorities. |
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. |
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, and Access Certificate Authorities. |
A.2.3.32 Topic 32 - PID interoperability
See Topic 12.
A.2.3.33 Topic 33 - Wallet Unit backup and restore
Short description
Backup and restore functionality is needed in case the User has lost access to their current Wallet Unit, for example in case of loss, theft, or breakdown. It is also needed if the User wants to start using another Wallet Unit, for example because they have bought a new device, need to factory-reset their existing device, or want to migrate to another Wallet Solution. In all of these cases, the User wants to restore the PIDs and attestations in their existing Wallet Unit on their new Wallet Unit, with as minimal an effort as possible.
The [European Digital Identity Regulation] does not contain a requirement mandating backup and restore functionality in the Wallet. However, Wallet Providers should implement backup and restore functionality nevertheless, because it will be expected by Users. In fact, the requirements in Topic 34 also ensure the possibility of backup and restore.
HLRs
There are no specific requirements in this Topic.
A.2.3.34 Topic 34 - Migrate to a different Wallet Solution
Short description Article 5a 4 (g) of the [European Digital Identity Regulation] ensures the User's rights to data portability. Data portability means that a User can migrate to a different Wallet Solution. The User installs an instance of the new Wallet Solution, and then wants to restore the PIDs and attestations in their existing Wallet Unit to their new Wallet Unit. This should be possible with as minimal an effort as possible, and independent of whether the User still has access to their existing Wallet Unit.
The solution described in this Topic is to introduce a Migration Object in each Wallet Unit. This object is a list of PIDs and attestations contained in the Wallet Unit, together with the information needed to request (re-)issuance of that PID or attestation. Note that the Migration Object does not contain any private keys associated with the PIDs or attestations. In most security architectures for a Wallet Solution described in Section 4.5 of [ARF], this is impossible, since the WSCA/WSCD that contains these private keys does not allow their extraction under any circumstances. An exception may be architectures in which attestation private keys are managed in a remote HSM and the migration is to a new Wallet Unit of the same Wallet Provider. However, in such cases, restoring functionality of the PIDs and attestations in a new Wallet Unit does not necessitate that private keys must be exported to another HSM. Rather, it implies the User must be able to authenticate towards the existing HSM from the new Wallet Unit, and be recognised as an existing User.
The fact that the Migration Object does not contain private keys means that PIDs and attestations cannot be backed up and restored from the object in such a way that they are usable in a new Wallet Unit without involvement of the PID Provider or Attestation Provider. Instead, the User must ask the respective PID Provider(s) or Attestation Provider(s) to re-issue the PID(s) or attestation(s) to the new Wallet Unit. The only function of the Migration Object is to simplify this process by listing the PIDs and attestations present in the existing Wallet Unit, together with the information needed by the new Wallet Unit to start the re-issuance process.
The Migration Object does not contain attribute values or attribute identifiers, as that data is considered sensitive and is not useful anyway because of the limitations explained above. Instead, the object only contains a list of attestation types and the related Attestation Providers. However, even this limited information may be considered sensitive in some cases. Therefore, the Migration Object is stored in such a way that its confidentiality is ensured and that it can be used only by the User.
HLRs
A. Back-up requirements
Index | Requirement specification |
---|---|
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 present in the Wallet Unit, according to the requirements in this Topic. |
Mig_02 | The Commission SHALL define a technical specification of the Migration Object. |
Mig_03 | For each PID or attestation that is issued to it, a Wallet Unit SHALL add all data that is necessary to request re-issuance of that PID or attestation to the Migration Object. 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 associated with the PID or attestation. |
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. |
Mig_04 | The Wallet Unit SHALL store the Migration Object in an external storage or remote location of the User's choice, 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. Note: 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 Unit. |
Mig_05 | The Wallet Unit SHALL store the Migration Object in such a way that its confidentiality is protected and that it is protected against use by others than the User. Note: This could be done, for example, by using password-based cryptography to encrypt the object. |
B. Restore Requirements
Index | Requirement specification |
---|---|
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 location indicated by the User. |
Mig_07 | For each PID and attestation listed in the Migration Object, the Wallet Unit SHALL enable the User to select that PID or attestation. When selected, the Wallet Unit SHALL request the respective PID Provider or Attestation Provider to re-issue that PID or attestation. If the Migration Object lists a PID, the PID SHALL be the first to be restored. |
Mig_07a | 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. |
Mig_08 | Empty |
Mig_09 | Empty |
Mig_10 | Empty |
Mig_11 | The processes and interfaces used for re-issuance of a PID or attestation (as part of a migration process) SHALL be the same as those used for their issuance, as specified in Topic 10. |
Mig_12 | Empty |
Mig_13 | Empty |
Mig_14 | Empty |
Mig_15 | Empty |
Mig_16 | Empty |
A.2.3.35 Topic 35 - PID issuance service blueprint
Short description
This Topic analyses the meaningful User journeys for PID issuance to a Wallet Unit. This Topic focuses on natural persons only and lists high-level requirements related to the PID issuance user journey, covering both remote and proximity use cases.
HLRs
Index | Requirement specification |
---|---|
PID_ISS_01 | A Wallet Unit SHALL support at least the protocol defined in the technical specifications for PID issuance. A Wallet Unit MAY support additional protocols for PID issuance. The following requirements apply only to the protocol defined in the technical specifications. |
PID_ISS_02 | A Wallet Unit SHALL authenticate and validate the identity of the PID Provider it is communicating with. |
PID_ISS_03 | A PID Provider SHALL verify the authenticity of Wallet Unit's WUA. |
PID_ISS_04 | A Wallet Unit SHALL present the corresponding data to the User, informing the User about the attributes to be issued by the PID Provider. |
PID_ISS_05 | Empty |
PID_ISS_06 | A Wallet Unit SHALL support device binding for PID, enabling the User to prove possession of the bound device. |
PID_ISS_07 | A Wallet Unit SHALL support an activation procedure for PID Providers to verify that a PID is delivered to its subject. |
PID_ISS_08 | A Wallet Unit SHALL support technical specifications for securely delivering the PID from the PID provider to the device controlled by the User. |
PID_ISS_09 | Empty |
A.2.3.36 Topic 36 - Risk Analysis of the Wallet usage
There are no HLRs for this Topic.
A.2.3.37 Topic 37 - QES -- Remote Signing - Technical Requirements
See Topic 16.
A.2.3.38 Topic 38 - Wallet Unit revocation
Short description
This Topic discusses Wallet Unit revocation. In particular, it answers the following questions:How can a Wallet Provider revoke a Wallet Unit?During issuance of an attestation, how can an Attestation Provider verify whether a Wallet Unit has been revoked?When requesting attributes from an attestation, how can a Relying Party verify whether a Wallet Unit has been revoked?
In case of a security issue, Article 5e of the [European Digital Identity Regulation] requires Wallet Providers to first suspend a Wallet Unit and to revoke it only if the issue cannot be solved within three months. However, the suspension of a Wallet Unit is an administrative process, which does not imply that the WUAs of that Wallet Unit need to be suspended, as opposed to being revoked. Instead, if the Wallet Provider administratively suspends a Wallet Unit, it will immediate revoke all corresponding WUAs. If (within three months) the situation is remedied and the Wallet Unit can be re-instated, the Wallet Provider will issue one or more new WUAs to the Wallet Unit.
HLRs
A. Issuing a Wallet Unit Attestation
Index | Requirement specification |
---|---|
WURevocation_01 | To enable a Relying Party or an Attestation Provider to verify the authenticity and (if necessary, see requirement VCR_01) 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. Note: 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. Re-issuance of attestation, including WUAs, will be discussed with Member States for ARF 2.0. |
WURevocation_02 | During the lifetime of the Wallet Unit, the Wallet Provider SHALL ensure that the Wallet Unit at all times is able to respond with a valid WUA to a presentation request from a Relying Party. Note: To comply with WURevocation_04, the validity period of a WUA probably cannot be very long. This implies that the Wallet Provider must regularly issue new WUAs to a Wallet Unit. |
WURevocation_03 | Empty |
WURevocation_04 | The Wallet Provider SHALL manage the issuance processes for WUAs in such a way that the WUAs cannot be misused by colluding Relying Parties (and Attestation Providers) to track a User. *Notes: - See also WUA_09. - The requirements for WUA management in this regard are comparable to those for management of a PID or attestation. |
WURevocation_05 | Empty |
A. Revoking a Wallet Unit
Index | Requirement specification |
---|---|
WURevocation_06 | Empty |
WURevocation_07 | A Wallet Provider SHALL be able to revoke a Wallet Unit by revoking its WUA(s), as specified in [Topic 7]. Note: Topic 7 also allows the use of short-lived (i.e., valid for less than 24 hours) WUAs that do no need to be revoked. In that case, the Wallet Provider revokes the Wallet Unit by no longer issuing WUAs to it. |
WURevocation_08 | Empty |
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) if they have a remaining validity period of 24 hours or longer. 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 a WSCA it uses for managing cryptographic keys and sensitive data, 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. |
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. |
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. To do so, the Wallet Provider SHALL revoke all valid WUA(s) for that Wallet Unit, if they have a remaining validity period of 24 hours or longer. The Wallet Provider SHALL authenticate the User before accepting a request to revoke the 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, if they have a remaining validity period of 24 hours or longer. To identify the Wallet Unit that is to be revoked, the PID Provider SHALL use the Wallet Unit identifier provided by the Wallet Provider in the WUA during PID issuance. |
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. |
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. |
B. Informing the User
Index | Requirement specification |
---|---|
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. |
WURevocation_15 | Empty |
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. |
C. Verifying the revocation status of a Wallet Unit
Index | Requirement specification |
---|---|
WURevocation_17 | Empty |
WURevocation_18 | A PID Provider or Attestation Provider SHOULD, for each of its valid PIDs or attestations, regularly verify whether the Wallet Provider revoked the Wallet Unit on which that PID or attestation is residing. If it turns out that the Wallet Unit is revoked, the PID Provider or Attestation Provider SHOULD immediately revoke the respective PID or attestation in accordance with all requirements in [Topic 7]. Notes: - How the PID Provider or Attestation Provider can do this verification depends on the details of the WUA and on WUA management. This is a topic that will be discussed for ARF 2.0. - 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 section 4.6.3. |
WURevocation_19 | A Relying Party SHOULD verify the revocation status of the Wallet Unit by requesting and verifying a WUA and subsequently verifying the revocation status of the WUA following the steps specified per VCR_11. |
WURevocation_19a | To safeguard User privacy, a Relying Party Instance SHOULD request only the data from the WUA that is necessary for carrying out a revocation check for the Wallet Unit. Note: The format of the WUA will be discussed with Member States and will be specified in ARF 2.0. However, the WUA contains information about the Wallet Instance and the related WSCD(s) that are only relevant for PID Providers and Attestation Providers, and that a Relying Party should not know. |
WURevocation_19b | To safeguard User privacy, a Wallet Unit SHALL present to a Relying Party only the data in the WUA that is necessary for carrying out a revocation check for the Wallet Unit. Note: See note to requirement WURevocation_19a. In addition, this requirement implies that the format of the WUA must enable the selective disclosure of attributes. |
WURevocation_20 | For the verification of WUAs, a Relying Party SHALL accept the trust anchors in the Wallet Provider Trusted List. Note: The Wallet Provider Trusted List is explained in [Topic 31]. |
WURevocation_21 | When no reliable information regarding the revocation status of a WUA 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 Wallet Unit. |
A.2.3.39 Topic 39 - Wallet to wallet technical Topic
See Topic 30.
A.2.3.40 Topic 40 - Wallet Instance installation and Wallet Unit activation and management
Short description
This Topic discusses requirements related to the installation of a Wallet Instance by the User, the subsequent activation of the Wallet Unit by the User and the Wallet Provider, and the management of the Wallet Unit throughout its lifetime.
HLRs
Wallet Instance installation
Index | Requirement specification |
---|---|
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). Note: This allows the operating system of the device to perform relevant checks regarding the authenticity of the Wallet Unit. |
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. Note: 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. |
Wallet Unit activation
Index | Requirement specification |
---|---|
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. |
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. |
WIAM_05 | During the activation process of a new Wallet Unit, the Wallet Provider SHALL process information about the User device and the available WSCAs and WSCDs, as far as necessary to issue a Wallet Unit Attestation to the Wallet Unit conform all requirements in Topic 9 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. |
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. |
Wallet Unit management
Index | Requirement specification |
---|---|
WIAM_07 | During the lifetime of the Wallet Unit, the Wallet Provider SHALL update the Wallet Unit as necessary to ensure its continued security and functionality. |
WIAM_08 | All communication between the Wallet Provider and the Wallet Unit SHALL be mutually authenticated and SHOULD be encrypted. |
WIAM_09 | If the User uninstalls the Wallet Unit, the Wallet Unit SHALL ensure that all cryptographic key material in the WSCA(s) related to the Wallet Unit is securely destroyed. This includes all keys of the WUAs, PIDs and attestations stored in the Wallet Unit. Note: Key deletion is a cryptographic key operation and requires User authentication, as specified in requirement WUA_02. |
A.2.3.41 Topic 41 - Minimum requirements on PuB-EAAs rulebooks
See Topic 12.
A.2.3.42 Topic 42 - Requirements for QTSPs to access Authentic Sources
Short description
This Topic discusses the ability of QTSPs issuing electronic attestations of attributes to verify those attributes by electronic means at the request of the User, wherever those attributes rely on Authentic Sources within the public sector.
HLRs
Index | Requirement specification |
---|---|
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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). Note: 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 QEEAs and the 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. |
A.2.3.43 Topic 43 - Embedded disclosure policies
Short description
This topic is focused on identifying high-level requirements for disclosure policies which may be embedded in an attestation. Such a policy may be created by the Attestation Provider, and allows the Wallet Unit, using data obtained from the Relying Party, to determine whether the Attestation Provider agrees with releasing specific attributes from the attestation to the Relying Party.
Where requirements in this Topic refer to a 'requesting Wallet Unit', what is meant is a Wallet Unit that is used to request attributes from another Wallet Unit, as described in Topic 30.
This topic will be further discussed with Member States in the future.
HLRs
Index | Requirement specification |
---|---|
EDP_01 | A Wallet Unit SHALL enable an Attestation Provider to optionally include an embedded disclosure policy in a QEAA, PuB-EAA, or non-qualified EAA, as defined in the applicable Rulebook. Note: The [European Digital Identity Regulation] does not contain a requirement for PIDs to be able to contain an embedded disclosure policy. |
EDP_02 | The Provider of an attestation that includes an embedded disclosure policy SHALL comply with the applicable Rulebook when including an embedded disclosure policy in the attestation. |
EDP_03 | An embedded disclosure policy created by an Attestation Provider SHALL only refer to information provided in an authenticated manner to the Wallet Unit by the Relying Party or the requesting Wallet Unit. Note: A future version of this ARF will specify a method for the Attestation Provider to ensure that the Relying Party (or requesting Wallet Unit) can provide such authenticated information to the Wallet Instance. A possibility is to use Attribute Certificates as specified in RFC 5755, referencing the Relying Party Instance access certificate. This will be discussed with Member States for ARF 2.0. |
EDP_04 | Empty |
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. |
EDP_06 | The Wallet Unit SHALL be capable of evaluating an embedded disclosure policy in conjunction with the information received from the requesting Relying Party or the requesting Wallet Unit, in order to determine if the Relying Party or the requesting Wallet Unit has permission from the Attestation Provider to access the requested attributes. |
EDP_07 | The Wallet Unit SHALL enable the User, based on the outcome of the evaluation of the embedded disclosure policy, to deny or allow the presentation of the requested electronic attestation of attributes to the requesting Relying Party or the requesting Wallet Unit. |
EDP_08 | The Commission SHALL take measures to create a technical specification establishing common mechanisms for the specification of embedded disclosure policies by Attestation Providers, and for the evaluation of such policies by Wallet Instances. |
A.2.3.44 Topic 44 - Relying Party registration certificates
Short description This topic identifies high-level requirements for Relying Party registration certificates, which were introduced in Commission Implementing Regulation 2024/2982 [2024/2982]. A registration certificate is issued by a Relying Party registrar to a Relying Party during the registration process described in Topic 27. It contains mainly the list of attributes registered by the Relying Party according to Article 5b 2 (c) of the [European Digital Identity Regulation]. A registration certificate is signed by the Registrar.
Commission Implementing Regulation 2024/2982 requires a Wallet Unit to authenticate and validate the registration certificate, and to display the information in the certificate to the User, where applicable. This enables Users to verify that the attributes being requested by the Relying Party are within the scope of their registered attributes, providing assurance that the request is legitimate and trustworthy.
HLRs
A. Issuance of Relying Party registration certificates
Index | Requirement specification |
---|---|
RPRC_01 | During the registration process for Relying Parties, as specified in Topic 27, the Member State Registrar SHALL create and sign a registration certificate and issue it to the Relying Party. The registration certificate SHALL comply with the applicable requirements in the technical specification mentioned in RPRC_02. Note: These requirements do not apply in case the Relying Party acts only as an intermediary, see Topic 52. |
RPRC_02 | The Commission SHALL ensure that a technical specification is created, describing at least 1. the contents and format of registration certificates, 2. the signing method(s) used to ensure the authenticity of the registration certificates. 3. the trust infrastructure necessary for signing registration certificates and for verifying these signatures, including, if necessary, the use of Trusted Lists to establish trust in Member States Registrars and to distribute their trust anchors to Wallet Units. 4. the method used for binding each registration certificate to the Relying Party Instance access certificate that will be used during the same transaction. This binding method SHALL enable a Wallet Unit to verify that the registration certificate was in fact issued to the Relying Party that authenticated itself using the access certificate. The binding method SHALL consider situations in which the Relying Party uses the services of an intermediary (see Topic 52) to connect to the Wallet Unit. 5. whether or not a registration certificate must have a validity period. 6. whether or not a registration certificate must be revocable, and if so, the method to be used for revocation. Moreover, if a registration certificate must be revocable, the technical specification SHALL describe the impact of revocation, especially compared to the impact of revocation of the Relying Party Instance access certificates. |
RPRC_03 | The contents of a registration certificate SHALL include at least 1. the list of attributes registered by the Relying Party, where each attribute is identified by the identifier specified for it in the applicable Attestation Rulebook, as specified in ARB_06a or ARB_06b. 2. the name of the Relying Party, which SHALL be identical to the name meant in Reg_31. 3. the EU-wide unique identifier of the Relying Party, as meant in Reg_32. 4. if the Relying Party uses the services of an intermediary (see Topic 52): the fact that this is the case, plus the name and unique identifier (as meant in Reg_32) of this intermediary. |
B. Presentation and verification of Relying Party registration certificates
Index | Requirement specification |
---|---|
RPRC_04 | In both proximity and remote presentation flows, the Relying Party Instance SHALL transfer a Relying Party registration certificate to the Wallet Unit in the presentation request, according to the applicable standard's extension mentioned in RPRC_05. |
RPRC_05 | The Commission SHALL ensure that extensions are specified for [ISO/IEC 18013-5] and for [OpenID4VP], allowing a Relying Party to transfer a Relying Party registration certificate to a Wallet Unit. These extensions SHALL comply with applicable requirements in these standards. |
RPRC_06 | 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 and subject to the User preference set according to RPRC_08, notify the User that it could not verify whether the Relying Party registered the requested attributes with the competent authorities. |
RPRC_07 | The Wallet Unit SHALL verify that all attributes requested in the presentation request are included in the list of attributes in the registration certificate. If the outcome of the verification is negative, the Wallet Unit SHALL, when asking for User approval according to RPA_07 and subject to the User preference set according to RPRC_08, notify the User about the requested attributes that the Relying Party did not register. |
RPRC_08 | A Wallet Unit SHOULD enable its User to set their preference for showing or hiding the notifications meant in RPRC_06 and RPRC_07. By default, the Wallet Unit SHALL show the notifications. |
A.2.3.45 Topic 45 - QEAA Rulebook
See Topic 12.
A.2.3.46 Topic 46 - Protocols and interfaces for Presentation of PID and (Q)EAA with Relying Parties
A.2.3.47 Topic 47 - Protocols and interfaces for PID and (Q)EAA issuance, and (non-)qualified certificates issuance
A.2.3.48 Topic 48 - Blueprint for requesting data deletion to Relying Parties
Short description
In this use case, a User requests the deletion of their personal attributes from Relying Parties with which they have interacted through their Wallet Unit.
Users are concerned about having control over their personal data, thus the function of requesting data deletion ensures a higher degree of transparency, privacy and control of the Users over their personal data.
This Topic lists high-level requirements related to the function of Users requesting the deletion of their personal data from Relying Parties through their Wallet Unit.
HLRs
Index | Requirement specification |
---|---|
DATA_DLT_01 | A Wallet Provider SHALL ensure that its Wallet Units support the technical specifications 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 Regulation (EU) 2016/679. |
DATA_DLT_02 | The Commission SHALL, in cooperation with the Member States, develop technical specifications for a Wallet Unit interface allowing a Wallet Unit to send attribute deletion requests to Relying Parties with whom it has interacted in the past. |
DATA_DLT_03 | A Wallet Instance SHALL provide a function where the User may select one Relying Party or multiple Relying Parties for which an attribute deletion request must be submitted. |
DATA_DLT_04 | A Wallet Instance SHALL be able to display the attribute deletion requests previously submitted through the Wallet Unit. |
DATA_DLT_05 | A Wallet Unit SHALL include attribute deletion requests in a log so they can be presented to the User via the dashboard (as specified in Topic 19). |
DATA_DLT_06 | The log SHALL include as a minimum: - Date of attribute deletion request, - Relying Party to which the request was made, - Attributes requested to be removed. |
A.2.3.49 Topic 49 - Protocol and interfaces for requesting data deletion to relying parties
Deleted.
A.2.3.50 Topic 50 - Blueprint to report unlawful or suspicious request of data
Short description
In this use case, a User reports a Relying Party to the competent national data protection authority, because the User claims that this Relying Party sent an unlawful or inappropriate request for attribute to the Wallet Unit. Users are concerned about having control over their personal data, and specifically about a Relying Party over-asking for personal information, thus the function of reporting suspicious or inappropriate requests ensures a higher degree of transparency, privacy and control of the Users over their personal data.
This topic lists high-level requirements related to the function of Users reporting unlawful or inappropriate attribute requests from Relying Parties.
HLRs
Index | Requirement specification |
---|---|
RPT_DPA_01 | A Wallet Unit SHALL provide a interface to lodge a complaint of suspicious Relying Party presentation requests to the DPA of the Member State that provided the Wallet Unit. |
RPT_DPA_02 | The User interface enabling a User to start the process of lodging a complaint SHALL be accessible via the Wallet Instance. |
RPT_DPA_03 | A Wallet Provider SHALL implement the interface in compliance with national procedural law and administrative practices. |
RPT_DPA_04 | A Wallet Unit SHALL enable the lodged complaint to be substantiated, including information to identify the Relying Party, their presentation request, and the User's allegation. |
RPT_DPA_05 | A Wallet Unit SHALL keep reports sent to the DPA in a log file so that it can be presented to the User in the dashboard (as specified in Topic 19). |
A.2.3.51 Topic 51 - PID or attestation deletion
Short description
This topic lists high-level requirements related to a User deleting a PID or attestation from their Wallet Unit.
HLRs
Index | Requirement specification |
---|---|
PAD_01 | A Wallet Unit SHALL at any time enable the User to delete any PID or attestation from their Wallet Unit. |
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 document type and Provider, a Wallet Unit SHALL delete all of these PIDs and attestations simultaneously. Note: 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. |
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. Note: This is a matter of User privacy. |
PAD_04 | If the Wallet Unit deletes a PID or attestation on the User's request, the Wallet Unit SHALL ensure that all cryptographic key material in the WSCA related to this PID or attestation is securely destroyed. Note: Key deletion is a cryptographic key operation and requires User authentication, as specified in requirement WUA_02. |
A.2.3.52 Topic 52 Relying Party intermediaries
Short description
This topic lists high-level requirements regarding so-called intermediaries, which form a special class of Relying Party. Article 5b (10) of the [European Digital Identity Regulation] states "Intermediaries acting on behalf of relying parties shall be deemed to be relying parties and shall not store data about the content of the transaction.". Such an intermediary is a party that offers services to Relying Parties to, on their behalf, connect to Wallet Units and request the User attributes that these Relying Parties need. The intermediary then sends the presented attributes to the 'end' Relying Party. This implies that an intermediary performs all tasks assigned to a Relying Party in this ARF on behalf of the 'end' Relying Party.
Index | Requirement specification |
---|---|
RPI_01 | An intermediary SHALL register as a Relying Party, in accordance with all requirements in Topic 27. Note: This implies that an intermediary obtains an access certificate containing its own name and unique Relying Party identifier. |
RPI_02 | An intermediary is acting only as an intermediary for other Relying Parties, and not as a Relying Party in its own right, SHALL NOT obtain a registration certificate according to Topic 44, containing its own name and Relying Party identifier. |
RPI_03 | For each of the Relying Parties that uses its services, an intermediary SHALL obtain a registration certificate from a Registrar, according to the requirements in Topic 44. This registration certificate SHALL contain that Relying Party's name and unique identifier, as well as the list of attributes registered for that Relying Party. |
RPI_04 | When issuing a registration certificate for a Relying Party to an intermediary, the Registrar SHALL verify, in a manner to be decided by a Member State, that the Relying Party will indeed use the services of the intermediary to interact with Wallet Units. |
RPI_05 | When issuing a registration certificate for a Relying Party to an intermediary, the Registrar SHALL include in the registration certificate the attribute meant in requirement RPRC_03, point 4, containing the name and identifier of the intermediary. |
RPI_06 | When requested by a Relying Party, an intermediary SHALL request the presentation of attributes from a specific Wallet Unit, using their own access certificate meant in requirement RPI_01, and the registration certificate of the Relying Party meant in RPI_03. |
RPI_07 | In case a Wallet Unit receives a presentation request from an intermediary, on behalf of a Relying Party, it SHALL verify the name of the intermediary during Relying Party authentication and display this name to the User when asking for User approval, as described in requirement RPA_06a. |
RPI_08 | When a Wallet Unit presents any User attributes to an intermediary, the intermediary SHALL forward these attributes only to the Relying Party that requested the intermediary to request these attributes from the Wallet Unit. |