Findynet Cooperative feedback to eIDAS implementation regulation

Background

The European Regulation 2024/1183 (11 April 2024) on establishing the European Digital Identity Framework entered into force on May 19^th, 2024. The regulation amends regulation 910/2014 on electronic identification and trust services for electronic transactions in the internal market, also known as eIDAS. In addition to the original regulation and the amendment, the consolidated text is also published in the EUR-Lex service.

The regulation mandates that the Commission establish lists of reference standards, specifications, and procedures to implement the regulation. The Commission will do this through implementing acts. The drafts of the first implementing acts are published for views and feedback.

General comments

The eIDAS regulation sets a high bar for the security of the European identity wallets. The wallets need to be certified in all member states, they need to present evidence about their capabilities to the providers (issuers) and relying parties (verifiers) of electronic attestations of attributes (verifiable credentials). The combination of strict requirements on functionality and the fact that the use of wallets must be free to individuals poses an interesting challenge to wallet providers.

We believe that the current ways of conducting business online need improvement. We often don’t have the means to be sure who we’re interacting with. This leads to all kinds of fraud, phishing, and scams. The revised eIDAS regulation and the draft implementing acts are one attempt to solve this issue. The proposed solutions – including wallet unit attestations, relying party access certificates, registration of issuers, etc. – may tackle a part of the problem. However, there seems to be a lot of emphasis on the technical security of the wallets. We don’t believe that most of today’s fraud results from breaking the security features of our Internet browsers or e-mail clients.

We believe that the technical capabilities of digital wallets would be sufficient even without the eIDAS regulation and the implementation acts. The question “Who am I interacting with?” should get more emphasis than “Can we rely on this piece of software?”

The implementing acts try to answer the question of who is who with the same methods as the original eIDAS regulation: chains of public key certificates, lists of trusted lists, and nationally accredited trust service providers. While there is nothing inherently wrong with these technologies, they will not scale to support our digital everyday life beyond cross-border authentication to some public sector services.

The proposed approach may lead to a world where Europeans need one wallet to log in to their national public online services and another that they use in global and private sector contexts.

Organization identity and wallet

The eIDAS regulation states that European digital identity wallets should be provided to natural and legal persons (article 5a). The regulation mentions legal persons on multiple occasions. We feel like the implementing regulation drafts were written with mostly natural persons in mind. The implementing regulation on person identification data doesn’t seem to consider legal persons (e.g., family_name_birth and sex as mandatory attributes).

The implementing regulation drafts define ‘wallet user’ as a natural or legal person, and then mostly talk about wallet users. For example,  article 5 of the integrity and core functionality implementation regulation draft refers to the Implementing Regulation (EU) 2015/1502 when talking about the electronic identification of wallet users. Here, ‘wallet user’ presumably means a natural person operating the wallet – not the legal person who owns the wallet. (A legal person cannot be authenticated using at least two authentication factors as required by 2015/1502 level high.) The distinction between a wallet owner and the person operating the wallet should be clarified. The operation of a legal person’s wallet should be automated while retaining clear accountability over automated actions.

We hope that the wallets will let also legal persons conduct business in a secure, trusted, and seamless way across borders.

Trust framework

The implementing act on Trust Framework mentions a secure electronic notification system, through which the member states can notify the Commission of the wallet providers, issuers of person identification data (PID), registrars of relying parties, identity scheme, and wallet validation mechanism. The Commission will then compile this information into lists and publish those lists – like the current eIDAS trust service providers and their services are published. There’s not much more in the draft, which is surprising given the context of the digital identity ecosystem.

It’s unclear from the draft whether this notification system works in real-time or if there is a delay in processing the member states’ notifications.

Every time a user presents an attestation from their wallet, the wallet should verify the relying party’s access certificate – using the lists published by the Commission as a source of truth about the certificate’s issuer. While this model works for current eIDAS trust service providers, we doubt whether it can scale to support hundreds of millions of daily digital wallet transactions and hundreds of thousands of relying parties. Should the list publishing service be compromised, unavailable, or slow to respond, the consequences to wallet users and ecosystems will be significant.

The trust framework doesn’t answer questions about liability. It might be challenging to use the framework in high-stakes, high-security use cases like authorizing bank transfers if it is unclear who compensates who in case of fraudulent user authentication.

The implementing act should state that the European identity wallets, providers of PID and electronic attestations of attributes, and relying parties use OpenID Federation protocol to publish and query information about issuers and verifiers. The Commission would host a root node of that federated trust framework, publishing official statements about the member states’ nodes. In addition to public sector organizations, associations like IATA could apply for formal recognition as a root of trust in their sector. This approach allows for more flexibility and embedding each ecosystem’s rules into the trust framework.

Integrity and core functionalities

There are interesting definitions. The ‘provider of person identification data’ means a natural or legal person responsible for ensuring that the person identification data of a user is cryptographically bound to a wallet unit. Does the Commission believe that natural persons (individuals) could act as PID providers in the EU? Is the cryptographic binding the main task of the PID provider (instead of e.g., authenticating the person)? A ‘wallet relying party’ means a relying party that intends to rely upon wallet units for the provision of public or private services by means of digital interaction. Do the relying parties rely upon wallets digitally or do they offer digital services? We assume that the relying parties can request information from digital wallets even when they offer offline, analog, brick-and-mortar services.

The annex for this implementation act lists three embedded disclosure policies for electronic attestations of attributes. The first is labeled ‘No policy’  but even it seems to prohibit data sharing with unauthenticated parties. We anticipate that in addition to high-security use cases, there will be situations where convenience should override security. As a chess player, you might want to share some information (e.g., FIDE rating, proof of participation in at least 5 tournaments, and the membership credential of a local chess club) with the organizer of a small chess tournament even if the organizer hasn’t been registered as a wallet relying party.

We believe that to be successful, digital wallets should cater to both high- and low-security use cases. The instructions on how to behave in each situation could be embedded in the verifiable credentials or the credentials could point to a registry stating the rules to be applied when handling that credential. While more complex, that mechanism would support more real-life requirements than a simple 3-tier disclosure list and the requirement to register all relying parties.

Person identification data and electronic attestations of attributes

A special credential type supported by the European identity wallets is the person identification data (PID). It can be used to identify the wallet holder.

The draft says: “Providers of person identification data shall issue the person identification data to wallet users in accordance with the electronic identification schemes under which their wallet solutions are provided.”

The idea that wallet solutions are provided (and certified) under PID providers’ eID schemes seems like a tail is wagging the dog. Does “their” refer to the wallet users or the PID providers? We understand that the PID providers follow their identification schemes, the wallet solutions are certified by member states, and a wallet user should be able to choose any wallet solution certified by a country whose PID the user wants.

Compared to just 4 mandatory PID attributes in the ARF 1.4 PID rulebook, the draft implementing regulation specifies 12 mandatory attributes. Four are related to PID issuance, but the 8 others are person’s attributes. There are also 18 optional attributes, and each PID provider may choose a set of attributes they issue into a PID to ensure its uniqueness.

Consider a digital service that needs to store values of family_name, given_name, birth_date, family_name_birth, given_name_birth, birth_place, sex, nationality, birth_state, and birth_city about all users from one country and values of family_name, given_name, birth_date, resident_address from another country – only to know that the returning user is the same person who used the service last week. All the services would need to investigate each member state’s digital identity scheme to find which attributes need to be queried from a country’s PID to identify people.

A single string is the simplest way to identify users. The optional personal_administrative_number attribute should be made mandatory (and renamed personal_administrative_identifier, since it often contains other characters besides numbers). Countries that don’t have a suitable identifier could generate the string when issuing the PID.

We understand that a unique identifier wouldn’t solve the problem of existing users in all cases. If Mohammad Mohammad, John Smith, or Wang Li wants to use his identity wallet to log into his bank’s online service, the bank will have a hard time matching their identity with customer records. Identity matching can be done by the holder presenting other credentials (e.g., the passport they showed when the bank first authenticated them) and probably should be out of the scope of the implementation regulations.

The person identification data seems to be specified with only natural persons in mind. The implementing regulation should also include attributes of a legal person’s identification data.

Revocation

The draft implementing regulation for person identification data and electronic attestation of attributes sets a requirement for revocation notification: “Where providers of person identification data or electronic attestations of attributes have revoked person identification data or electronic attestations of attributes, they shall inform wallet users subject of those person identification data or electronic attestations of attributes without delay of the revocation and of the reasons for the revocation. This shall be done in a manner that is concise, easily accessible and using clear and plain language.”

This requires that all providers of electronic attestations (issuers) store electronic contact information (e-mail addresses) of all wallet users (holders) for the validity period of the electronic attestations of attributes (verifiable credentials) they issue. In addition, all wallet users must keep this information up to date with all providers of electronic attestations. A holder might not wish to release their contact information with all issuers. They should be able to opt out of communication from an issuer, even if that means they miss the notifications about the revocation of their verifiable credentials. A holder’s wallet might still inform the holder about the revocation status of their verifiable credentials.

The requirement to inform a wallet user should be mandatory only in cases where the user has shared and maintained their contact information. The implementing regulation could refer to a standardized way the attestation providers can use to notify the wallet user (e.g., the DIDComm protocol).

The draft also requires:
“4. Providers of person identification data or electronic attestation of attributes issued to a wallet unit shall revoke that data or attestation, in each of the following circumstances:
– –
(c) upon becoming aware of the death or dissolution of the wallet user;
(d) upon becoming aware that the value of one or more attributes in the person identification data or the electronic attestation of attributes have changed;
(e) where the wallet unit to which the person identification data or electronic attestation of attributes was issued to has been revoked;
5. Providers of person identification data or of electronic attestation of attributes issued to a wallet unit shall ensure that revocations cannot be reverted.”

4(e) and 5 together hurt the user experience of the European identity wallet. Consider that a wallet provider notices a flaw in a version of their wallet and decides to release a new version and revoke all old versions. Revocation of the wallet unit itself should suffice to render all person identification data and electronic attestations of attributes in the revoked wallet units unusable. (The relying parties asking for PID or attestations  should not accept them from a revoked walled unit.) When the wallet users upgrade their wallet units to a new version, they should be able to use their PID and attestations again. Re-applying and issuing the PID and all (possibly hundreds of millions of) attestations of all affected users of revoked wallet units is a massive effort to both wallet users and providers of person identification data and electronic attestations of attributes.

Does 4(c) imply that the providers of electronic attestation of attributes must actively seek information about the death of the persons to whom they have issued attestations? (E.g., should a university request a national population authority to inform them whenever one of their alumni dies so that the university can revoke the academic credentials of that alumni?) If a bank has issued an electronic attestation of attributes stating the IBAN address of the bank account, should that attestation be revoked when the account owner dies? Suppose the deceased person has provided this IBAN credential to all organizations that make payments to her. In that case, revocation of the credential stops these payments from occurring even if the payments are still valid and should be paid to the same account – now owned by her death estate.

The article concerning revocation should be rewritten completely. The implementing regulation should give guidance on the technical revocation methods and standards to ensure interoperability between issuers, wallets, and relying parties. The electronic identification schemes and rulebooks of electronic attestations of attributes should be able to state the situations when the credentials are revoked. At the minimum, 4(e) should be removed from the implementing regulation.

In the draft annex, JSON is misspelled as ison.

Protocols and interfaces to be supported

The draft implementing regulation states: “Wallet providers shall ensure that wallet solutions request person identification data and electronic attestations of attributes only from parties having an authentic and valid wallet relying party access certificate issued to a provider of person identification data or provider of electronic attestations of attributes.” So, issuers must have a relying party access certificate. (Usually, the term relying party refers to the organization that requests and receives information from a wallet.) In our analog wallets, we may carry driving licenses, payment cards, membership cards, loyalty cards, discount tickets, etc. Some have electronic chips and holograms, some are printed on cardboard. It’s easy for a company’s lunch restaurant to print lunch tickets and easy for employees to hold them in their wallets since our analog wallets support low-security credentials. It is great that European identity wallets will enhance security and trust by supporting high-security use cases like authentication to public services. It would be sad if they didn’t also support low-security use cases like holding lunch tickets.

A wallet user might want to hold their academic credentials from an American university in their digital wallet and present them to a Japanese verifier – even if those organizations don’t have relying party access certificates listed in European trust registries. We will hinder the adoption of digital wallets and make everyday life more complicated for people if a European citizen cannot hold their passport, a British Airways flight ticket, and a Visa issued by an African country in the same wallet.

The trust architecture of the wallets should be re-designed so that the wallets can distinguish trusted issuers from untrusted ones and trusted verifiers from untrusted ones – with some shades of gray. The European digital identity trust framework should be just one of the frameworks the wallets could support. Many digital wallets that are currently available allow users to request and hold verifiable credentials from whomever they want. They should be able to be certified as European digital identity wallets by supporting the eIDAS regulation and its implementation regulations – without the requirement to not accept credentials from sources in other jurisdictions.

The Annex contains only one protocol related to the presentation of attributes (ISO/IEC 18013-5:2021). We believe that other protocols already mentioned in ARF 1.4 (most notably OID4VCI and OID4VP) will be added at some point. The implementation regulation annex should also clearly state which protocols wallets must use to support articles 6 (communication of data erasure requests) and article 13 in the integrity and core functionality implementing regulation draft (data recovery and portability). Also, functionality specified in article 7 (reporting of relying parties to supervisory authorities) could be implemented using a single protocol or a limited set of protocols.

Certification

A wallet must be certified separately in each member state. All member states can have separate certification schemes. This will incur lots of overlapping work when creating the schemes and certifying wallet solutions. We fear that many wallet providers will delay the certification of their wallets until there is either cross-border recognition of certification between member states or a Union-wide, harmonized certification scheme. The proposed certification mechanism might lead to exactly one digital identity wallet in each EU member state, with no competition, and no drive for wallet providers to develop excellent user experience.

We hope that member states collaborate when creating their certification schemes and possibly in their certification activities, and that a uniform scheme will emerge sooner rather than later. We also see the benefits of a global – rather than a European – digital wallet certification scheme.

Conclusion

We thank the Commission for the possibility of giving feedback on the draft implementation regulations. We hope that future versions of the regulations will better support legal persons and different levels of security. The underlying trust model should be more flexible and implemented using modern protocols. The success of the revised eIDAS regulation depends on the sustainability of the business models of attestation issuers, relying parties, and wallet providers. We hope to see cross-border cooperation on wallet certification and look forward to a harmonized certification framework. The European identity wallets should support free movement within the European internal market and be usable in global use cases outside Europe.