Notes about the ARF (currently 1.4) from a DC4EU perspective.

[leifj]

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).

[digeorgi]

Thank you very much for your valuable feedback: The raised points do include some important topics. Below, we try to extract these and answer them separately:

• The ARF should not assume that a Wallet Instance always runs on a mobile device, but should be flexible enough to allow other form factors. We agree, and, as you noted, have taken steps in ARF 1.4.0 to make sure that there are no requirements that would forbid such a solution. Please let us know about any specific sections or requirements that still are problematic in this regard.
• Solutions need to be described for legal person Wallets and for representation. Again, we agree. The ARF should describe the requirements for PIDs and attestations issued to legal persons and for wallets used by legal persons. Also the relation with delegation needs to described, i.e. when do we issue a legal-person attestation and when do we issue an attestation giving a natural person the right to represent a legal person? We intend to add a section to the ARF main document to describe this, but first we need to discuss this within the eIDAS Expert Group.
• The ARF trust model is based on trusted lists, which may impede domain-specific trust models. The ARF fully intends to allow domain-specific trust models for non-qualfied EAAs, even if they are not based on trusted lists. Please let us know about any specific sections or requirements that you think are problematic in this regard.
• A trusted list cannot handle more than 100,000 entries, which is less than the expected number of Relying Parties. Here, we believe there is a misunderstanding. A Relying Party (and its trust anchors) will not be directly included in a trusted list. Instead, each Relying Party will receive an access certificate from an Access Certificate Authority. The expectation is there won't be many Access Certificate Authorities in a Member State, so perhaps the total will be in the order of 100 authorities. The trust anchors of these Access CAs will be put on a trusted list. A Wallet Instance only needs these 100 trust anchors to be able to validate the authenticity of all Relying Parties. See section 6.4.2. of the ARF main document and Topics 27 and 31 in Annex 2. We hope this clarifies.
• The ARF lacks features like revocation and delegation. For delegation, we agree; see our response above. For revocation, we don't agree. Revocation of both Wallet Instances and PIDs/attestations is described in several places in the ARF main document, as well as in Topics 7 and 9 in Annex 2. It is true that detailed mechanisms for revocation are not yet described in the ISO/IEC 18013-5 and SD-JWT VC standards that the ARF refers to, but this is actively being worked on in the respective standardisation organisations at the moment.
• Use of the W3C VC DM attestation format must be allowed. This is in fact the case, as you noted yourself. It is true that support for this format is not required in ISSU_02. A well-considered decision was taken to limit the attestation formats that are mandatory to support to the specified two. Each format to be supported by the Wallet significantly increases the complexity of the Wallet. Moreover, in order to be interoperable, it would be necessary at least to specify the proof format(s) that must be supported by the Wallet in combination with this attestation format. To our best understanding, the W3C VC DM proof formats published by the W3C either do not allow selective disclosure (e.g. Ed25519Signature2018) or lack widespread support in secure hardware such as Secure Elements and HSMs (e.g. bbs-2023).
• Current set of attributes in PID Rulebook does not rule out homonyms. We agree. This topic was discussed heavily in the context of the Implementing Acts. The Annex of the draft Implementing Act on PID and EAA introduces an optional "personal_administrative_number". The PID Rulebook in ARF 1.5.0 will follow the final Implementing Act.
• The Pseudonym Rule Book could potentially contravene the privacy principles of the new eIDAS Regulation and pseudonyms described in the Rulebook are limited in several ways. The Pseudonym Rulebook was not officially published as part of ARF 1.4.0 and will be dropped altogether. Instead, we are discussing to fulfill the requirements in the Regulation regarding the use of pseudonyms by requiring the Wallet to support FIDO Passkeys.