Menu Close

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. 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.  Read More   

Generated by Feedzy

Disclaimer

Innov8 is owned and operated by Rolling Rock Ventures. The information on this website is for general information purposes only. Any information obtained from this website should be reviewed with appropriate parties if there is any concern about the details reported herein. Innov8 is not responsible for its contents, accuracies, and any inaccuracies. Nothing on this site should be construed as professional advice for any individual or situation. This website includes information and content from external sites that is attributed accordingly and is not the intellectual property of Innov8. All feeds ("RSS Feed") and/or their contents contain material which is derived in whole or in part from material supplied by third parties and is protected by national and international copyright and trademark laws. The Site processes all information automatically using automated software without any human intervention or screening. Therefore, the Site is not responsible for any (part) of this content. The copyright of the feeds', including pictures and graphics, and its content belongs to its author or publisher.  Views and statements expressed in the content do not necessarily reflect those of Innov8 or its staff. Care and due diligence has been taken to maintain the accuracy of the information provided on this website. However, neither Innov8 nor the owners, attorneys, management, editorial team or any writers or employees are responsible for its content, errors or any consequences arising from use of the information provided on this website. The Site may modify, suspend, or discontinue any aspect of the RSS Feed at any time, including, without limitation, the availability of any Site content.  The User agrees that all RSS Feeds and news articles are for personal use only and that the User may not resell, lease, license, assign, redistribute or otherwise transfer any portion of the RSS Feed without attribution to the Site and to its originating author. The Site does not represent or warrant that every action taken with regard to your account and related activities in connection with the RSS Feed, including, without limitation, the Site Content, will be lawful in any particular jurisdiction. It is incumbent upon the user to know the laws that pertain to you in your jurisdiction and act lawfully at all times when using the RSS Feed, including, without limitation, the Site Content.  

Close Bitnami banner
Bitnami