The European Commission recently published version 1.0.0 of the Architecture and Reference Framework (ARF) for an European Digital Identity (the proposed update of the eIDAS Regulation). I wrote about these proposals earlier, from a more abstract perspective. I mentioned a lot would depend on the technical details. With some of them now available, it is time to study them.
Below I will briefly discuss the proposed use cases (as they are an indicator of where the whole framework is heading), then discuss the scope (what is and isn’t covered by the ARF), and then describe technical points for discussion in more detail. I will finish with some policy observations. But first some terminology, because the regulation and the framework both use them (and their abbreviations) extensively:
Note: future versions of the ARF will be made available through EUs own git repository.
Among the standard use cases like providing secure and trusted identification to access online services and offering educational credentials and professional qualifications, the ARF also mentions the following interesting/surprising use cases:
Compared to the breath of use cases, the scope of the ARF is rather limited.
According to the overview of the ecosystem on page 12, the interaction between the user and the wallet is out of scope for the ARF. This is problematic for two reasons:
Also the interfaces between the user and the wallet provider, and the device manufacturer is defined out of scope. This is disappointing, as these interfaces will have a bearing on the autonomy of the user towards both entities. A set of baseline requirements regarding the provision of wallet services and the availability of support would be the minimum to expect here. Similarly, some do’s and don’t for the device manufacturer regarding the use of the wallet by the user on the device should be specified. Moreover, the interface between the wallet provider and the device manufacturer is defined out of scope. This is potentially dangerous, as this interface has a tremendous impact on the overall sovereignty of the EUDI framework (as mentioned in earlier blogposts). At the very least, some basic requirements and a clear risk assessment should be provided.
Regarding the overview of the ecosystem itself, I would assume that authentic sources are also relevant for Personal Identification Data (PID) providers and Electronic Attestation of Attributes (EAA) providers.
Also, a clear hierarchy is not defined nor sketched among the different governance roles. A clear overarching governance body overseeing the full ecosystem appears not to be specified. This is problematic as strong coordination as well as a unified and predictable set of procedures and their application across the whole ecosystem (member stated, wallet solution providers, issuers, relying parties) is essential to achieve a high level of trust in the ecosystem.
The main part of this blog post concerns some technical issues. Most importantly:
These (and a few more) are discussed below.
One consideration for updating the eIDAS regulation was the risk of large online platforms leveraging their own login processes to offer ‘social logins’ and authentication of users to other (smaller) service providers, while tracking their users as the sign on to all these other services. This tracking of users through logins poses a serious privacy concern.
The new regulation and the ARF offer some privacy protective mechanisms. The offline use of wallet, and separating the issuing and use of attributes such that issuers do not and cannot keep track of the use of the attributes they issue, is an important step forward. Also both the use of the PID as well as the use of (Q)EAAs should support selective disclosure of their attributes.
However, the limited number of cryptographic schemes (SD-JWT or the Mobile Security Object specified in ISO 18013) that one should select to implement this are all linkable: the signature over the PID stays fixed and is revealed with every disclosure of (parts of) the PID. This signature thus becomes a powerful tracking cookie that services can use to recognise (‘single out’) returning customers, as well as profile them accross different services.
So for the EUDI, selective disclosure works as follows. Let h be a hash function, creating a digest h(ai) for an attribute ai. This hash function is one-way: given a digest di one cannot recover ai such that di = h(ai). In the EUDI scheme, an attribute attestation over attributes a1, …, an is a signature S = s(d1,…,dn) over the digests di = h(ai) of the attributes, generated by the ‘issuer’ (the attribute attestation provider). This signature S is a unique bitstring. To selectively disclose some attribute aj, the user sends to the relying party:
Selectively disclosing another attribute ak, the user sends
As S is unique, the user can be singled out with every visit to any relying party. In other words, S serves as a tracking cookie.
In contrast, true attribute based credential schemes that offer unlinkability (like the ones implemented by Idemix or IRMA) hide the signature as follows. To selectively disclose some attribute aj, the user sends to the relying party:
Using the randomised proof, the signature and the other fixed hashes to hidden attributes remain hidden, and thus no linkable information is revealed. (To construct such a proof a specific type of signature needs to be generated, and the hashes are also computed in a special way.)
(Added 2023-02-16 after a conversation with Arjen Geluk: the problem is that a requirement to use approved cryptographic primitives clashes with full unlinkability: the attribute based credentials use non standard cryptographic primitives to achieve their unlinkability properties. A ‘hack’ out of this paradox is to issue several independently signed attribute attestations that a wallet can randomly show to relying parties.)
However, even if the attribute attestation itself would be implemented in fully unlinkable way, this would not make the wallet unlinkable. It turns out that the protocol to exchange attribute attestations is relying on mutual authentication (i.e of both the relying party and the wallet) according to the description of the architecture components (p27); this appears to imply full identification of at least the wallet app (and by proxy its user) for all wallet interactions. This is a huge privacy concern by itself.
The validity status of QEAAs must be verifiable by relying parties in real-time. This is important if the ecosystem should be able to support real-time revocation of attributes. Although it is clearly stated that the QEAA providers themselves should not have the ability to receive any information about the use of the attestations (p14), nothing is required of the providers of these validity services themselves. Clearly specifying what these validity service providers receive when an attribute of a user is revoked, and what they receive when the validity status of an attribute is checked, is important to assess the privacy impact of such a validity check. For example, if the validity service provider receives information about the service requesting the validity check, this would allow the validity service provider to profile users based on the unique signature in the attribute attestation (as explained above).
Although for the overall trustworthiness of the EUDI framework it is crucial that the EUDI wallet can only be used by its actual owner, the current version of the ARF does not contain a lot of information about how to implement ‘owner binding’ (or ‘holder binding’ as the ARF appears to call it). Proper owner binding is especially challenging in remote settings where the EUDI is used remotely to access a service and it is much harder to ascertain that indeed the actual owner of the wallet is currently using it. What is worrying that the only mention of holder binding in the current ARF seems to imply that the relying party needs to perform it (see p24 and p25). This makes sense in a face-to-face setting where relying parties have an actual opportunity to verify that the person using the wallet is indeed is the one that is allowed to use it according to (meta)data associated with the PID (e.g. a passport like picture). But for remote use this does not make sense at all. There, some on-device checking and enforcement (using e.g biometrics) seems more appropriate.
Note that holder binding is also important when issuing attribute attestations, but no similar requirement is put on issuers to verify this binding (as is done for relying parties).
This brings me to another important security property, namely session binding, which guarantees that a sequence of steps all belong to the same session. This is for example used to first authenticate and authorise a user within a session and subsequently grant that user access to some resource within the same session. Note that in the context of the EUDI framework, session binding is especially important when issuing attribute attestations after having verified a user’s PID or other attributes, to ensure that the new attribute attestation is issued to the same wallet that was used to prove the PID and/or other attributes.
It is therefore surprising to see session binding only mentioned once in the ARF, on page 35.
The ARF mentions the existence and the importance of trusted lists (as trusted sources of information regarding issuers, relying parties and attribute metadata), but does not clearly describe the functionality provided by these trusted lists, let alone specifying a clear API to access them. This leaves open a lot of questions. For example: which entities can query these lists? Who can offer updates to these lists? What exactly do these lists contain? Are there lists describing which provider is allowed to issue which types of attribute attestations? Do the lists keep track of when trust in a certain entity is revoked, and is this information also available to other entities?
The ARF specifically leaves open the design decision of whether EUDI Wallet Instance consists of a single mobile app, or a set of local and remote components. So cloud based solutions are within scope. (see p18)
The ARF is ambivalent about the scope and nature of PID. Apart from obvious data elements in a PID, the table on page 22-23 also mentions optional and even possible additional attributes. A PID with containing many, possible more dynamic, attributes is bad from a user perspective as changing any attribute appears to require revocation of the current PID, which also renders the Wallet invalid and therefore unusable for EUDI purposes (p20-21). Also, the benefit of letting the PID contain many different attributes is unclear. So why not make almost everything a (Q)EAA except the really mandatory fields in a PID: family name, first name, date of birth, and the unique identifier? The ARF seems aware of this (quoting p23):
However, Nationality/Citizenship may also be communicated in the form of (Q)EAA’s, to allow citizens to demonstrate a given nationality, without updating the PID set or involving the PID Provider.
So why not pursue this principle more generally throughout?
On a related note: the ARF claims that the lifecycles of PID and (Q)EAA are essentially identical (p19). I wonder whether this is really true. If the PID is restricted to the mandatory field, the PID is static in almost all cases. Could, for example, an attribute become ‘valid’ again after being revoked or having become invalid? Given that PIDs and EAAs are essentially different things with entirely different roles in the overall ecosystem, I would be cautious lumping them together like this.
P.S.: probably there should be a direct arrow from ‘issued’ to ‘revoked’ in the PID lifecycle to ensure that wrongly issued PIDs or EAAs can be revoked without first having to make them valid (for a brief amount of time).
The tables of cryptographic requirements (on page 34 and further) independently lists several indirect requirements (referring to different standards) regarding the cryptographic primitives to be used; it is not clear whether these requirements aren’t by chance mutually exclusive. In any case, it would be much clearer to directly specify the cryptographic primitives and their parameters to use. This prevents confusion and perhaps incompatibilities later on. Perhaps this is solved once ISO 23220 will used as a basis for the ARF once it becomes publicly available.
The ARF repeats a few important policy cornerstones of the eIDAS regulation:
Some more complex policy related issues remain that are discussed next.
The ARF seems to suggest that in practice most attribute attestations (like drivers licenses, educational credentials and digital payments) will not be qualified (see p15). This is surprising given that the regulation stresses the importance of a high assurance identity framework and that in particular qualified trust services (whose operation is overseen by a supervisory body and that are audited regularly by a conformance assessment body) play an important role in ensuring this. Quoting recital 28 of the original eIDAS 2014 regulation:
To enhance in particular the trust of small and medium-sized enterprises (SMEs) and consumers in the internal market and to promote the use of trust services and products, the notions of qualified trust services and qualified trust service provider should be introduced with a view to indicating requirements and obligations that ensure high-level security of whatever qualified trust services and products are used or provided.
Also, recital 27 of the updated eIDAS 2021 regulation states that
qualified electronic attestation of attributes has the equivalent legal effect of lawfully issued attestations in paper form.
Authentic sources (like sources for attributes on address, age, gender, civil status, family composition, nationality, education and training qualifications titles and licences, professional qualifications titles and licences, public permits and licences, financial and company data) “are required to provide interfaces to QEAA Providers to verify the authenticity of […] attributes, either directly or via designated intermediaries recognised at national level.” (p15). This is risky as it opens up a huge set of sources of (sensitive, personal) data to third parties, unless clear guidelines and restrictions are specified and proper access control is mandated. This is not yet the case. Also the question who pays for all this (actually a more general issue with the full EUDI proposal) is not answered.
Attribute schemas and vocabularies are very important as they define the scope of the possible authentic statements a user can make (over which attribute types a user can make authentic claims); also they are important in terms of expressiveness and inclusivity (as the also define the possible attribute values a user can reliably express). It is unclear how they are provided, and by whom, and which entities govern this process and provide oversight (and redress).