It is important to ensure that the wallet can be implemented in as many different ways as possible in order to promote as wide a use of the wallet as possible, e.g. both as a mobile application or web browser based wallet.
Any number of users and use-cases will require access to a wallet that is not in the form of a mobile native application. Transient users, users with limited platform access and users who need to be represented by other people all will need a non-traditional form factor for the wallet. It is important to ensure that the ARF does not contain any assumptions about the WSCD or the rest of the ecosystem that is based on the assumption that wallets are all native mobile applications.
We note that important steps have been taken in version 1.4 to address this issue.
This issue is also connected to the question of legal person wallets where it also will be important to be able to support non-traditional native mobile wallets. The issue of legal person and their use of the EUDI wallet ecosystem is also linked to the question of representation in the sense that legal persons have to separate the people representing the legal entity from their respective individual identities which leads to similar issues of representation or delegation that are present in other domains (e.g. social security, education and professional qualifications).
One of the key aspects to achieve high security is the reliable, harmonized and efficient trust framework that ensures the legitimacy of the components and entities involved in the EUDI Wallet ecosystem. It is important that the trust framework is implemented in a way that does not limit the scalability of the system but can ensure a decentralized, distributed or federated model that supports multilateral trust formation.
The ARF talks - in passing - about the possibility of domain specific trust mechanisms but the ARF is built on the assumption that trust is managed via trusted lists. The ARF should be analyzed to ensure that those assumptions are not in any practical way an impediment to domain specific solutions.
There is extensive experience in the R&E community on the use of aggregate trusted lists and lists of trusted lists in the form of the eduGAIN infrastructure which indicate that this model stops being an efficient solution when the number of entities pass 100k. This number is much lower than the expected number of relying parties for the EUDI wallet. The R&E community has serious concerns about the ARF on this point.
From a business perspective, the ARF currently lacks crucial features, including revocation/suspension and delegation of attestations. It is imperative to establish a harmonized process of revocation, consent and delegation to ensure acceptance across borders. This will also facilitate the definition of sector specific rulebooks for attestations which will be the foundation of LSPs for testing and piloting the critical functionalities within a cross-border user journey.
Other issues
Use of W3C VC DM 1.1 and or 2.0? ⇔ A MUST for DC4EU. Be aware that yes, it is included in A.2.3.12 Topic 12 - Attestation Rulebooks
Text references to “SD-JWT-VC”
SD-JWT-VC has not been approved by Member States representatives. ISSU_02 Shall be reviewed. W3C-VCs must be added in alignment with W3C-VCDM.
Based on the mandatory attributes specified in the "PID Rule Book" for the EUDI Wallet ecosystem, there is a potential for homonyms (individuals with the same name) to exist
Mandatory Attributes
family_name: Current last name(s) or surname(s) of the PID User.
given_name: Current first name(s), including middle name(s), of the PID User.
birth_date: Day, month, and year on which the PID User was born.
age_over_18: Indicates whether the PID User is currently an adult (true) or a minor (false).
issuance_date: Date (and possibly time) when the PID was issued.
expiry_date: Date (and possibly time) when the PID will expire.
issuing_authority: Name of the administrative authority that has issued this PID instance, or the ISO 3166 Alpha-2 country code of the respective Member State.
issuing_country: Alpha-2 country code of the PID Provider’s country or territory.
While the current set of mandatory attributes in the PID Rule Book enhances the ability to identify individuals, it does not completely eliminate the possibility of homonyms. For absolute uniqueness, additional identifiers or biometric attributes would be necessary.
Pseudonym Rule Book could potentially contravene the privacy principles of the new eIDAS Regulation
Limitations: Pseudonyms are not persistent across different wallet instances for the same user, and pseudonyms cannot be used for anonymous authentication (Section 2.4).
Main issues and comments
It is important to ensure that the wallet can be implemented in as many different ways as possible in order to promote as wide a use of the wallet as possible, e.g. both as a mobile application or web browser based wallet.
Any number of users and use-cases will require access to a wallet that is not in the form of a mobile native application. Transient users, users with limited platform access and users who need to be represented by other people all will need a non-traditional form factor for the wallet. It is important to ensure that the ARF does not contain any assumptions about the WSCD or the rest of the ecosystem that is based on the assumption that wallets are all native mobile applications. We note that important steps have been taken in version 1.4 to address this issue. This issue is also connected to the question of legal person wallets where it also will be important to be able to support non-traditional native mobile wallets. The issue of legal person and their use of the EUDI wallet ecosystem is also linked to the question of representation in the sense that legal persons have to separate the people representing the legal entity from their respective individual identities which leads to similar issues of representation or delegation that are present in other domains (e.g. social security, education and professional qualifications).
One of the key aspects to achieve high security is the reliable, harmonized and efficient trust framework that ensures the legitimacy of the components and entities involved in the EUDI Wallet ecosystem. It is important that the trust framework is implemented in a way that does not limit the scalability of the system but can ensure a decentralized, distributed or federated model that supports multilateral trust formation.
The ARF talks - in passing - about the possibility of domain specific trust mechanisms but the ARF is built on the assumption that trust is managed via trusted lists. The ARF should be analyzed to ensure that those assumptions are not in any practical way an impediment to domain specific solutions. There is extensive experience in the R&E community on the use of aggregate trusted lists and lists of trusted lists in the form of the eduGAIN infrastructure which indicate that this model stops being an efficient solution when the number of entities pass 100k. This number is much lower than the expected number of relying parties for the EUDI wallet. The R&E community has serious concerns about the ARF on this point. From a business perspective, the ARF currently lacks crucial features, including revocation/suspension and delegation of attestations. It is imperative to establish a harmonized process of revocation, consent and delegation to ensure acceptance across borders. This will also facilitate the definition of sector specific rulebooks for attestations which will be the foundation of LSPs for testing and piloting the critical functionalities within a cross-border user journey.
Other issues
Use of W3C VC DM 1.1 and or 2.0? ⇔ A MUST for DC4EU. Be aware that yes, it is included in A.2.3.12 Topic 12 - Attestation Rulebooks
Text references to “SD-JWT-VC” SD-JWT-VC has not been approved by Member States representatives. ISSU_02 Shall be reviewed. W3C-VCs must be added in alignment with W3C-VCDM.
Based on the mandatory attributes specified in the "PID Rule Book" for the EUDI Wallet ecosystem, there is a potential for homonyms (individuals with the same name) to exist Mandatory Attributes family_name: Current last name(s) or surname(s) of the PID User. given_name: Current first name(s), including middle name(s), of the PID User. birth_date: Day, month, and year on which the PID User was born. age_over_18: Indicates whether the PID User is currently an adult (true) or a minor (false). issuance_date: Date (and possibly time) when the PID was issued. expiry_date: Date (and possibly time) when the PID will expire. issuing_authority: Name of the administrative authority that has issued this PID instance, or the ISO 3166 Alpha-2 country code of the respective Member State. issuing_country: Alpha-2 country code of the PID Provider’s country or territory.
While the current set of mandatory attributes in the PID Rule Book enhances the ability to identify individuals, it does not completely eliminate the possibility of homonyms. For absolute uniqueness, additional identifiers or biometric attributes would be necessary.
Pseudonym Rule Book could potentially contravene the privacy principles of the new eIDAS Regulation
Limitations: Pseudonyms are not persistent across different wallet instances for the same user, and pseudonyms cannot be used for anonymous authentication (Section 2.4).