Framework Document Section

Text from EU Digital Identity Framework And Reference Document

Comment Suitable For External Publication

3

This is very positive. It explicitly confirms that qualified (issued by authorized and certified Qualified Trust Service Providers or QTSPs) and non-qualified (issued by any organization like a bank, gym, airline) electronic attestations (also commonly called “credentials”) can co-exist in the same wallet at the same time. 

This is important because, unlike eIDAS Regulation, it makes the wallet far more useful for non government use cases. This will significantly increase adoption and use and give eIDAS 2.0 a really good chance of succeeding. 

3.1

The EUDI Wallet would enable end-users to create qualified electronic signatures and seals (QES).

This confirms that the wallet will enable citizens to sign documents with legal value. It’s another good step forward in harmonizing digital signing which should enable streamlining of many paper-based wet-signature processes.

Additionally, it will be possible for the wallet to authorize a 3rd party provider to execute the signature process, meaning that the wallet will not necessarily need to have all the complex QES functionality at the edge (e.g., in an app on a mobile phone) making wallet apps smaller and simpler. 

While this is an important capability of the EUDI Wallet, it is recommended to give the citizens the possibility to choose which QTSPs they prefer for the issuance of digital certificates.

3.2

EUDI Wallet Issuers are Member States or organisations either mandated or recognized by Member States making the EUDI Wallet available for end users. 

As expected, but not good for the overall eIDAS ecosystem. 

Individual certification rules for individual member states will make things difficult and expensive for wallet providers which will result in limited choice for citizens. 

This seems an obvious opportunity for EU harmony and for a single wallet certification scheme to work across the EU, so a wallet only needs to be certified once to be usable in any member state.

3.3

Personal Identification Data (PID) providers would verify the identity of the EUDI Wallet user, maintain an interface to provide PID securely to the EUDI Wallet (in a harmonized common format), and make available information for relying parties to verify the validity of the PID, without having an ability to receive any information about the use of the PID.

This looks positive. It appears to confirm that unlinkability of data, (i.e. preventing a credential issuer from seeing what the holder (citizen) is doing with that data) is a requirement. 

This goes a long way in preventing the correlation of a citizen’s online activities by a credential issuer.

Care needs to be taken if the Commission is contemplating use of the mechanism employed for ISO 18013-5 mobile driving licences, which explicitly enables verifiers to contact issuers when used in online mode. 

3.5

Qualified EAA (Electronic Attestation of Attributes) would be provided by QTSPs (Qualified Trust Service Providers).

Confirms the Commission still plans to use QTSPs to make the link between the person and the data, and issue government-backed high assurance credentials.

There’s no real surprise here, but it would be good to see data coming directly from governments. However QTSPs do provide a valuable service in creating the tight linkage between individuals and their data, and ensuring it keeps up to date. This approach also provides a nice bridge for the existing eIDAS 1.0 service to be smoothly enhanced for eIDAS 2.0.

3.6

Non-qualified EAA “NQEAA” can be provided by any trust service providers. While they would be supervised under eIDAS, it can be assumed that other legal or contractual frameworks than eIDAS would mostly govern the rules for provision, use and recognition of EAA.

This is both good and bad.

It allows any organization to issue data into the wallet for any purpose. This is exactly what will encourage continent-wide uptake, as it enables privacy and security for thousands of use cases.

But, we need clarity of what “supervised under eIDAS” means. 

While an “NQEAA” would have to adhere to interface specs, etc., what other “supervision” would be needed and how would it be implemented. And by whom?

3.10

To rely on the EUDI Wallet, relying parties would need to inform the Member State where they are established and their intention for doing so.

This might place a block on private sector usage. It is unclear why relying parties would need to “inform” a Member State. My local shop does not need to inform the government that it wants to check driving licenses to verify customer age.

Just because the data is now coming within a digital bearer, rather than on a piece of plastic or paper, that does not justify enforcing relying parties to “register” with their government.

This brings in the potential for unreasonable barriers to be imposed, threatening the open and unrestricted use of a citizen’s own data. Such restrictions are not in place for physical credentials and should not be for digital ones.

3.11

The EUDI Wallets would have to be certified by accredited public or private bodies designated by Member States.

This could become onerous, expensive, and time consuming but perhaps unavoidable if different states impose different approaches. A single pan-EU certification body could provide an alternative approach but would likely come with its own challenges.

Care needs to be taken to ensure that certification costs do not prevent innovation by companies large and small.

3.13

For secure cryptographic material storage, specific devices or services may be interfaced with. Other related entities may be service providers such as cloud service providers, app store providers etc.

This opens the door to cloud wallets, where the credentials (and keys) are stored remotely, rather than on the device (“edge wallets”). This will have interesting technical and security implications that will have to be clearly communicated in the detailed toolbox specifications.

4

Diagram of wallet functional components.

It is interesting to see that the PID (Person Identification Data) is seen as separate to other credentials (Electronic Attestations of Attributes). This seems like an additional complexity that is unnecessary, unless the document is just differentiating from the perspective of usage rather than the underlying technology.

It is acknowledged that the PID may be used to bootstrap the acquiring of other qualified and non-qualified credentials, but does that make the PID something technically different? This needs to be clarified in the detailed toolbox specifications. For example, the toolbox could define different “classes” of credentials that can be treated and governed in different ways by the wallet (such as within a Trust Over IP Layer 3 credential governance framework).

4.1

Functional requirements

• Perform electronic identification, store and manage qualified electronic attestation of attributes (QEAA) and electronic attestation of attributes (EAA) locally or remote;
• Request and obtain from attestations from providers, qualified electronic attestation of attributes (QEAA) and electronic attestation of attributes (EAA);
• Provide or access cryptographic functions;
• Mutual authentication between the EUDI Wallet and external entities; Selecting, combining and sharing with relying parties PID, QEAA and EAA;
• User interface supporting user awareness and explicit authorization mechanism; Signing data by means of qualified electronic signature/seal (QES);
• Provisioning of interfaces to external parties.

It is very positive to see mutual authentication specified. This is a very important and often overlooked function that will enable citizens to confidently know that, for example, their bank is their bank and not a scammer.

“Selecting, combining, and sharing with relying parties” is very important. This indicates the specification and implementation of selective disclosure (sharing a subset of attributes from a larger credential) and compound proofs (combining attributes from different credentials into a single proof). These are major privacy and data minimization techniques that we are very pleased to see within this document.

4.1

The EUDI Wallet shall have either only a local storage, or a hybrid storage with at least pointers to a remote storage which are stored locally. 

This brings in the opportunity for several different wallet implementation strategies.

Care needs to be taken to ensure that off-device storage is adequately protected, and access is tightly controlled. The Decentralized Identity Foundation already has defined an architecture for remote storage of data protected by keys that are held and controlled by the holder on their device.

Remote storage introduces a larger attack surface of possibly millions of stored wallets for hackers to compromise, compared with edge storage (on device), where each individual device would need to be hacked individually. The threat vector and economics of hacking change significantly when a remote storage facility contains millions of citizens’ data, versus that data being held at the edge on individual wallet devices.

4.2

The EUDI Wallet shall:

integrate a functionality to request and obtain PID of the user during on-boarding, for example, through an interface with electronic identifications means of assurance level high13;

This indicates as expected that the PID is the anchor data that will allow other qualified credentials to be obtained.

But can other non-qualified credentials be obtained and used even if the holder has not acquired their eIDAS PID?

Users should be able to use their secure and useful EUDI wallet for non-eIDAS purposes without having to “bootstrap” it with an eIDAS PID credential first.

4.2

The EUDI Wallet may:

for use during the electronic identification/authentication process, rely on an interface with authoritative sources, for example official identity documents (e.g. through an access to the NFC interface of mobile phones in order to read identity documents with an NFC chip) or civil registries.

This is good. It opens up the possibility for remote document scanning and NFC passport chip reading to initially establish the PID and provide that input to a QTSP.

This sort of functionality is already in use in digital credential solutions such as IATA’s Travel Pass, which converts the data read by NFC from a passport into a verifiable digital credential.

This will simplify the initial setup of a PID credential.

4.3

Cryptographic functions:

authentication of the EUDI Wallet itself towards third parties;

This states that a relying party should be able to determine that it is talking to a valid and certified EUDI wallet. 

Care will need to be taken to ensure that no unique wallet identifier is used that could act as a perfect correlator for all the actions of a holder.

4.3.2

The EUDI Wallet may rely on a Trusted Execution Environment (TEE) and Secure Elements (SE) locally or a remote equivalent or similar technology depending on the device to execute those computations.

This is further confirmation of the acceptability of remote cryptographic functionality, not just relying on on-device capabilities.

4.4

To ensure that the EUDI Wallet can be used in a seamless way by TSPs and relying parties alike, a common authentication protocol shall be specified, ensuring interoperability at least at EU level and considering relevant European or international standards.

It is very good to see mutual authentication taking such a prominent position in this document.

The use of the EUDI Wallet for multi-factor authentication opens up a whole wealth of opportunities, including use for Secure Customer Authentication in the financial sector.

4.4.1

The EUDI Wallet itself shall be able to prove to the relying party the origin and integrity of the individual EUDI Wallet being used and thereby contributing to an increase in trust and security of the ecosystem. This shall prove that a valid certification has been performed and the solution was installed on a suitable device with adequate security. Revocation checks still have to be done in addition.

The last sentence is very interesting, and it allows a lot of leeway in terms of implementation. It is not clear if this means revocation of the wallet, revocation of credentials in the wallet, or revocation of the certification of the wallet provider.

Because an EUDI wallet will be able to contain non-government credentials, great care must be taken when examining methods of revocation so as not to stop legitimate use of those non-government credentials. It should not be necessary to revoke the content of an entire wallet in order to revoke your driving license for example.

Clarity is needed on this topic.

4.5

The EUDI Wallet shall make it impossible to collect information about the use of the wallet which are not necessary for the provision of the wallet services, nor shall it combine person identification data and any other personal data stored or relating to the use of the European Digital Identity Wallet with personal data from any other services offered by this issuer or from third-party services which are not necessary for the provision of the wallet services, unless the user has expressly requested it.

This is very good to see.

There will need to be a careful definition of “for the provision of wallet services”.

4.5

Selective disclosure and combination of attestations can be handled in two different ways:

1. the EUDI Wallet may hold a very broad collection of attributes as PID, QEAA and EAA, and each time a specific attribute or the derivation of a specific attribute is required, a new PID or (Q)EAA has to be requested from providers.
2. The EUDI Wallet may have the intrinsic capability, based on the obtained PID and (Q)EAA, to selectively disclose, derivate a specific attribute and aggregate several single attributes, without the need for new PID, (Q)EAA or interactions with the PID and (Q)EAA providers. For instance, specific fit for purpose signature schemes in PID and (Q)EAA could enable such capabilities.

There are significant problems with the first option.

Option 1 implies that interactions will require a complex combination of transactions to obtain new data combinations from one or more issuers. In a situation where a proof may contain attributes from multiple issuers, this becomes highly computationally intensive with large latencies. 

It relies on the issuer being reachable in real time at the point of proof generation, which may not be the case. 

It also allows the issuer to have significant power over the holder in that they could refuse to generate the new combination of data, e.g.: if they detect it may be used at a competitor’s organization. 

Additionally, Option 1 will allow the issuer to see that the holder is transacting with a relying party, and the nature of the data requested is likely to give the issuer useful information about what the holder is doing. This breaches the requirements around unlinkability that have already been stated in 4.5.

Option 2 is significantly more preferable from a latency, security, and privacy perspective.

Option 1 should be removed.

4.5.1

The offline sharing scenario corresponds to a use case where the user share a PID, QEAA or EAA or a combination of these to a third party, which is in immediate proximity.

Good explanation of offline sharing.

4.6.1

User awareness component

It is very good to see this description of user interaction, which will have important implications for user experience design. 

Methods for prevention of the faking an “EU Digital Identity Wallet trust mark” need to be clarified.

This section should also detail the mechanisms for selecting a specific attribute when the holder possesses more than one attribute of a certain type that can fulfill a proof request. For example, a date of birth from a driving license and from a passport - what abilities are there for the user to select which to use?

4.6.2

Additionally, the EUDI Wallet shall require the user to use two-factor authentication in a combination of at least two authentication factors for certain use cases, satisfying the requirements for LOA high:

 a proof of knowledge; a proof of possession; a proof of inherence.

Good to see inbuilt multi-factor authentication within the EUDI wallet.

There should be specifications for ensuring tight binding of the holder to the credentials at the time of presentation (proving) for high assurance use cases.

4.8.2

Following Regulation 2019/115725, Member States ID cards contain attested PID in digital format, accessible through a contactless interface. The EUDI Wallet may leverage on this data in its workflows for instance in order to:

Retrieve electronically attested PID;

Help with the identity proofing process;

Strengthen identification or authentication claims.

This provides an elegant way to bridge across from existing eID systems in Member States to the new eIDAS 2.0 functionality without losing the investment already made in those systems.

5

The EUDI Wallet shall ensure full control of the user over their data held within their individual EUDI Wallet by integrating security and privacy by design. Therefore, the core functions of the EUDI Wallet such as identification, authentication, signature, seal and attributes sharing shall not occur without the consent of the user. However, suspension and revocation may not require consent of the user who may be informed.

As per 4.4.1, the final specifications of the EUDI wallet need to be far clearer on the meaning of the terms “revocation” and “suspension” as these have the potential to completely undermine the privacy and security of the EUDI wallet if implemented poorly.

5

The issuer of the EUDI Wallet shall not collect information about the use of the EUDI Wallet, which are not necessary for the provision of the EUDI Wallet services. In addition, the Wallet issuer shall not combine PID and any other personal data stored or relating to the use of the EUDI Wallet with personal data from any other services offered by this issuer or from third-party services, which are not necessary for the provision of the EUDI Wallet services, unless the user has expressly requested it.

The definition of the EUDI wallet as being able to contain credentials from both qualified and non-qualified sources indicates that the definition of “EUDI Wallet services” is extremely broad.

This needs further clarification. The danger is that if PID data is “walled off” from other types of digital credentials, it will degrade the user experience and utility of the wallet without enhancing security or privacy because the wallet already needs to strongly protect ALL credentials and data it manages on behalf of the user.  

Additionally, “issuer” is a term usually used for those who issue credentials. A different term should be used for those who provide wallets, such as “wallet supplier” or “wallet provider” or “wallet publisher”.

6

Form factors

• Form factor 1: Mobile application

• Form factor 2: Web application

• Form factor 3: Secure Application on PC

It is good to see multiple form factors. This is important from an inclusivity perspective. 

Some form factors are missing, such as smart watches that already have wallets for payment cards and other credentials.

Synchronization of data across devices and form factors will be complex and will require tight specification in the toolbox. This includes synchronization of revocation, backup and recovery.