The European Union (EU) is currently undergoing a substantial update to the eIDAS (electronic IDentification, Authentication, and trust Services) regulation to establish a European digital identity framework. The proposed regulation will help drive adoption of digital wallets for both citizens and businesses. Its main objective is to enable EU member states to issue certified digital wallets and Person Identification Data (PID) attestations to their citizens and residents. As a result, a European resident in one member state will then be able to not only use these attestations inside their home country, but also across the EU, with both public sector and private sector organizations. While EU residents will not be required to use digital wallets, they will have the ability to do so if they desire.
In this article, I will highlight the main technical considerations that the European Digital Identity Wallet Architecture and Reference Framework intends to convey. Keep in mind that the reference framework will change over time as it is still being actively developed and has not been finalized.
I will not discuss the ideas behind decentralized identity, digital wallets, or the concept of issuers, holders, and verifiers, as I have already written extensively about them in prior work. I will focus on the EU vision for digital identity in Europe and their architecture requirements.
Attestation Presentation Flows
The architecture and reference framework focuses primarily on digital wallets for citizen use. Of course, a legal entity such as a corporation can have its own digital wallet on a server somewhere and hold attestations/verifiable credentials that are issued to it, but the main emphasis of the framework is on natural persons that have a digital wallet that can receive, store, and present attestations to verifiers/relying parties. Here are the flows that will be supported for presenting attestations:
- Proximity supervised flow
- In this flow, the holder presents an attestation to another device, acting as a relying party/verifier (such as wallet-to-wallet). The relying party has a human representative that supervises the flow. The presentation of the attestation can be transmitted over proximity technologies such as Bluetooth or Near Field Communication (NFC), and internet connectivity is not required by either device.
- Proximity unsupervised flow
- Similar to the supervised flow, but the relying party does not have a human to supervise the process. For example, presenting an attestation to open a door (i.e. the relying party is a machine without human supervision).
- Remote cross-device flow
- The holder uses the wallet on a mobile device to access a service on another device, such as a laptop. For example, the user scans a QR code presented on their laptop web browser with their phone device, in order to sign into a website or present some other attestation.
- Remote same-device flow
- The user uses the same device, so in this case, an example would be a user trying to present an attestation to a website on their mobile phone, or another mobile app on their phone that is requesting to receive an attestation that is also stored on the same device.
As you can see, these attestation presentation flows cover a wide range of scenarios, only limited by your imagination.
Person Identification Data (PID) Attestation
One of the core themes of the architecture and reference framework is the concept of a Person Identification Data (PID) attestation. Essentially, every citizen of an EU member state will have the PID attestation in their wallet, and this attestation will enable identity verification of the natural person across the EU. Moreover, a PID attestation can also be issued to a legal person. In fact, the wallet isn’t considered to be in a valid state, until the PID is issued to the wallet instance. Of course, a holder may have other attestations, but the PID is essentially a mandatory “genesis” attestation. In many scenarios, a holder will need to present the PID to receive other attestations. The PID attestation states who you are, not what you can do!
In fact, one of the primary scenarios unlocked by the wallet and its PID is the ability to provide a high level of identity assurance, which can be leveraged by both public and private sector relying parties across the EU. Relying parties will be able to confidently verify the identity of users that interact with them in a consistent manner!
Wallet Instance
The wallet instance is a major part of the architecture, and it’s critical that both issuers and verifiers trust the wallet provider, before they issue or verify attestations. A wallet provider must be certified, and a specific installation of the wallet application on a user’s mobile phone is called a wallet instance. The idea is that a wallet provider needs to issue a digitally signed attestation binding a verified wallet instance to a public key, after verifying that the counterparty is running legitimate wallet provider software on the device. When the wallet instance communicates with issuers or verifiers/relying parties, the issuer or verifier will be able to determine the wallet provider that it is communicating with, as well as the specific wallet instance. Of course, this needs to be done in a privacy-preserving manner, but the general idea is that an issuer or verifier will only trust a wallet instance from a trusted wallet provider.
In addition, both issuers and relying parties must verify that a wallet instance has not been suspended or revoked. If the wallet instance has been suspended or revoked, attestations will not be issued to the wallet instance, and relying parties will not be able to trust the presentation of such attestations.
Device Binding and User Binding
Interestingly, the architecture and reference framework emphasize the importance of device binding over user binding. When an attestation is issued, it is bound to the device/wallet instance via a public key being signed as part of the attestation. When an attestation is being presented to a verifier, the verifier will need to verify that the attestation hasn’t been copied or cloned to another device. At this point, the verifier knows that the attestation is being presented from the same device to which it was issued (hence the term device binding). This underscores the centrality of the wallet instance, and its secure cryptographic hardware.
In contrast, user binding would ensure that an impostor human cannot present the attestation, since the attestation usually describes a natural person as the subject. How would the verifier know that it is, in fact, the same human presenting the attestation? Since the wallet instance would require the user to authenticate to the wallet instance before performing any operations such as presenting an attestation to a relying party, it is assumed that an imposter would not be able to take control of someone else’s wallet instance in order to use their wallet instance nefariously. For many scenarios, in order for proper user binding to occur, the verifier may need to perform some sort of biometric verification to make sure that the attestation is being presented by the legitimate owner, and so the ability of the relying party to perform user binding will depend on the attributes in the issued attestation as well as on the specific presentation flow type.
As a result, the focus of the architecture and reference framework is on device binding, which is the more appropriate term, rather than on user binding. At the very least, with device binding, the attestation can be verified that it is being presented from the same physical device to which it was issued. Assuming it was issued to a legitimate device and user, user binding verification may not be necessary in all cases but may certainly be necessary to achieve higher levels of assurance.
Device binding and user binding are orthogonal to each other. Device binding is sometimes called proof of possession or key binding, while user binding is also known as holder binding. In essence, device binding is cryptographic in nature, while user binding is biometric in nature.
Trust Registries
There are trust registries for all the actors involved, and trust anchors that need to be established on a common trust infrastructure. The following entities need to be trusted and verified:
- Wallet providers
- Attestation providers/issuers
- Relying parties/verifiers
A wallet instance needs to trust an issuer and a verifier before it can transmit information to them. While the wallet instance will not check the digital signature on received attestations, it plays a central role in working in tandem with the user to ensure only the relevant information is transmitted to relying parties. If a wallet instance cannot determine the trustworthiness of issuers or verifiers, it will instruct the user about it. The entire EU digital identity ecosystem is based on trusted lists. For example, the relying party will receive the trusted list of wallet providers and attestation providers, so it will be able to trust the specific wallet instance that it is interacting with, and of course also trust the issuer of the attestation.
It’s important to point out that attestation providers can be broken down into two broad categories:
- Qualified electronic attestation of attribute providers
- Non-qualified electronic attestation of attribute providers (also known as electronic attestation of attribute providers)
The Person Identification Data (PID) attestation, as well as government-issued attestations such as driver’s licenses are considered qualified and will be chained to a trust anchor in a trusted list registry. Relying party verifiers will trust qualified attestations by default. For example, a relying party that verifies a PID or a driver’s licenses will not need to verify whether or not the specific issuer of that attestation has authority to issue that type of attestation, since the relying party knows that the entity that issued the attestation is on a trusted list of entities that has been vetted by an authority. As well, it is foreseen that qualified electronic attestation of attributes will be issued and presented across EU member states, so they need to be recognized broadly across the EU. Member states will need to provide the trusted lists for the qualified electronic attestation providers. Qualified electronic attestations have the same legal validity as a paper document.
Non-qualified electronic attestations of attributes, while cryptographically similar to qualified ones, do not hold the same legal status, and will be less regulated than qualified attestations. For example, a gym membership or a bus ticket may be examples of non-qualified electronic attestations. In some scenarios, non-qualified attestations of attributes will be issued and presented in a local region, and may not require the same level of legal, trust, and interoperability needs as qualified attestations of attributes. As a result, the architecture and reference framework focuses on qualified electronic attestation of attributes and their trust registries while indicating that non-qualified attestations are domain-specific, and their trust anchors and legal status are out of scope of the regulation. Non-qualified electronic attestations may or may not have the same legal validity as a paper document.
Importantly, both qualified and non-qualified electronic attestations of attributes require a schema, and so the EU will work on having schema providers that will be able to describe the vocabulary, structure, and semantics of attestations to enable interoperability across the EU.
Digital Signatures and Seals
The architecture and reference framework is designed to accommodate use cases that involve the digital signing of any data, both by natural persons as well as legal persons via electronic signatures. The standard use case for digital wallets is to be able to request and receive digitally signed attestations, store them, and then present them when needed to relying parties for verification to gain access to a product or service. As a result, the typical use for the attestations is more transient in nature – the relying party simply needs to be satisfied with the presented attestation to “unlock” the service. To that end, the relying party will verify that the issuer of the attestation is authentic and can be trusted, perform device binding, and also potentially perform user binding verification.
In contrast, digital signatures will enable the user to sign large documents, such as mortgage loan agreements, which will be qualified, (i.e. legally binding via a qualified electronic signature). As a result, there will be specific services that can offer qualified electronic signature capabilities, both on the user’s device and remotely, including cryptographic device hardware such as hardware security modules (HSMs). Such services will need to provide a high level of assurance for the individual signing the document, timestamps of when the document was signed, protection and safeguarding of cryptographic private key material, amongst other important considerations.
Electronic signatures made by people and electronic seals (signature capability of legal entities) are advanced capabilities and most digital wallets in use today do not offer this functionality. However, the EU is expecting that the digital wallet ecosystem and trust services will enable this capability in the future.
Final Thoughts
It is quite clear that the EU has very ambitious plans for digital access to products and services across the EU. Yet, the architecture and reference framework does not dive deeper into a lot of the technical details about how this will all be implemented, and leaves a lot of open questions, specifically around the technical implementation. However, the primary purpose of the architecture and reference framework is to provide architectural requirements that the various ecosystem actors will need to meet – the focus is on the what, more than the how.
It’s challenging enough to implement this well inside of one EU member state, but doing this across the approximately 27 EU member states and ensuring interoperability among them is certainly a very high bar.
Finally, the centrality of the digital wallet cannot be understated. Unlike traditional federated identity architectures, the digital wallet will be the ultimate user agent that places the individual human at the center of all interactions – both on the issuance as well as presentation sides. In fact, the user may use the digital wallet instance to file complaints about relying parties asking for data that they shouldn’t be and instructing relying parties to remove personally identifiable information (PII) they have shared with them in prior interactions. In addition, user privacy must be maintained (e.g. through pseudonymous identifiers), and all interactions must be secure. The user should also be able to use the digital wallet to view the history of all the relying parties that they have interacted with, including the specific attributes that a relying party requested and the attributes that the user presented.
Only time will tell how much of all this will end up being implemented and used in practice, but the hard work that the EU is currently undertaking may end up paving the path for international/global interoperability that currently appears as a distant utopian dream.