The European Commission has opened a consultation on implementing regulations fixing some details of the European Digital Identity Wallets, as part of the larger reform of the European Digital Identity Framework (eIDAS). I have been critical in the past, so it is time to revisit the current proposals and share here the feedback I also submitted to the Commission in response to this consultation.
In fact five separate implementing regulations are proposed, concerning
I will discuss them separately, even though I think this is a fundamentally broken approach (as I will discuss afterwards). This discussion is based on version 1.4.0 of the Architecture Reference Framework (ARF) and the Final text of the amended eIDAS regulation, as well as the different proposals for implementing regulation of course.
The first implementing regulation claims it concerns the trust framework, but in actual fact is limited to describing a notification system to be set up by the Commission, and defining the kind of notifications Member States need to issue through this system. As this does not specify the full trust framework, it is better to rename the implementing regulation accordingly.
The proposed notification system is a basic database where member states can enter information about
This information, and especially the included certificates for authentication, is used by the wallet to determine whether a party is a vetted participant in the identity framework. Such vetted access is indeed a crucial first step in constructing a trust framework: after all each participant in the framework contributes (or deteriorates) the overall trust in the framework. Restricting access to vetted participants allows you to keep or kick out misbehaving participants.
It is therefore surprising to see that attribute attestation providers are missing from this list. These should also be required to be registered before they can take part in the identity framework. Rogue attestation providers can do significant harm to the (perceived) trust in the overall identity framework if they issue nonsensical or nonfunctional attribute attestations.
Given the importance of the integrity of the information contained in the notification system to maintain trust in the identity framework, I would expect the implementation regulation to specify some process to maintain this integrity as well. It should, for example, describe processes that verify and maintain the integrity of information submitted by member states. And describe (emergency) processes when information in the database becomes corrupted (including quickly notification any services depending on the information int he notification system, within a guaranteed time frame). Unfortunately, such processes are not defined.
Also missing is a requirement for member states to provide information about the attributes a wallet relying party can request from a wallet. According to Article 6b.1e of the final text of the regulation Member States should make information about “the intended use of the European Digital Identity Wallet, including the data to be requested” (Article 6b.1a.c) “available online in electronically signed or sealed form suitable for automated processing”. The notification system appears to be suitable place to do so, but the description of the required information within such notifications is lacking these fields.
Final, minor, point. Article 1 of the implementing regulation establishes a trust framework for the validation of both
I would assume the latter would be sufficient to establish the former (assuming we trust the providers of person identification data to only issue authentic data). Otherwise this would imply creating a registry of all authentic person identification data, which surely is not what is intended.
The second implementing regulation covers certification.
This is by far the largest of the five implementing regulations, making clear that Commission considers proper certification rather important. Too important perhaps.
I am not an expert in certification, so I do not have a lot to say about this. But I did notice certain things I found peculiar.
First of all, the implementing act only considers the certification of wallets. Certification of providers of personal identification data or of attribute attestations is not covered. Is this planned for another implementing regulation? If not, then this is an omission: certification is an important mechanism to increase the trust in such providers, and hence in the overall trust in the identity framework. All effort to strictly certify wallets are in vain, if rogue providers can spoil the trust.
Second, a process to harmonise the individual certification schemes of Member States appears to be missing. This means that there is a risk that a wallet solution could get certified in one member state while being denied certification in another. It is important to align the different certification schemes and continually monitor that their outcomes are more or less equivalent. Also, mechanisms should be put into place to ensure that if a certification scheme from one Member State falls behind and threatens to negatively impact the overall trust in the identity framework, corrective actions can and will be taken. Luckily, a transition to a European certification scheme is foreseen (Article 20 of the implementing regulation). But until that happens, a stronger focus on harmonisation from the start is essential.
The third implementing regulation addresses the issuing of personal identification data (PID) and attribute attestations.
This implementing regulation only covers the issuing of personal identification data and attribute attestations, and not the subsequent use of these at relying parties. It is unfortunate that these closely interrelated aspects are regulated independently. (More on this below.)
Proper provisioning of wallets to citizens and the subsequent proper issuing of the core personal identification data to this wallet is of crucial importance to the overall trustworthiness of the European Identity Framework. The process must ensure that the correct PID, corresponding to the actual owner of the wallet, is issued to his or her wallet. It is therefore crucial that this particular implementing regulation properly describes this process with sufficient precision and sufficient detail.
In its current form Article 3 does not. First of all, it is never explicitly requires that the PID issued corresponds to the actual owner of the wallet it is issued to. The very clear state diagram in section 4.4.3 of the ARF (showing how wallet provisioning and PID issuing are interrelated and both required to create a valid and usable wallet instance) cannot be reconstructed from the items in Article 3.
Member States shall ensure that the set of person identification data attributes issued to a given wallet user is unique. (Art. 3.4)
First, it is surprising that this requirement is placed on the Member States and not on the issuers of PIDs themselves. What’s worse, the set of mandatory attributes in a PID according to Annex 1 is too restrictive to actually guarantee this: there is a (theoretical) possibility that two people with the same name are born on the same date, in the same place, asking their PID to be issued at the same data at the same authority,
Member States shall enroll wallet users in accordance with the requirements relating to enrolment, as set out in Commission Implementing Regulation (EU) 2015/1502 (Art. 3.7)
Enrolment of wallet users is not a concept defined in the ARF, nor is it compatible with the ARF. In fact the ARF assumes users individually install a component on their user device. Moreover, this item does not specify at which level of assurance this should happen. Given that in certain use cases of the wallet a high assurance level is required, shouldn’t this be required here as well?
Article 3.7 references Commission Implementing Regulation (EU) 2015/1502 of 8 September 2015 on setting out minimum technical specifications and procedures for assurance levels for electronic identification means. Why isn’t that implementing regulation followed more closely in this case, also with regard to identity proofing for example?
Article 3.5 requires cryptographic binding of the PID to the wallet it is issued to. What is missing, however, is to explicitly require some holder binding, i.e. offer some guarantees that the current user of the wallet is in fact the person to which the PID pertains. This could, for example, be realised by explicitly requiring that the wallet secure cryptographic device (which realises the cryptographic binding of the PID to the device) is only unlocked through a form of biometrics.
It is undesirable to (re)use wallet relying party access certificates to authenticate PID issuers (Art. 3.8) and attribute attestation issuers (Art. 4.2). Issuers are (in general) not relying parties, unless they require users to first disclose some information before they issue a new PID or some attribute attestation. Conflating both entities into one category runs the risk that relying parties are mistakenly recognised as issuers by a wallet. Different types of certificates (that are clearly distinguishable as such) should in general be issued to different types of entities.
Revocation as proposed by these implementing regulations (and also as described in the ARF) violate the principle of privacy by design that is so central to the regulation.
As hinted to by Art 5.6 (and as specified in the ARF), providers must include an URL within the PIDs and attribute attestations they issue through which a relying party can access the revocation status of this particular PID or attestation. The idea is that a relying party checks, through this URL, in real time the revocation status of each PID or attribute attestation it receives. Accessing this URL will reveal the identity and location of the relying party (through the IP address) and the time and date the PID or attestation is being presented to this relying party. It will also reveal the specific PID or attribute attestation whose revocation status needs to be checked. The regulation leaves unspecified who should be the entity hosting the server with the revocation statuses accessed through this URL. This could very well be the provider of PID or attribute attestation itself. In that case, the provider can keep perfect track of which users are using the PIDs or attestations it issued, and when and where. This is strong violation of privacy, essentially rendering void any of the privacy protections offered or presumed by the regulation. It would in fact turn the attribute based approach of the regulation completely equivalent to the network based social logins, that allow Facebook or Google to keep track of all accounts that you log in with through their account.
Article 5.3 requires providers of attribute attestations to inform users without delay of the revocation and of the reasons for the revocation. This implies that these providers must keep records of the personal data of each user to which they have issued attribute attestations. This is a privacy violation. In particular, it rules out use cases where users anonymously obtain some new attribute attestations solely based on other attribute attestations they already hold. For example obtaining a voucher for an age restricted product based on an age assurance attributes (like the over 13 or over 18 attributes optionally present in a PID).
Ensuring that the authenticity of attribute attestations (Art. 4.3) or PIDs (Art. 3.2) can be verified is more reliably guaranteed by mandating particular data formats for both types of data objects, as has been done in earlier versions of the ARF (and which is done through Art 4.1, although the exact data formats in the standards references should be made explicit).
The annex to this implementing regulation specifies the mandatory and optional data elements present in a PID. Attributes for age assurance are optional unfortunately, and only limited to over 13 and over 18. It might be good to add a few more, like over 65 and over 16 (as two examples of ages that are significant in certain cases or within certain Member States).
The fourth implementing regulation discusses wallet application programming interfaces and protocols. It in particular deals with the conditions under which PIDs and attribute attestations can or should be presented to relying parties.
It is interesting to see that Art 4.3. is more strict w.r.t. the checking of the validity of access certificates when issuing PIDs or attribute attestations to wallets. Art 4.3. specifically requires that
ensure that wallet units authenticate and validate wallet relying party access certificates using only the trusted list of providers of wallet relying party access certificates
Such an additional check against this trusted list is not specifically required when interacting with relying parties as described in Art. 3. This is an omission.
More fundamentally though, the technical measures to restrict unfettered access to PIDs and attribute attestations by relying parties are misguided.
The mechanism is supposed to work as follows. Providers of PIDs and attribute attestations can include disclosure policies within them. These polices can have three forms (as explained in Annex II of the next implementing regulation on core functionalities):
- ‘No policy’, indicating that wallet users may only disclose electronic attestations of attributes to authenticated relying parties.
- ‘Authorised relying parties only policy’, indicating that wallet users may only disclose electronic attestations of attributes to authenticated relying parties which are explicitly listed in the disclosure policies.
- ‘Specific root of trust’ indicating that wallet users may only disclose the specific electronic attestation of attributes to authenticated relying parties with authentication certificates derived from a specific (or list of specific) root certificate(s).
If present, wallets must check whether the relying party requesting an attribute or information from a PID passes the test specified in its disclosure policy. The good thing is that this always guarantees that only authenticated relying parties (who registered their service at Member State) get access.
But it does very little to technically restrict relying parties to over-authenticate and ask users for more attributes than strictly necessary for accessing their service.
First of all, issuers are in no position to tell which relying parties actually do require their attributes to provide access to their services (especially if one issuer is in one member state, while the relying party is in another). In fact, such decisions should not be made by individual issuers (i.e. PID or attribute attestation providers) but are political in nature and should be made be a competent authority preferably at the European level, overseeing the overall European identity framework. The current setup runs the risk that issuers on the one hand will be too lax in imposing restrictions on relying parties, while on the other hand could overly restrict the use of the PIDs and attestations they issue.
Second, a much more appropriate approach to keep relying parties in check exists: simply add access permissions to specific sets of attributes to the access certificates already given to relying parties. The authority deciding whether the relying party should have access to EU identity wallets at all is in a much better position to determine which particular attributes the relying party should have access to. The wallet then not only checks the authenticity of the relying party, but also whether it is in fact entitled to the attributes it requests to be revealed - by checking the permissions in the access certificates. This is a much more appropriate and privacy preserving method than relying on disclosure policies.
The final implementing regulation covers integrity measures and core functionalities.
Recital 6 should be strengthened to also require issuer unlinkability, i.e. making it impossible for an issuer (i.e. provider of PIDs or attribute attestations) to link the use of an attribute at a relying party with one it issued earlier. The current proposals to technically/cryptographically implement PIDs, attribute attestations and the way they are disclosed do not achieve this. In fact, the current proposals also do not satisfy the current phrasing of Recital 6, unless PIDs and attestations are issued in batch, where each of them are used only once. This is impractical. We refer for details to “Cryptographers’ Feedback on the EU Digital Identity’s ARF”, Baum et. al, June 2024, for details.
Recital 11 requires that wallets support backup and restore of PIDs and attribute attestations. Care should be taken to ensure that such functionality cannot be abused to create duplicates of such PIDs and attestations that can then be shared with others.
Authenticity of wallets is ascertained through wallet unit attestations. Wallets can be revoked by revoking these attestations (Art. 7.3). As explained elsewhere (in the comments on the third implementing regulation addressing the issuing of personal identification data (PID) and attribute attestations), revocation uses a URL embedded in the attestation. The relying party must use this URL to verify the revocation status of the attestation. As also explained elsewhere this reveals which relying party is checking this, and when. If the service pointed to by the URL is hosted by the provider of these wallet unit attestations, this means this provider is able to track exactly when and where a particular is used. Again a flagrant violation of the privacy by design principles the regulation aims to uphold.
Art. 4.2. is oddly specific. There are many more security controls that could and should be implemented. Either mention them all, or none.
Art. 6.2. requires that
Wallet providers shall ensure that the wallet unit attestations […] contain a public key, and that the corresponding private key is protected by the wallet secure cryptographic application.
It is unclear what this is used for, and how a risk of profiling based on this public key is prevented.
Regarding Annex IV, be more specific to which part of the cited WebAuthn recommendation the pseudonym generation should adhere to, because this recommendation does not actually mention pseudonyms specifically/literally.
First and foremost, the current approach of issuing five separate implementing regulations is broken, for two reasons.
First, the different aspects covered by the implementing regulation interact and influence each other. Aspects discussed in core functionality are strongly related to wallet interfaces which resonate with aspects of issuing. Having separate implementing regulations runs the risk of introducing inconsistencies, or that certain small but important issues fall between the cracks and are not properly regulated.
More fundamentally though, trying to properly and precisely specify a technical artefact (like an eID system) through a legal instrument using legal language, will not work. The current implementing regulation proposals are not all specific enough to guarantee certain security and privacy properties, as these fundamentally depend on the nitty-gritty details. Moreover, it will fail to guarantee full interoperability of the different wallets issues by Member States, and all the different providers and relying parties, while such interoperability is fundamental to the success of the eID Wallet. Recall that one of the prime reasons to update and modernise the existing eIDAS regulation was that current (cross-border) use of national eID solutions based on eIDAS is too low. In other words, I would strongly urge the Commission to actually publish the ARF itself as one single implementing regulation instead (after that is also improved and updated based on the critique here and elsewhere, and is extended to include important processes surrounding enrolment and notification).
I already mentioned our “Cryptographers’ Feedback on the EU Digital Identity’s ARF”, Baum et. al, June 2024. Here we showed that properly implementing truly unlinkable PIDs and attribute attestations can be efficiently implemented using formally proven cryptographic techniques under reasonable cryptographic assumptions. Such truly anonymous attribute based credentials would offer much stronger privacy guarantees, and are practical. This should be used as the basis for implementing all attribute attestations and PIDs, to ensure the eID wallet truly achieves the privacy features promised in the regulation.
Current certified trusted hardware devices (secure elements on devices or HSMs used by issuers) do not support the cryptographic primitives used by such anonymous credentials. A temporary measure for device binding (until future trusted hardware components support the necessary modern cryptographic primitives) is to include an additional classic public key in every credential, and prove ownership (using a generic zero knowledge protocol) of the corresponding private key in stored in the trusted hardware component. Efficient zero knowledge protocols to prove such generic statements do exist.