Understanding the EU Digital Identity Wallets’ Architecture Reference Framework
As European Union citizens await a transformation in how they create and handle their identities and personal data, how they control the use of their data by others and generally how they live their digital lives with an EU Digital ID Wallet, a great deal of working is underway on the legislation, standards and usability of the eIDAS 2.0 project.
The Architecture Reference Framework (ARF) v1.0.0 for interoperable EU Digital Identity Wallet Solutions was published by the European Commission in February, a year after the outline. Consortium-led large-scale pilots are getting underway to develop use cases of the digital wallets such as cross-border payments. Code for a template wallet is being developed by the Scytales/Netcompany-Intrasoft partnership, expected later in the year, although little has emerged on progress here.
The ARF is the basis for the reference implementation of the project and will enable the pilots. It is also somewhat conceptual, dealing with notions such as wallet instances and solutions. There are also significant gaps on issues such as unique identifiers.
The Intesi Group, an Italian certification authority, hosted a webinar to try to explain the framework. In ‘Demystifying the EUDI Wallet Architecture Reference Framework,’ Peter Altmann of Sweden’s DIGG Agency for Digital Government explained what some of it means, jumping from Chapter 1 to 4 to 6 to make it clearer.
The ARF is a living document
As only the very first draft, the ARF is a living document, said Altmann. It is part of a feedback loop. Its specifications will feed into the reference implementation (RI), which is the basis for and supports the large-scale pilots (LSPs), whose feedback and proposals feed back into the ARF.
As a document it has no legal standing, says Altmann, but it is not true to say that the LSPs have free rein to experiment. They should focus on “production ready solutions around the use cases.”
National implementations of wallets must be based on the RI, but can include their own software aiming to be open source and opt out of optional modules and plugins. There is a minimum set of modules, but details on these areas are pending.
As are details of “central services” to the ecosystem as stakeholders await official Commission communication.
Digital wallet states, solutions and instances – just add PID
‘Solution’ becomes a little more concrete as a term as it means the whole wallet set up. It is part of the wallet ‘lifecycle.’ An EUDI Wallet Provider will provide a ‘Wallet Solution.’ The provider is a role whilst an individual wallet, downloaded and installed is a Wallet Instance.
The Wallet Solution begins in ‘Candidate state,’ requiring certification from an EU Member State. Once certified and made available, the Solution is then in Valid Wallet Solution state. This change of state is inherited by all the EUDI Wallet Instances linked to that Solution.
Wallet Instances also change state. Once downloaded and installed they are in ‘Operational state’ with limited functionality. At this point they are not bound to an individual’s identity, but can still be used for non-personalized items such as train tickets or loyalty cards.
When the user binds their Personal Identification Data (PID) to the Wallet Instance it is then recognized as a fully functional Valid EUDI Wallet Instance.
Though there are still some issues pending here. Each Member State will decide on how it provisions PID. Every EUDI Wallet Solution must be certified and listed, but it is not yet clear how. Likewise for the fact every PID Provider must be included in a Trusted List, says Altmann.
Standards and use cases
The ARF is based on standards and specifications. These are not necessarily ideal as they were what was publicly available and agnostic to use cases. This does not mean they are preferred standards, say Altmann.
In fact, the lack of mature standards and technical specifications is leading to pressure to develop open-source options. There are discussions at the Commission to have more open-source libraries, but not much is known about this.
Altmann uses the example of security, saying that not every functionality to protect security has to be on the device itself, as a country could have external security features.
It will be very difficult to meet all the eIDAS use case requirements with a single Solution, says Altmann: “I would argue it’s impossible.” He says ARF v1.0 recognizes this situation.
There are two configurations for Solutions at present though others may be added. Type 1 is focused on PID attestation and the non-exportability of secrets, which then impacts backup, recovery and multi device support, he points out.
Type 2 is for use cases not satisfied by Type 1. So, if attestations come from the same configuration (both from Type 1 or both from Type 2) they can be used together. This will not necessarily be the case when they are issued from different configurations.
Unique identifier TBC
It is not yet clear what any unique identifiers – a unique, possibly lifelong number per human – for individuals will be, how they will be defined, how they will be generated. The thorny issue of the identifier looked like it could be removed, but then was managed at least conceptually.
Altmann explains that PID attestation contains both mandatory and optional eIDAS attributes. The mandatory is the “intersection of what all Member States can provide,” albeit with the unique identifier part being unclear.