EUDI Wallet: Technical aspects (Part 1)
In our last article, EU Digital Identity Wallet we presented the user centric aspects as one of the key elements of the EUDI Wallet’s potential success. While the technical specifications laid down in the EUDI Architecture and Reference Framework (ARF) are already being tested through different use cases within Large Scale Programs (LSPs), we can reflect on this occasion on how users can obtain their Verifiable Credentials (VCs) or attributes and store them in their wallet. In this perspective, particularly interesting will be to identify how the EUDI Wallet’s ecosystem anticipates to protect the privacy of our data with the implementation of Person Identification Data (PID).
On EUDI Wallet’s different states
EUDI Wallet can have different states because its holder can use it for multiple use cases, even for those where relying party or the verifier does not necessarily need a high level of assurance (LoA). We will see below that two states of the EUDI Wallet are occurring in the EUDI Wallet Instance lifecycle. As indicated in EUDI ARF version 1.0.0, an “EUDI Wallet Instance starts its life based on a valid EUDI Wallet Solution.”
In the Operational state of the EUDI Wallet Instance:
· The User can request an attestation, such as a PID, which will contain identity data. The EUDI Wallet Instance may also fulfil non-EUDI specific functions, like storing loyalty cards, or any other type of certification that does not explicitly necessitate a link to a valid PID.
In the Valid state of the EUDI Wallet Instance:
· Once an EUDI Wallet Instance holds a valid PID set, it is considered valid. At this moment, the User can add Qualified Electronic Attestation of Attributes (QEAA) or Non-Qualified Electronic Attestation of Attributes (EAA). QEEA is coming from trusted sources, and the attributes as such can be diplomas, or certificates, like residence certificate. EEA is coming from unqualified sources, but EUDI Wallet holder can trust that EEA issuer is authentic. Let us consider an example of a rail membership program where individuals can sign up to access special privileges and services offered by the rail company. In this case, the rail company does not need to be a qualified provider because the usage and the verification process is limited to the rail company itself and does not imply a third party.
· It is worth mentioning that if the PID expires or is revoked, the EUDI Wallet is not automatically unusable, its state is merely downgraded back to operational. This may affect the validity of a (Q)EAA or a certificate for electronic signatures and seals (QES).
Figure 1: Adapted from EUDI ARF version 1.0.0 "EUDI Wallet Instance Lifecycle"
The Person Identification Data (PID): the root trust of your digital identity
eIDAS Regulation defines PID as “A set of data enabling the identity of a natural or legal person, or a natural person representing a legal person to be established.”
The revision of the eIDAS Regulation specified in Commission Implementing Regulation (EU) 2015/1501 (hereafter Regulation (EU) 2015/1501) defines the minimum data set as:
· PID set of mandatory attributes is unique to each person.
· The PID set should at least contain the minimum set of attributes specified in Regulation (EU) 2015/1501 (Shown on the Table 1 below) as mandatory.
· The mandatory data set is by nature limited to what all Member States (MS) can provide for all natural and legal persons.
· The optional data can be different, and each MS can select the ones suitable for them. Table 1 below is showing few possible examples.
Table 1: Adapted from EUDI ARF version 1.0.0 "PID Attributes for Natural Persons"
For having PID stored on the mobile phone, users will have to complete a series of carefully monitored and governed processes to validate their identity. The ARF does not define how PID should be issued, so MS can rely on their existing national solution. The uniqueness about this state of the VC Configuration is that it can only be issued by the trusted issuers.
It is possible for the PID provider to use identification documents like passports or ID cards as a trustworthy source for PID attributes. These documents contain a contactless chip that can be read with a mobile phone, just like when you use your phone to make contactless payments. The chip in these documents holds digitally signed data about the person it belongs to, and this is where the Visogo solution from INCERT comes in. Visogo can help the PID provider to confirm if the data stored on the chip is authentic. It ensures that the information has not been altered or tampered with, so the PID provider can rely on its authenticity and accuracy.
Now that we have presented the different states of a wallet, their two main conditions, captured by the fact that both instances of EUDI Wallet can work independently, we ask ourselves how the privacy of our data will be maintained in the EUDI wallet’s ecosystem.
EUDI Wallet and privacy of User’s data
There has been a substantial (technical and legislative) effort put on the EUDI Wallet’s security and privacy mechanisms. For example, attention has been put on the fact that issuer of a VC (let us imagine an educational institution) cannot track back from different verifiers (let us imagine an employment agency, potential employer, ...) with whom users shared VC they issued. This therefore is eliminating the possibility for external stakeholders to get ahold of EUDI Wallet users’ data for commercial profiling.
This is particularly sensitive for the PID, where users are expected to share their attributes in various occasions and use cases, and in the case of VCs revocation, where verifiers will contact issuers when an attribute is no longer active, or removed. Nevertheless, keeping the User at the center of the wider European Digital Identity strategy, the EUDI Wallet is based on the trust system of all stakeholders involved.
Alongside of the EU wide trust system on which EUDI Wallet is based, initiatives currently exist which propose additional privacy preserving approaches. These are going to be explored during the LSPs testing, underlining their potential. Specifically, we are referring here to Zero Knowledge Proofs (ZKPs). What are they and what they promise to bring, we will explore in our next article.