eIDAS Architecture Reference Framework 1.0

Thoughts on ARF from DIDAS Technology Working

Earlier this year, the eIDAS Expert Group published the first version of the Architecture Reference Framework (ARF), which lays the foundation for the future European Digital Identity (EUDI) Wallet Infrastructure. For us at DIDAS, it represents a very exciting moment, as we are facing the final phase of the Swiss E-ID Law development and already work on pilots to explore and showcase what is possible.

We strive for the broadest interoperability between all European Digital Identity (and hopefully worldwide) initiatives. Beyond pure technical interoperability (e.g., at the protocol level), it’s crucially important to highlight potential differences in approaches to ensure that the ideas and principles that went into our input to the Swiss E-ID Law are also reflected in the eIDAS work.

After all, our raison d’être – and our responsibility – is to advocate for the advancement of digital processes in society while respecting the privacy and digital sovereignty of Swiss citizens.

First, we’d like to point the interested reader to the excellent series published by Andrew Tobin , where he goes in-depth into the ARF and highlights, in an easy-to-understand language, a few aspects that require special attention, e.g., the potential complexity of managing the ecosystem and ensuring trust at national levels, correlation of credentials’ usage, etc.

We also would like to thank the authors of the document for the demanding work that went into its creation. We believe that many good choices have been made. The proposed approach does pave the way to an exciting future where everyone can take full advantage of the continuously evolving digital services in a privacy-preserving manner and be in control of their data!

We realize that this is version 1.0 of a framework, and a lot of work went into making it acceptable for a variety of players.

In this Blog post, we’d like to share our view on some of the critical aspects of the ARF, considering both the technical and user-experience implications of the proposed Reference Framework.

The Trusts Lists – minimizing complexity.

Let us start by looking at a foundational topic: how will wallets and their users know if they are dealing with a trusted issuer or a verifier? This is where the so-called “Trust Lists” come into play. They are meant to be directories where wallets can look up a counterparty’s identifier and determine their status. The ARF proposes many lists, mainly to allow flexibility and accommodate the unique requirements of the member states.

This, however, will potentially lead to hundreds of them and will, arguably, make the overall system less secure and confusing. From our standpoint, a better approach would be to use credentials: each issuer and verifier must present a credential (e.g. EBSI proposal) , which will certify to the user’s wallet that they are authorized to issue or request a particular set of credentials with a known schema. This way, the system becomes much more manageable and resilient and is built of the same building blocks throughout. While, at the same time, allowing for regional variations.

An essential enabling factor for this is going to be a robust governance framework, which should regulate and enforce the rules for these credentials, including the attributes of the schemas.

The user wallet then will have a much easier job of “advising” its users of whether a specific data exchange is a good idea, promoting trust and improving overall usability and acceptance.

Lose your phone, lose your wallet?

Another foundational aspect currently not well highlighted in the document is the topic of what happens in case of a lost wallet or a need to upgrade to a new phone. Both are related to the issue of cryptographic key lifecycle management. From our standpoint, this is both a technical and a user acceptance topic.

Without clear guidance on what happens when a user wants to either upgrade their phone or deactivate the wallet on a lost phone, it’s hard to imagine that a wide adoption will occur. A well-thought-through user experience is necessary here.

The ability to move data between devices is not only a user-experience topic. It is also a question of Data Self-Sovereignty, which is one of the fundaments principles of Self-Sovereign Identity (SSI) and a real need, or even a right of today’s and future citizens.

Technically speaking, this can be enabled via known techniques where keys can be migrated between secure elements (e.g., cloning/backup procedure for HSMs). Or more modern, scalable approaches, e.g., W3C DIDs or KERI (Key Event Receipt Infrastructure), where key rotation is built-in, and a stable identifier is independent of the underlying key material.

Are PIDs complete?

Personal Identification Data (PID) is clearly a big focus of the current version of the framework. When we consider which attributes fall under the definition of PID, we see that name and date of birth are mandatory. The current address is, however, optional, and a photo is missing. The latter should be added to make a PID-carrying wallet an equivalent of a conventional ID card (user experience again).

When we return to the optionality of an address, we notice that it creates uncertainty. If a given use case requires an address (such as onboarding at a bank), then the verifier’s system cannot rely on PID to provide that information since it is optional. This means that a separate proof request (and a corresponding credential) will have to be made, complicating the system’s overall design.

A better way from our viewpoint would be to plan for a more fine-grained approach from the very beginning and allow additional, “high-resolution” PID credentials such as “Proof of Residence” (“Wohnsitzbestätigung”) to be provided at the ecosystem level from the start.

The beauty of an SSI ecosystem, after all, is that multiple credentials and their attributes can be combined for a particular use case. A highly desirable outcome!

With that in mind, we recommend that a mechanism be put in place to allow the ecosystem players to onboard new types of “PID” credentials and thus continuously expand the EUDI’s capabilities. A good example of this is an “Official Organizational Role” (OOR) credential that has been pioneered by GLEIF (Global Legal Entity Identifier Foundation).

Privacy by Design?

This is perhaps one of the most significant areas of concern for us. The non-negotiable, essential requirement for an electronic identity/verifiable credentials solution is to ensure that the users can’t be tracked as they conduct their daily life.

For that to be true, two key assumptions must be guaranteed:
• First, validity verification must occur without any data being leaked about the presenter or the circumstances of a credential’s usage.
• Second, there should be no data in the credential itself or in the verification protocol, which allows to correlate the user across touch points.

ARF mentions the first aspect in the section on qualified verifiable credentials (aka QEAA). Still, it is missing from the sections that define PID Providers and non-qualified credentials’ issuers (EAA). We interpret that omission as a signal that both latter categories are not subject to this requirement. This is, in our opinion, an unacceptable proposition.

The second aspect is also not well represented in the document. The SD-JWT and mDL, the first couple of technologies proposed to carry verifiable credentials, can’t guarantee that the users won’t be correlated across their activities.

One of the good things about the framework is that it settles on OpenID Connect for Verifiable Presentations as its primary enabling technology. A key feature of that specification is that it is agnostic to the format of a verifiable credential. So, more privacy-friendly credential technologies can be used.

As we think about alternative credential formats, we also need to consider the thorny question of revocations. It is unclear how revocations, beyond just a simple expiration mechanism, will be made functional under the framework. However, it is, without a doubt, a must-have feature for many use cases.

Scalable, privacy-preserving revocation mechanisms are notoriously difficult to implement. The momentum created by this much-needed EU-wide initiative gives us a chance, however, to accelerate and advance the research that has been taking place in the last few years. The rush to market and “pragmatic” conventional choices that can be made to enable it should be reconsidered. Our societies deserve a truly person-centric, privacy-preserving solution, which will finally help us to get rid of paper credentials and thus lay a solid foundation for truly seamless digitalization.

That is what SSI is all about, and that’s what we at DIDAS passionately strive to enable!