Update arf.md Andy Tobin #234
Conversation
Commentary on ARF 1.4 from Andy Tobin of Gen Digital. Comments are in square brackets and bold [** xxxx **].
| @@ -184,7 +184,7 @@ various online services, both public and private. This capability is | |||
| crucial, as it allows Relying Parties to confidently verify the identity | |||
| of Users they interact with. | |||
|
|
|||
| In this specific use case, a User employs the EUDI Wallet to | |||
| In this specific use case [**Which specific use case? Para above speaks about both identification and authentication with no particular use case stated**] , a User employs the EUDI Wallet to | |||
There was a problem hiding this comment.
What is meant is 'identification and authentication to access online services'. I agree that that's not very specific and I have therefore removed the word 'specific'.
| @@ -198,14 +198,14 @@ User\'s perspective. It spans from acquiring a valid Wallet Instance to | |||
| the process of identifying and authenticating themselves for an online | |||
| service. The focus here is on a practical remote same-device flow (as | |||
| detailed in [section 4.2.2](#422-attestation-presentation-flows) and [4.2.3](#423-mobile-apps-and-web-browsers)). In this context, a User utilises a | |||
| single device for both securing their session and accessing the service, | |||
| single device [**What about scenarios where the wallet device is used for multi-factor euthentication for a service being accessed on another device? This is a valid use case as not everything will be done on a mobile phone**]for both securing their session and accessing the service, | |||
There was a problem hiding this comment.
Remote cross-device presentation scenarios are discussed in chapter 4. In fact, section 2.1 should not talk about the distinction between same-device and cross-device. This paragraph will be removed.
There was a problem hiding this comment.
Hi Andy, thanks for your detailed review. I've commented on the first many of them; I will continue tomorrow. Please note that these comments have not been approved by the EC, so while I believe they are correct, they cannot be taken as an answer by the Commission.
If you have a comment on which you would like an official answer, please raise an issue.
| [Chapter 6](#6-trust-model) - Trust Model, [Annex 2](annexes/annex-2/annex-2-high-level-requirements.md) (High level requirements in \[Topic 2\], | ||
| \[Topic 10\] and \[Topic 23\], and [Annex 3.1](annexes/annex-3/annex-3.01-pid-rulebook.md) - PID Rulebook. | ||
| [Chapter 6](#6-trust-model) - Trust Model, [Annex 2](annexes/annex_2_high_level_requirements/annex_2_high_level_requirements.md) (High level requirements in \[Topic 2\], | ||
| \[Topic 10\] and \[Topic 23\], and [Annex 3.1](annexes/annex_3_attestation_rulebooks/annex_3.01_pid_rulebook.md) - PID Rulebook. |
There was a problem hiding this comment.
Thanks for catching the broken links. But in fact, this 'introductory' paragraph does not belong in this section and will be removed. We have done our best to fix broken links throughout the ARF.
| @@ -218,7 +218,7 @@ part of a local QSCD, or a remote QSCD managed by a QTSP \[Topic16\] and | |||
| ### 2.3 Mobile Driving Licence | |||
|
|
|||
| A significant use case for the EUDI Wallet involves allowing Users to | |||
| acquire, store, and present a mobile Driving Licence (mDL) as an | |||
| acquire, store, and display a mobile Driving Licence (mDL) as an | |||
There was a problem hiding this comment.
'display' suggest that the mDL is displayed to the Relying Party, using the display of the User's device. Probably that's not what you mean. But in any case, 'present' is the verb used in the ARF for the action of sending the verifiable attestation to the Relying Party.
| @@ -231,13 +231,18 @@ proximity flows have one significant difference: in the supervised flow, | |||
| the EUDI Wallet presents mDL attributes to a human Relying Party or | |||
| under their supervision (who may also use a device); whereas in the | |||
| unsupervised flow, the EUDI Wallet presents mDL attributes to a machine | |||
| without human oversight. | |||
| without human oversight. [**How does this tie into the proposed revisions to the EU driving licence directive to enable use of mDLs? This doc should refer to those new proposals to ensure joined-up thinking and implementation.**] | |||
There was a problem hiding this comment.
Sorry, I am not wholly sure what your point is. Do you see a conflict between the new DL directive and the statements in this section? If so, please provide some more detail.
|
|
||
| (Q)EAA issuance requirements, mDL attribute schema and Trust | ||
| Infrastructure details are further detailed specifically in [Chapter 3](#3-ecosystem) - | ||
| Ecosystem, [Chapter 5](#5-attestations) - Attestations, and in [Annex 2](annexes/annex-2/annex-2-high-level-requirements.md) - \[Topic 2\], | ||
| Ecosystem, [Chapter 5](#5-attestations) - Attestations, and in [Annex 2](annexes/annex_2_high_level_requirements/annex_2_high_level_requirements.md) - \[Topic 2\], |
There was a problem hiding this comment.
Again, thanks for this fix. However, this paragraph was removed from this section.
| [**How is Clause 14 of the regulation addressed in this ARF? "Member States should integrate different privacy-preserving technologies, such as zero knowledge proof, into the | ||
| European Digital Identity Wallet. Those cryptographic methods should allow a relying party to validate whether | ||
| a given statement based on the person’s identification data and attestation of attributes is true, without revealing any | ||
| data on which that statement is based, thereby preserving the privacy of the user."**] |
There was a problem hiding this comment.
That statement is in the non-binding Recital 14 of Regulation 2024/1183. Zero-knowledge proofs have been discussed with Member States and experts, see in particular #200. In summary: ZKPs cannot be used right now due to a lack of support by secure hardware. However, the topic will be discussed again with Member States for ARF v2.0 (Q1 2025).
|
|
||
| The EUDI Wallet Providers make available to a User, through an instance | ||
| of their EUDI Wallet Solution, a combination of several products and | ||
| Trust Services foreseen in the legal proposal, which give the User full | ||
| control over the use of their Person Identification Data (PID) and | ||
| Electronic Attestations of Attributes (QEAA, PuB-EAA or EAA), and any | ||
| other personal data within their EUDI Wallet. From a technical | ||
| other personal data within their EUDI Wallet. [**Not really "full control" as the user can only use it at places that are deemed by some 3rd party to be acceptable, and for data sharing that is within certain parameters. Better to say "gives the user control over the release of their...**] |
There was a problem hiding this comment.
I get your point. Since the Regulation requires 'sole control', I have changed 'full control' to 'sole control' here. After all, the Regulation obviously is always right...
| managing, and publishing a Trusted List. Within the EUDI Wallet | ||
| managing, and publishing a Trusted List. | ||
|
|
||
| [**Who is the Trust List Registrar? How to become one? If there are more than one, who runs and maintains the trusted list of trusted list registrars? Some more detail on this would be very useful.**] |
There was a problem hiding this comment.
We have added to ARF 1.5.0: "A Trusted List Provider is appointed by a Member State and notified to the Commission."
(Note we changed the name of this role.)
| @@ -407,6 +422,8 @@ ecosystem, Trusted Lists exist for the following entities: | |||
| - Access Certificate Authorities for | |||
|
|
|||
| - Relying Parties, | |||
|
|
|||
| - [**Add relying party proxy services?**] | |||
There was a problem hiding this comment.
Good question. At the moment, we're not sure how proxys would work exactly. The Regulation says that they shall be deemed to be Relying Parties, but of course the question is what that means, exactly. For example, if there should be a way for Wallet Units and Users to distinguish a proxy from a 'real' RP, and to get information about the RP that uses the proxy to connect with the Wallet Unit. After all, that RP is the one that will receive the User attributes. This is a topic that we need to discuss further with Member States.
| @@ -437,6 +454,12 @@ to provide a registration service for the relevant entities. The terms | |||
| and conditions for entities to become registered are for each registrar | |||
| to determine unless specified elsewhere e.g., in sectoral rules. | |||
|
|
|||
| [**What is the implication of having so many trusted lists on the performance of the wallet and the transactions it executes? Wallets will presumably have to cache such lists for offline use. Any rules on how frequently that will need to happen? Generally the proliferation of trusted lists across 27 member states is a concern from a complexity and performance perspective.**] | |||
|
|
|||
| [**For relying party registration, what happens in the case of a multinational (eg Decathlon or Pret A Manger) if one member state is OK with accepting them as a relying and another state is not? When a citizen travels from one state to another, they will find that their use of their wallet in one state is inconsistent with the other member state. This will reduce confidence in the use of eIDAS by people, who will expect consistency across the EU. Additionally, for such multinationals, having to register as a relying party in 27 member states will dissuade them from participating, which is the opposite of what we want. I suggest that relying party registration is harmonised across member states so approval in one member state is approval in all member states.**] | |||
There was a problem hiding this comment.
The process for RP registration is out of scope of the ARF for the moment. As far as I know, it's being discussed between Member States in the context of the next batch of Implementing Acts.
| [**For relying party registration, what happens in the case of a multinational (eg Decathlon or Pret A Manger) if one member state is OK with accepting them as a relying and another state is not? When a citizen travels from one state to another, they will find that their use of their wallet in one state is inconsistent with the other member state. This will reduce confidence in the use of eIDAS by people, who will expect consistency across the EU. Additionally, for such multinationals, having to register as a relying party in 27 member states will dissuade them from participating, which is the opposite of what we want. I suggest that relying party registration is harmonised across member states so approval in one member state is approval in all member states.**] | ||
|
|
||
| [**Should relying parties have controls over what information they are allowed to ask for? I suggest that if relying party registration is required, the relying party has to detail what information they are going to ask for and for what purpose. This will allow wallets to inform users if the relying party requests they receive are from the valid relying party, are not asking too much sensitive data, and are proportionate with the requirements of the transction being executed.**] | ||
|
|
There was a problem hiding this comment.
Yes, this is exactly how it's going to work. This was established in the recently published Implementing Act on protocols and interfaces. But again, details for the RP registration process are still being discussed.
| @@ -476,6 +499,7 @@ may provide validity information about EAAs, without having an ability | |||
| to receive any information about the use of the EAA. The terms and | |||
| conditions of issuing EAAs and related services are subject to sectoral | |||
| rules. | |||
| [**What protections will be in place to prevent a TSP issuing EAAs that appear the same/similar to a QEAA e.g. a fake driving license with all the same attributes as a real driving license? While the relying party should be able to check the issuing source is legitimate, in the early days of eIDAS 2.0 rollout, this faking approach will be a major attack vector. Tricky one to solve I know.**] | |||
There was a problem hiding this comment.
This is the approach we've taken: PID Providers, QEAA Providers and PuB-EAA Providers are trusted to not issue attestations that they are not allowed, registered, or expected to issue. That trust is warranted because these Providers are regulated, are audited regularly and in general have too much to lose if they are caught. That leaves only non-qualified EAA Providers to worry about. So, Relying Parties must properly manage their trust anchors and make sure that they don't use a trust anchor of a non-qualified EAA Provider to verify PIDs, QEAAs, or PuB-EAAs.
The ARF does not specify any measures to further mitigate this risk within the non-qualified EAA category, because the Regulation doesn't contain any basis to regulate this. An example would be someone creating fake vouchers for a free beer at a restaurant. The EEA Provider itself should make sure that the RPs accepting their EAAs are able to distinguish fake attestations from real ones. Again, this most likely comes down to proper management of trust anchors.
| @@ -542,6 +566,13 @@ doing so. Relying Parties need to maintain an interface with the EUDI | |||
| Wallet to request attestations with mutual authentication. Relying | |||
| Parties are responsible for authenticating PIDs and (Q)EAAs. | |||
|
|
|||
| [**Is there a mechanism in place to allow a relying party to determine what happens when the user has multiple (Q)EAAs containing the same data, all of which could fulfil a request. For example, a user may have address information in (Q)EAAs from their bank, elecricity company, insurance company, etc. How can a relying party ensure they are requesting the right one, and how will the wallet logic and user interface work when data from a selection of (Q)EAAs is available and the user has to make a choice which one to use?**] | |||
There was a problem hiding this comment.
Relying Parties are supposed to know what they need, which attestations exist that might fulfill that need, and which of these are acceptable for the RP. To help with that, the Commission will establish a catalogue of attestations.
The ISO/IEC 18013-5 or OpenID4VP standards do not contain mechanisms to let the RP know upfront which attestations are present in the Wallet Unit, as that would be an obvious privacy risk. So if there are multiple attestations that could fulfill the RP's need, probably the best they can do is request them all. As far as I know, the latest versions of both standards allow the RP to indicate that some of the requested attestations are alternatives, so that the Wallet Unit will return only one of them. The Wallet Unit could let the User make the final choice, but there are no requirements for this. It's also acceptable if the Wallet Unit itself decides (based on the parameters in the request) which attestation to return (and then, obviously, ask the User for approval.)
| @@ -542,6 +566,13 @@ doing so. Relying Parties need to maintain an interface with the EUDI | |||
| Wallet to request attestations with mutual authentication. Relying | |||
| Parties are responsible for authenticating PIDs and (Q)EAAs. | |||
|
|
|||
| [**Is there a mechanism in place to allow a relying party to determine what happens when the user has multiple (Q)EAAs containing the same data, all of which could fulfil a request. For example, a user may have address information in (Q)EAAs from their bank, elecricity company, insurance company, etc. How can a relying party ensure they are requesting the right one, and how will the wallet logic and user interface work when data from a selection of (Q)EAAs is available and the user has to make a choice which one to use?**] | |||
|
|
|||
| [**Can you give some detail on how Regulation clause 5b.3 handled by wallets? "3. Relying parties shall not request users to provide any data other than that indicated pursuant to paragraph 2, | |||
There was a problem hiding this comment.
Per the recently published IA on protocols and interfaces, a Relying Party will receive a registration certificate indicating which attributes it has registered. The Wallet Unit must authenticate that certificate and display the information in it to the User.
Because the introduction of registration certs in this IA is a quite late development, and because the topic of RP registration is still being discussed in comitology, the ARF does not yet specify in more detail how this should work. ARF 1.5.0 will describe the concept of registration certificates on a high level, so as to be consistent with the published IA. The intent of the IA seems to be that the User is warned when the RP requests data that it did not register for, but the User is still free to decide to present that data anyway.
| point (c)."**] | ||
|
|
||
| [**Can you add some info on how relying party intermediary/proxy services specified in 5b.10 of the Regulation will operate within the scope of the ARF? Will they require any different technical consideration than "normal" relying parties?**] | ||
|
|
There was a problem hiding this comment.
We don't know yet. It's been flagged internally as a topic that needs discussion.
| @@ -695,6 +726,8 @@ the EUDI Wallet Solution: | |||
| server. The minimum hardware and software requirements for the User | |||
| device will be determined by the Wallet Solution. | |||
|
|
|||
| [**Can you give some more information about the acceptability of hybrid wallets for natural persons, for example where some wallet access keys are held at the edge on device, and credentials are held in a secure cloud storage. This can have benefits such as enabling cross-device operation, providing "always on" capability, and offloading processing/logic from the device to speed up things like lookup of many trusted lists. This seems to be within the WCSD arena but it's not really clear, as the cloud capability could also include logic & orchestration needed in the WI.**] | |||
|
|
|||
There was a problem hiding this comment.
Hybrid wallets, or any other architectures, are acceptable as long as they can be certified.
| @@ -2005,6 +2059,8 @@ Note: | |||
| EUDI Wallet ecosystem. Each PID Provider or Attestation Provider | |||
| will choose which Trusted Lists they need to subscribe to. | |||
|
|
|||
| [**This has the potential to get very messy and confusing, and result in inconsistencies across the eIDAS ecosystem. Isn't there a better way?**] | |||
There was a problem hiding this comment.
This was a mistake in ARF 1.4 that will be corrected in 1.5. Attestation Providers must actually support all (certified) Wallet Solutions.
However, for reasons of national sovereignty, PID Providers get to choose which Wallet Solution(s) they want to support. Practically speaking, it looks like many Member States will (initially?) issue their PIDs only into their own Wallet Solution. The Wallet Provider and the PID Provider may even be the same entity.
| @@ -2282,6 +2338,8 @@ Instance uses the User authentication mechanisms set up during Wallet | |||
| Instance activation, see [section 6.5.3](#653-wallet-instance-activation). More detailed requirements | |||
| regarding User approval can be found in \[Topic 6\]. | |||
|
|
|||
| [**Not specific to presentations, but is there further detail on the wallet's logging of these transactions to provide an audit trail or "proof" that a user has conducted them? I may have missed this somewhere else, but I haven't noticed a requirement on the wallet provider to ensure that all activities are logged to provide the user with evidence that they have done certain things. There should also be a mechanism that enables a user to access this audit trail and provide prof of action that can be verfied. If this isn't in the ARF anywhere, I recommend it is added.**] | |||
There was a problem hiding this comment.
Yes, such requirements exist. See section 6.6.3.13 and Topic 19 in Annex 2.
| @@ -2352,6 +2410,8 @@ Notes: | |||
| attestation and verifies the value encoded at the bit position given | |||
| by the index value in the attestation. | |||
|
|
|||
| [**This is problematic and contravenes 16a of the Regulation "16. The technical framework of the European Digital Identity Wallet shall: (a) not allow providers of electronic attestations of attributes or any other party, after the issuance of the attestation of attributes, to obtain data that allows transactions or user behaviour to be tracked, linked or correlated, or knowledge of transactions or user behaviour to be otherwise obtained, unless explicitly authorised by the user;" . An index value to a revocation status list is a unique identifier for a specific credential belonging to a specific user. Once a 3rd party (eg a relying party) has this index value, they can collude with other relying parties who will see the same index value each time attributes from this attestation are presented. They will be able to build up a profile of that user's activity. Given that the user won't have a choice about not presenting this index value, they are effectively sharing a unique identifier with everyone to whom they present any attributes from this attestation, EVEN IF they are using selective disclosure. Assuming selective disclosure is used, relying parties who each receive a small selection of attributes from the user will be able to assemble them into a much more comprehensive set by using this index value as the key. Additionally, once a 3rd party has this index value and the URL of the status list, the 3rd party can watch this revocation status bit constantly to see if it changes even if their relationship with the user has lapsed. This is a privacy issue as any relying party can continue to check if my driving license has been revoked long after my original transaction with them. The could, for example, then blackmail me by threatening to tell friends/colleagues/my employer that my driving license has been revoked. Or that my membership of a club has been revoked. Or that I have lost my job because my employee ID attestation has been revoked. The use of status lists should therefore be avoided unless the correlation and ongoing access issues are handled well enough to satisfy the regulation 16a.**] | |||
|
|
|||
There was a problem hiding this comment.
This privacy risk is actively being discussed with Member States at the moment. Requirements to mitigate it will be added to ARF 1.7. Basically, these mitigations come down to regular re-issuing of attestations, such that an index value (or any other static identifier in an attestation) cannot be used to link attestation presentations. In addition, specifically for revocation, the ARF already describes that Attestation Providers can use short-lived attestations that do not have to be revoked.
| @@ -2393,6 +2453,7 @@ The technical implementation of this verification depends on which of | |||
| the standards mentioned in \[Topic 12\] is supported by the Wallet | |||
| Instance. Each of these standards specifies in detail how to carry out | |||
| this verification. | |||
| [**Can you expand on what happens when a "cloud wallet" is being used and there could be multiple devices that access the cloud wallet?**] | |||
There was a problem hiding this comment.
From the point of view of the Relying Party, the internal architecture of the Wallet Unit does not have any impact. In general, the ARF does not discuss the various architectures that could be used to implement a Wallet Unit. The only requirement is that it must be possible to certify each solution.
| @@ -2456,6 +2517,8 @@ practice this will often mean that the identity document is a photo ID, | |||
| and the presentation must consequently be done in proximity and be | |||
| supervised, or done remotely and supported by PAD. | |||
|
|
|||
| [**The PID should contain a photo by default. The fact it doesn't is an ommission and needs to be corrected.**] | |||
|
|
|||
There was a problem hiding this comment.
According to the recently published Implementing Act on PID and EAA, inclusion of a User portrait is optional.
|
All change proposals in this PR have been considered, and, where agreed, processed in the ARF 1.5.0. This PR can be closed. |
Commentary on ARF 1.4 from Andy Tobin of Gen Digital. Comments are in square brackets and bold [** xxxx **].