The digital wallet is a done deal. The eIDAS reform came into force in May. By autumn 2026, all EU member states must offer their citizens a so-called „European Digital Identity Wallet“ (EUDI wallet), which they can use to identify themselves online and offline.
According to the EU regulation, the wallet should be voluntary, free of charge, and above all, secure. Users should also be able to transparently determine which data they share with whom. But how can this be implemented technically? And how can a data protection-compliant exchange between citizens, authorities, and companies take place?
An expert group is currently seeking answers to these questions as part of the European Digital Identity Project. They are developing an Architecture and Reference Framework (ARF) in close coordination with the EU Commission. The framework is part of a „toolbox“ that the member states are creating together. The final ARF version defines technical specifications, guidelines, and procedures for the implementation of the eIDAS reform. A few weeks ago, the project published version 1.4 of the ARF.
The updated specifications have met with massive criticism from the civil rights organisation epicenter.works. They accuse the project of ignoring and thus undermining key provisions of the eIDAS Regulation. The framework threatens to undo the achievements in fundamental rights that were painstakingly negotiated in the political process.
Specifically, epicenter.works criticizes new loopholes in data exchange, an eroded right to pseudonymity, and gaps in unobservability and unlinkability.
More data outflow than permitted
The ARF itself states: „This document itself is not legally binding.“ Only the regulations adopted, such as eIDAS and related legal acts, are binding.
The eIDAS reform strictly regulates use cases to protect users‘ data from unauthorised access by others. For example, relying parties should only be able to retrieve the information from the wallets that they are authorised to receive by law.
This includes the user’s contact details or the member country in which they live. In addition, the relying party must be transparent with the user about which data it is retrieving from the wallet and for what purpose. In advance, relying parties must register in the respective EU member states and explain which data they will request from users. This is intended to ensure that users never disclose more data than required by the regulation.
Although the text of the eIDAS Regulation is unambiguous here – epicenter.works refers to Articles 5a and 5b of the Regulation – the ARF does not currently provide any technical specifications that could prevent companies from requesting more data from users than they are allowed to. In fact, the framework would „simply ignores“ the relevant paragraphs, according to epicenter.works. However, if the clear legal requirements are only implemented inadequately, it makes no sense for relying parties to have to register in advance, the NGO criticises.
Pseudonymity eroded
In order to avoid overidentification, the reformed eIDAS Regulation also stipulates that users can always use a pseudonym if they are not obliged to disclose their legal identity. This allows users to confirm an identity with the wallet without disclosing personal information. Identifying themselves with their legal identity is then only necessary to open a bank account, for example.
However, the current ARF stipulates that law enforcement authorities can retroactively trace pseudonyms back to their legal identity. The provisions therefore „strongly contradicts the legal requirements,“ epicenter.works writes.
„The right to pseudonymity protects us from companies like Facebook or Schufa forcing us to reveal our civil identity,“ says Thomas Lohninger from epicenter.works to netzpolitik.org. „However, when implementing this right, a backdoor was built in that allows law enforcement authorities to trace every pseudonym back to a real person.“
Commission removes guidelines on pseudonyms
The exact specifications that the expert group will make here are currently hidden from the public. The Commission has removed the so-called Pseudonym Rule Book from the repository. It contains specific requirements on how pseudonyms are to be used within the EUDI wallet.
In response to an enquiry from netzpolitik.org, the Commission announced that it had agreed with experts from the Member States in the eIDAS Expert Group that the pseudonym rule book should be further developed before publication on GitHub. This process is currently underway.
In order to facilitate a public discussion on the requirements of the ARF, we are publishing the deleted version of the Pseudonym Rule Book in full text.
Experts invent „Pseudonym Provider“
The ARF also deviates seriously from the legal text in other respects by inventing the concept of a pseudonym provider without further ado, as epicenter.works writes. Such an instance is not provided for in the regulation. Instead, pseudonyms are to be created and stored locally on users‘ end devices. Nevertheless, according to ARF, an external entity is now to create pseudonyms for users – which authorities can then resolve to a real name.
However, the ARF „would make the EUDI wallet to a tool for indiscriminate mass surveillance and authoritarian control, incompatible with the Charter of Fundamental Rights and the eIDAS Regulation,“ writes epicenter.works in its analysis. „Every use of the wallet could be monitored by the state,“ fears Thomas Lohninger. „It gives the impression of a cover-up, because we only know about it through a leak. The relevant document ‚Pseudonyms Rule Book‘ was half-heartedly removed from the Commission’s website.“
Any mention of a pseudonym provider must be removed from the rules and regulations, demands epicenter.works. In addition, only locally generated pseudonyms that are stored in encrypted form in the wallet and cannot be linked to the legal identity of a user should be used.
Unobservability does not occur
In order to protect the rights of wallet users, the eIDAS Regulation also provides for the principles of „unobservability“ and „unlinkability“ of data.
Unobservability means that wallet providers are not allowed to view or collect the data stored in the wallets. Only the users should be able to see from the wallet which transactions they have carried out.
However, this requirement is not mentioned anywhere in the ARF, criticizes epicenter.works. The framework also contains „contains no safeguard of any kind to prevent the tracking, linking, correlating or otherwise obtaining knowledge about concrete use behaviour,“ according to the NGO.
Insufficient unlinkability
The second principle of „unlinkability“ states that different identification processes may not be combined. In concrete terms, this means that if a person repeatedly purchases alcohol in the same shop and proves their age using a wallet, for example, the seller may not link the various transactions together in order to track the purchasing behavior of this person over a longer period of time.
From epicenter.works‘ point of view, the ARF has major gaps. The regulation is very clear. The ARF would have to „enable privacy preserving techniques which ensure unlinkability, where the attestation of attributes does not require the identification of the user.“
The ARF does not meet this requirement, criticises epicenter.works. The precautions envisaged by the ARF would „neither unlinkability with respect to Identity Provider and Relying Party, nor across presentation to the same Relying Party.“
An international group of cryptographers made a similar criticism of the ARF a few days ago. They criticised the fact that the current proposal provides for encryption methods that cannot meet the requirements of the eIDAS reform. According to the experts, the problem cannot be solved quickly. Instead, fundamentally different cryptographic solutions are needed to protect users‘ data.
For Thomas Lohninger, the problems now go far beyond technical issues. „Our trust in the entire eIDAS process has been severely shaken by this proposal. The legally enshrined rights of the population have simply been ignored by the Commission and the Member States,“ says Lohninger. „If the technical implementation of the wallet is not drastically improved, we will be forced to take legal action against it before the European Court of Justice and urgently warn the public against the wallet.“
Das „Pseudonym Rule Book“ in Volltext:
Pseudonym Rule Book
for the EUDI Wallet ecosystem
- Author Ni-Scy
- Version: 1.0
- Date: 2023-10-17
- Status: Draft
- Classification: Proprietary
Version history
| Version | Date | Status | Author |
| 0.1 | 2023-05-18 | Draft | Ni-Scy |
| 0.2 | – | Draft – internal | Ni-Scy |
| 0.3 | – | Draft – internal | Ni-Scy |
| 0.4 | 2023-07-21 | Draft – internal | Ni-Scy |
| 0.5 | 2023-07-28 | Draft – internal | Ni-Scy |
| 0.6 | 2023-07-30 | Draft – internal | Ni-Scy |
| 0.7 | 2023-07-31 | Draft – internal | Ni-Scy |
| 0.8 | 2023-07-31 | Draft – internal | Ni-Scy |
| 0.9 | 2023-07-31 | Draft – internal | Ni-Scy |
| 0.10 | 2023-08-01 | Draft for 1st review by eIDAS expert group | Ni-Scy |
| 0.11 | 2023-09-04 | Draft – internal review | Ni-Scy |
| 0.12 | 2023-09-12 | Draft for review by EC | Ni-Scy |
| 0.13 | 2023-09-13 | Final draft for 2nd review by eIDAS expert group | Ni-Scy |
| 1.0 | 2023-10-17 | Final | Ni-Scy |
Change history
| Version | Date | Changes |
| 0.1 | 2023-05-18 | First version for internal NI-Scy review |
| 0.2 | – | Draft – internal |
| 0.3 | – | Draft – internal |
| 0.4 | 2023-07-21 | Draft – internal |
| 0.5 | 2023-07-28 | Draft – internal |
| 0.6 | 2023-07-30 | Draft – internal |
| 0.7 | 2023-07-31 | Draft – internal |
| 0.8 | 2023-07-31 | Draft – internal |
| 0.9 | 2023-07-31 | Draft – internal |
| 0.10 | 2023-08-01 | Final resolution of internal comments |
| 0.11 | 2023-09-04 | Reworked draft after review by eIDAS Experts and scope clarification by EC |
| 0.12 | 2023-09-12 | Minor changes, additions and clarifications after internal reviews |
| 0.13 | 2023-09-13 | Clarifications and changes after EC review. |
| 1.0 | 2023-10-17 | Changes after review by eIDAS Experts |
Table of Contents
1 INTRODUCTION
1.1 Context and scope
1.2 Document structure
1.3 Key words
1.4 Terminology
2 USE CASES, REQUIREMENTS, AND IMPLEMENTATION
2.1 Use cases
2.2 Requirements
2.2.1 Requirements for a User pseudonym
2.2.2 Requirements for a User alias
2.3 Pseudonymization method
2.4 Limitations
2.5 Risks
3 PSEUDONYM ATTRIBUTE SCHEMA
3.1 Pseudonym attestations and Pseudonym Issuers
3.2 Document type and namespace
3.2.1 EU-wide document type and namespace for pseudonyms
3.2.2 Domestic pseudonym namespaces
3.3 Pseudonym attributes
3.3.1 Introduction and overview
3.3.2 Attribute user_pseudonym
3.3.3 Attribute user_alias
3.4 Attribute encodings
3.4.1 Introduction
3.4.2 ISO/IEC 18013-5-compliant encoding
3.4.2.1 Encoding rules
3.4.3 SD-JWT-compliant encoding
3.4.3.1 Encoding rules
4 TRUST INFRASTRUCTURE DETAILS
4.1 Introduction
4.2 ISO/IEC 18013-5-compliant Pseudonym attestations
4.2.1 OIDs for use in Pseudonym-related certificates
4.2.2 Trusted Issuer List
4.3 SD-JWT-compliant Pseudonym attestations
5 REFERENCES
1 Introduction
1.1 Context and scope
This document is the Pseudonym Rule Book for the EUDI Wallet ecosystem. It contains requirements specific to the Pseudonym attestations within the EUDI Wallet. These requirements are additional to the requirements in the Architecture Reference Framework (ARF), see [ARF]. Requirements in the ARF hold for all attestations in the EUDI Wallet.
This document specifies a single type of pseudonym, which will be issued by a Pseudonym Issuer to a User having a Wallet Instance. In principle, there are many different parties that are able to provide a pseudonym to a citizen; for example, a Relying Party may be able to do so, or a Wallet Instance might. However, the added value (to Users and Relying Parties) of using a pseudonym attestation as defined in this document is that the Issuer must verify the identity of the User during the issuance process of the pseudonyms. See section 3.1 for the requirements on pseudonym attestations and Pseudonym Issuers.
There are many different use cases for which a Relying Party may use a pseudonym. As a consequence, there are many functional and security requirements that a pseudonym (or the pseudonymization method) may have to comply with in order to fulfill these use cases. The pseudonymization method defined in this document is not designed to fit all possible use cases and to comply with all possible requirements. Rather, it is intended to support a basic use case, namely allowing a Relying Party to recognize a User as someone about whom the Relying Party already knows something, or with whom the Relying Party has interacted before. Chapter 2 discusses this use case in more detail and describes the requirements the pseudonym defined in this document complies with. Member States (or other attestation Issuers) MAY specify and implement additional pseudonyms and pseudonymization methods, possibly with different characteristics, and add these to their domestic pseudonym namespace; see section 3.2.2. The requirements in this document do not apply to such domestic pseudonyms.
Member States SHALL ensure that all Users of a valid Wallet Instance, if they so desire, are able to receive a pseudonym attestation as defined in this document and are able to release their pseudonym values to Relying Parties.
1.2 Document structure
This Pseudonym Rule Book contains the following topics:
- Chapter 2 describes possible use cases for pseudonyms, as well as the requirements for the pseudonymization method specified in this document.
- Chapter 3 specifies the pseudonym attribute schema:
- Explanations and requirements for pseudonym attestations and Pseudonym
Issuers o Document type and namespace for the EU-wide pseudonyms discussed in this document.
- Two pseudonym attributes and encodings, one compliant with [ISO18013-5], the other compliant with [SD-JWT].
- Chapter 4 specifies some details on the trust infrastructures needed for issuing and verifying pseudonym attestations.
Further topics will be added to this Rulebook if and when they are identified.
1.3 Key words
This document uses the capitalized key words ‘SHALL’, ‘SHOULD’ and ‘MAY’ as specified in RFC 2119, i.e., to indicate requirements, recommendations and options specified in this document.
In addition, ‘must’ (non-capitalized) is used to indicate an external constraint, i.e., a requirement that is not mandated by this document, but, for instance, by an external document such as [ARF]. The word ‘can’ indicates a capability, whereas other words, such as ‘will’, and ‘is’ or ‘are’, are intended as statements of fact.
1.4 Terminology
This document uses the terminology specified in [ARF]. In addition, this document specifies the following terms:
| Term | Meaning |
| Anonymous authentication | A process verifying that the User uses a valid Wallet Instance, without learning anything else about the User |
| Attestation | Attestation in electronic form that allows the authentication of attributes. [eIDAS 2.0] |
| Identification | The process of recognizing an entity in a particular domain as distinct from other entities. In the context of this document, the entity is a User. [Adapted from ISO/IEC 24760-1, clause 3.2.1, to use terminology established within the EUDI Wallet ecosystem] |
| Identity | A set of attributes related to an entity. In the context of this document, the entity is a User [ISO/IEC 24760-1, clause 3.1.2] |
| Identifier | An attribute or set of attributes that uniquely characterizes an identity in a domain ISO/IEC 24760-1, clause 3.1.4] |
| Pseudonym | An identifier for a User that contains the minimal identity information sufficient to allow a Relying Party to use it for recognizing a User. A pseudonym can be used to reduce privacy risks that are associated with the use of identifiers with fixed or known values.
[Adapted from ISO/IEC 24760-1, clause 3.6.3, to use terminology established within the EUDI Wallet ecosystem] |
2 Use cases, requirements, and implementation
2.1 Use cases
Pseudonyms can be used in many different use cases. Generally speaking, most of these use cases come down to a form of User recognition. Recognition in this context means matching an identifier for a User with (or linking it to) an existing record, possibly resulting from a previous interaction. If User recognition succeeds, the record is supposed to belong to the User presenting the identifier.
A pseudonym is an identifier for a User, the value of which does not say anything about the real-world characteristics of the User. This is what makes it different from identifiers such as name, date of birth, nationality or gender, which obviously do contain information about the real world. A pseudonym is a meaningless value, the only purpose of which is that a Relying Party may look it up in a database[i].
Another important aspect of a pseudonym is that it is usable for User recognition in a limited domain only. In the context of this document, the value of a pseudonym is different for every Relying Party that receives it. Moreover, the pseudonym values obtained by two different Relying Parties for the same User cannot be linked. This implies that the pseudonym value can be used only at the Relying Party that received it. This is what makes a pseudonym different from the unique persistent identifier in the PID of a Wallet Instance. The value of that identifier is independent from any Relying Party, and thus it can be used for User recognition by all Relying Parties (and other parties) that know its value.
Since the value of the pseudonym defined in this document is different for every Relying Party, the Wallet Instance SHALL identify and authenticate the Relying Party that requests the pseudonym. Relying Party authentication is specified in [RPAuth].
2.2 Requirements
2.2.1 Requirements for a User pseudonym
The pseudonymization method specified in this document SHALL comply with the following requirements:
- During the issuance process of the pseudonyms, the Pseudonym Issuer SHALL identify the User using an identity means on Level of Assurance High, as specified in the
Commission Implementing Regulation (EU) 2015/1502, [2015/1502].[ii]
- Rationale: As explained in section 1.1 already, this is in fact its main added value compared to pseudonyms issued by other parties, either within the EUDI Wallet ecosystem or outside it.
- A Relying Party SHALL NOT be able to derive the User’s true identity, or any data identifying the User, from the pseudonym value received by the Relying Party.
- Rationale: This is what makes a pseudonym a pseudonym, as opposed to an identifier.
- The Wallet Instance SHALL always release the same value for the pseudonym of a given User to a given Relying Party, unless the User chooses to have multiple pseudonyms for the same Relying Party[iii], or chooses to deactivate a pseudonym[iv]. In other words, the pseudonym value SHALL NOT change from presentation to presentation without User intervention[v],[vi].
- Rationale: This is essential for allowing the Relying Party to use the pseudonym for User recognition.
- The Pseudonym Issuer SHALL ensure that pseudonyms contain sufficient entropy to make the chance of colliding pseudonyms (meaning two Users having the same pseudonym value for the same Relying Party) is negligible, even between pseudonyms issued by different Pseudonym Issuers.
- Rationale: If pseudonym collision could occur in practice, User recognition by the Relying Party would fail, because the wrong User would be matched to an existing record.
- The Wallet Instance SHALL allow the User to use multiple pseudonym values at a given Relying Party. In other words, if desired by the User7, the Wallet Instance SHALL give the User the choice to release one of the existing pseudonym values already associated with this RP, or to release a ‘unused’ pseudonym value.
- Rationale: A User may want to have multiple pseudonymous accounts with the same Relying Party, for example a business account and a personal one.
- The Wallet Instance SHALL allow the User to deactivate the pseudonym value for a given Relying Party. After the User has deactivated a pseudonym value, the Wallet
Instance SHALL NOT release that pseudonym value to any Relying Party anymore.
The Relying Party SHALL NOT be informed about this change.
- Rationale: The User has the right to be forgotten.
- The Wallet Instance SHALL always release a different value for the pseudonym of a given User to different Relying Parties[vii].
- Rationale: This is important to ensure that colluding Relying Parties cannot use the pseudonym values to track the User.
- It SHALL NOT be possible to correlate pseudonym values based on their value [viii], meaning that colluding Relying Parties are not able to conclude that pseudonyms released by a User to different Relying Parties belong to the same User.
- Rationale: If this was possible, it would defeat the purpose of using different pseudonym values and would allow colluding Relying Parties to track the User.
- The Pseudonym Issuer SHALL be able to issue a pseudonym value to the Wallet Instance of a User without knowing the identity of the Relying Party to which the Wallet Instance will release that value.
- Rationale: This simplifies the issuing process significantly, as otherwise either
- each new pseudonym would need be issued just-in-time; at the moment the User uses their Wallet Instance for the first time at a specific Relying Party. The Wallet Instance would need to communicate the Relying Party identifier to the Pseudonym Issuer, who would use it to calculate the new pseudonym value. Such a process would probably lead to longer transaction times and is not usable if the Wallet Instance is offline.
- or, alternatively, the Pseudonym Issuer would need to issue a pseudonym to the User for a Relying Party without knowing if the User will interact with that Relying Party. This may be possible in some cases, but not generally. It may also lead to the issuance of many pseudonyms that will never be used.
- Rationale: This simplifies the issuing process significantly, as otherwise either
- The pseudonymization method SHALL be openly specified, including the input data it takes and the cryptographic derivation functions used.
- Rationale: This allows any interested party, including academia, to analyze the pseudonymization method and find vulnerabilities in it. If vulnerabilities are found, they can be fixed. If they are not found, trust in the pseudonymization method will be reinforced.
This document does not specify a mechanism for associating a pseudonym to a Relying Party. It is up to each Wallet Provider to define such a mechanism, as long as the requirements above are complied with.
2.2.2 Requirements for a User alias
In addition to the core requirements for pseudonyms specified in the previous section, this section specifies a number of requirements for a User alias.
- A Wallet Instance SHALL enable the User to freely choose a User alias for each pseudonym released to a Relying Party. An alias SHALL be a text string. Setting an alias SHALL be optional for the User. The User SHALL be able to change the alias for any pseudonym.
- Rationale: Setting an alias helps the User to recognize and distinguish pseudonym values, which otherwise are meaningless sequences of symbols. Also, a Relying Party can use the alias to, for instance, address the User.
- The Wallet Instance SHALL associate each pseudonym to at most one alias, but the User SHALL be able to use the same alias for multiple pseudonyms.
- Rationale: Allowing multiple aliases for the same pseudonym seems unnecessary and confusing. It also begs the question how a Relying Party should request multiple aliases.
- A Relying Party SHALL NOT use an alias for recognizing the User. o Rationale: Since it is freely chosen by the User, the alias is not guaranteed to have any of the properties that are required for the pseudonym in section 2.2.1.
- The Wallet Instance SHALL NOT release an alias without the corresponding pseudonym value.
- Since the alias is not usable as a pseudonym, it is useless on its own.
This document does not specify a mechanism for associating a pseudonym to an alias. It is up to each Wallet Provider to define such a mechanism, as long as the requirements above are complied with.
2.3 Pseudonymization method
User pseudonyms as defined in this document SHALL be issued by a Pseudonym Issuer, as opposed to the Wallet Instance. This is a consequence of the requirement that the (true) identity of the User is verified before the pseudonyms are issued, using an identity means on Level of Assurance High. A Wallet Instance cannot do that. Another reason to not allow a Wallet Instance to generate pseudonyms and sign pseudonym attestations is that currently it is difficult to assess whether a Wallet Instance is secure enough to do this. Within the scope of this document, the relevant security property would primarily involve the (pseudo) random number generator available to the Wallet Instance, as the UUID specified in this document is randomly generated, and not derived from an underlying secret. Random number generation is hard, especially in constricted devices. Whether or not a Wallet Instance can securely do this, may depend on the chosen security architecture. It seems better to leave pseudonym generation and signing to an Issuer, who do this securely regardless of the properties of the Wallet Instance and the mobile device.
User pseudonyms as defined in this document SHALL be pseudo-randomly generated UUIDs as defined in RFC 4122, [RFC4122]. Pseudonym Issuers SHALL set the variant of each UUID to ‘10x’b, as specified in section 4.1.1 of [RFC4122], and SHALL set the version to 4, as specified in section 4.1.3. Pseudonym Issuers SHALL ensure the quality of the pseudorandom numbers generated for use in the pseudonyms by using a Cryptographically Secure PseudoRandom Number Generator (CSPRNG)[ix].
Pseudonym Issuers SHALL issue one or more pseudonym attestations (see section 3.1) to a
Wallet Instance upon request, using an issuance interface as defined in [Issuance]. Once a Wallet Instance contains a pseudonym attestation, the Wallet Instance SHALL always be able to release a new pseudonym to a Relying Party. To that end, unless technically infeasible[x], the Wallet Instance and the Pseudonym Issuer SHALL ensure that the Wallet Instance always contains at least one unused pseudonym value. The Wallet Instance and the Pseudonym Issuer SHALL follow the applicable requirements for attestation management. A Wallet Instance SHALL NOT restrict the total number of different pseudonym values it supports, apart from any technical limitations.
A Wallet Instance SHALL release each pseudonym value to at most one Relying Party. A Wallet Instance SHALL ensure that a recurring Relying Party always receives the same pseudonym value, unless the User decides to use a new pseudonym value, either as an additional value or in replacement of the existing value. To be able to do so, the Wallet Instance SHALL authenticate the Relying Party as described in [RPAuth].
A Wallet Instance SHALL show all pseudonym values it contains to the User upon request, together with their association with a Relying Party, if such an association exists. A Wallet Instance SHALL allow the User to deactivate a pseudonym value. Afterwards, if the Relying Party with which that pseudonym was associated again requests a pseudonym, the Wallet Instance SHALL release a new, unused pseudonym value.
2.4 Limitations
Below is a non-exhaustive list of limitations of the pseudonymization method specified in this document. This list is presented here only for information purposes:
- The pseudonym for a given User at a given Relying Party is not persistent between different Wallet Instances belonging to the User. For example, if the User has two different Wallet Instances, a given Relying Party will receive a different pseudonym value from each of these. Similarly, if the User loses a Wallet Instance and sets up a new one, the pseudonym value for a given Relying Party in the new Wallet Instance will be different. This implies that the User will not be able to access their account, unless they have set up an account recovery mechanism outside the scope of this document. This is true unless the Wallet Provider has a method for synchronizing or backing up and restoring the contents of Wallet Instances, including the association between a particular pseudonym value and a particular Relying Party, which is kept by the Wallet Instance. Backup and restore possibilities will be discussed in Epic 33. If technically possible, any mechanism for backing up and restoring Wallet Instance contents SHALL include the associations between pseudonyms values and Relying Parties.
- There is no guarantee that each User has only one pseudonym value for a given Relying Party.
- The pseudonym cannot be used for anonymous authentication. An anonymous authentication solution allows a Relying Party to verify that the User uses a valid Wallet Instance, without learning anything else about the User. In the case of the pseudonym defined in this document, the Relying Party learns the value of the pseudonym for this particular User at this particular Relying Party. Although the usefulness of that pseudonym is limited to that Relying Party only, the User cannot be said to be truly anonymous.
These limitations may be resolved in the future by introducing a cryptographically more advanced pseudonymization method.
2.5 Risks
After a pseudonym value is issued to a Wallet Instance of a User, the Pseudonym Issuer could keep a record of the pseudonym value and the associated User. This may be needed, for example, in case the Pseudonym Issuer wants to be able to re-issue the pseudonym value to the same User, for instance if the User’s device is lost, stolen or replaced. If the Pseudonym Issuer does not support re-issuance, the User will lose access to the account(s) represented by the pseudonym value.
However, keeping the issued pseudonym values implies that the Pseudonym Issuer is able to look up the User’s true identity (for example, the unique persistent identifier in the PID) from the pseudonym value received by a Relying Party. The Issuer would be able to derive the User’s true identity from a pseudonym that a Relying sends to the Issuer. This is a privacy risk for the User.
On the other hand, this ability may be seen as a feature as well, rather than as only a risk. It may be needed, for example, in case a Relying Party provides a service to a User based on the User’s pseudonym, and a legal conflict arises between the User and the Relying Party. The
Relying Party could then ask the Pseudonym Issuer to reveal the User’s true identity. Another circumstance in which this ability may be needed is when a law enforcement agency requests the true identity of the User that was involved in a transaction with the Relying Party.
Lastly, another reason to keep a record of issued pseudonym values may be a legal requirement in European Union or national law to retain such information.
With regard to this risk, this document specifies the following:
A Pseudonym Issuer SHOULD develop a policy regarding whether it keeps a record of pseudonym values issued to Users, considering at least the abovementioned advantages and (privacy) risks. In any case, the Pseudonym Issuer SHALL NOT keep the pseudonym values for longer than allowed by the relevant laws and SHALL NOT use them for any purpose different from what these laws impose.
3 Pseudonym attribute schema
3.1 Pseudonym attestations and Pseudonym Issuers
A pseudonym attestation as specified in this document SHALL be an Electronic Attestation of Attributes (EAA), as defined in the eIDAS v2 Regulation. A Pseudonym Issuer SHALL comply with all requirements for a PID Provider or a QTSP issuing QEAAs.
Requirements 7, 8 and 10 in section 6.3.1 of [ARF] specify that EAAs (such as pseudonym attestations) must be issued in accordance with either ISO/IEC 18013-5:2021 [ISO18013-5] or with [SD-JWT], and that consequently, data elements must be encoded in CBOR or JSON. In other words, a pseudonym attestation SHALL either be in the mdoc format specified in [ISO18013-5] or in the SD-JWT format specified in [SD-JWT] and [SD-JWT-VC]. This implies that a pseudonym attestation has largely the same properties as any other type of attestation within the EUDI Wallet ecosystem. For example,
- the authenticity and integrity of the attributes in the attestation is protected via a signature of the Issuer (or, in case of the alias attribute, the mobile device).
- pseudonym attestations are bound to the device on which they reside via a public key in the attestation (proof of possession, key binding).
- individual attributes in the attestation are selectively disclosable.
- a Wallet Instance must request user consent before releasing a pseudonym attribute, see [RPAuth].
- the Issuer can revoke pseudonym attestations using one of the methods specified in [AttestRevoc].
However, pseudonym attestations are different from other types of attestations in one respect: every Relying Party that requests the user_pseudonym attribute (see section 3.3.1) will receives a different value. At the same time, a recurring Relying Party will always receive the same value for the user_pseudonym attribute.
To allow these properties, there are two ways in which a Pseudonym Issuer can issue pseudonyms:
- First, the Pseudonym Issuer can issue each pseudonym value as a different attestation, including its own MSO or SD-JWT. This implies that the Wallet Instance must manage a different private key for each pseudonym value[xi]. When a Relying Party requests a pseudonym for the first time, the Wallet Instance releases an ‘unused’ attestation. Each subsequent time that same Relying Party requests a pseudonym, the Wallet Instance releases the same attestation. However, different Relying Parties will receive a different attestation, including a different MSO or SD-JWT. Thus, the Wallet Instance treats pseudonym attestations in a different manner than other types of attestations, which (in principle) can be issued multiple times to multiple Relying Parties[xii].
- Secondly, the Pseudonym Issuer can issue a single pseudonym attestation containing multiple pseudonym values. These different pseudonym values will be included in the attestation in the same way as different attributes are in other attestations (for example the attributes in the PID): the MSO or SD-JWT will contain a digest for each pseudonym value, and the collection of digests is signed by the Pseudonym Issuer. This ensures that each pseudonym value can be disclosed selectively. An advantage of this method is that it limits the number of attestation private keys to be managed by the Wallet Instance.
When a Relying Party requests a pseudonym for the first time, the Wallet Instance releases the pseudonym attestation, but discloses only one ‘unused’ pseudonym value, which it will subsequently always use for the same Relying Party. A different Relying Party will receive the same attestation, but with a different pseudonym value being selectively disclosed. Thus, like other types of attestations, a pseudonym attestation MSO or SD-JWT can (in principle) be released to multiple Relying Parties. This implies that there is a risk that the signature value or digest values in the MSO or SD-JWT will be used to track the User. The Wallet Instance and the Pseudonym Issuer must counter this risk by limiting the number of times a pseudonym attestation can be released to a Relying Party; see the discussion in section 3.3.4 of [AttestRevoc].
3.2 Document type and namespace
3.2.1 EU-wide document type and namespace for pseudonyms
Pseudonym Issuers SHALL use the document type “eu.europa.ec.eudiw.pseudonym.1” for Pseudonym attestations. The version number “1” in this document type MAY be used to distinguish between the first version of the pseudonym attestation (defined in this document) and any future version. Similarly, Pseudonym Issuers SHALL use the value
“eu.europa.ec.eudiw.pseudonym.1” for the namespace of the first version of the Pseudonym attributes specified in section 3.3.
3.2.2 Domestic pseudonym namespaces
As explained in section 1.1, Pseudonym Issuers (Member States) are free to specify additional pseudonyms and pseudonymization methods, for instance if they want to use a pseudonym having specific properties that are not supported by the pseudonymization method specified in this document.
To allow Relying Parties to request such a domestic pseudonym, the Pseudonym Issuer SHALL specify attribute identifiers within their domestic pseudonym namespace. If a Pseudonym Issuer chooses to define a domestic namespace for pseudonyms, it SHALL append the applicable ISO 3166-1 alpha-2 country code or the ISO 3166-2 region code, separated by a period, to the EUwide pseudonym namespace defined in the previous section, excluding the version number. The Pseudonym Issuer MAY include a version number in the domestic namespace.
EXAMPLE: The first version of the domestic pseudonym namespace for Denmark could be “eu.europa.ec.eudi.pseudonym.dk.1”.
for such attestations. Nevertheless, a Pseudonym Issuer MAY still choose to follow one of the approaches described in that section, for example to be able to treat all types of attestations it issues in the same manner.
3.3 Pseudonym attributes
3.3.1 Introduction and overview
To be able to comply with the requirements in section 2.2, Table 1 specifies two different attributes for the Pseudonym attestation. Table 1 contain the following information:
- The first column specifies the identifiers of the attributes. These identifiers SHALL be used in requests and responses according to [ISO18013-5] or [OpenID4VP], as applicable. There SHALL be at most one data element with the same attribute identifier in each pseudonym attestation.
- The second column describes the meaning of the data element.
- The third column specifies whether the presence of the element in a Pseudonym attestation is mandatory (M), or optional (O).
NOTE: If Table 1 indicates a data element as mandatory, this solely means that the Pseudonym Issuer SHALL ensure that this element is present in the pseudonym attestations.
- The fourth column indicates how the data elements SHALL be encoded, using the CDDL representation types defined in [RFC 8610]. Section 3.4 specifies how these representation types SHALL be serialized into CBOR and JSON data structures, respectively. Note that tstr and bstr are CDDL representation types defined in [RFC 8610]. All data elements having encoding format tstr SHALL have a maximum length of 150 characters.
| Attribute identifier | Definition | Presence | Encoding format |
| user_pseudonym | A pseudonym for the User, as defined in section 2.3 of this document. Its value is a 16-byte UUID. | M | bstr |
| user_alias | An alias for the User chosen by the User, as defined in section 2.2.2 of this document. | O | tstr |
Table 1 Pseudonym attributes
3.3.2 Attribute user_pseudonym
The attribute user_pseudonym SHALL be a pseudonym, complying with the requirements in section 2.2.1 and generated as specified in section 2.3 of this document.
This attribute SHALL be signed by the Pseudonym Issuer. For ISO/IEC 18013-5-compliant Wallet Instances, this implies that the Wallet Instance SHALL release this data element as an IssuerSigned Item. For OpenID4VP-compliant Wallet Instances, this implies that the Wallet Instance SHALL release this data element in a VP Token.
3.3.3 Attribute user_alias
The attribute user_alias SHALL be freely chosen by the User, using functionality offered by the Wallet Instance. Consequently, this attribute SHALL be signed by the Wallet Instance, using the private key corresponding to the public key in the MSO or SD-JWT of the Pseudonym attestation. Please note the following:
- As specified in [TrustModel] section 4.2.1, this attribute is (currently) the only one that is signed by the Wallet Instance rather than the Issuer.
- For ISO/IEC 18013-5-compliant Wallet Instances, this implies that the Wallet Instance SHALL release this attribute as a Device-Signed Item. For OpenID4VP-compliant Wallet Instances, this implies that the Wallet Instance SHALL release this attribute in an ID Token.
- For ISO/IEC 18013-5-compliant Wallet Instances, the Pseudonym Issuer SHALL authorize the public key in the MSO to sign this attribute.
- The Wallet Instance SHALL sign this attribute using the attestation private key that is also used for mdoc authentication (ISO/IEC 18013-5) or Key Binding (SD-JWT). This ensures that no additional keys and certificates must be used by the Wallet, which means that there is no additional risk of colluding Relying Parties using these to conclude that the aliases belong to the same User.
3.4 Attribute encodings
3.4.1 Introduction
This section specifies two separate encodings for the pseudonym attribute schema, an ISO/IEC 18013-5-compliant encoding in CBOR, and a SD-JWT-compliant encoding in JSON.
3.4.2 ISO/IEC 18013-5-compliant encoding
3.4.2.1 Encoding rules
If data elements specified in in Table 1 are encoded with CBOR, they SHALL be encoded as specified in [RFC 8949].
The CDDL representation types used in Table 1 are specified in section 3.3.1. Rules to encode CDDL representation types with CBOR are specified [RFC 8610] and [RFC 8949].
3.4.3 SD-JWT-compliant encoding
3.4.3.1 Encoding rules
If data elements are encoded with JSON, they SHALL be encoded as specified in [RFC 8259].
The CDDL representation types used in Table 1 are specified in section 3.3.1. Rules to encode CDDL representation types with JSON are specified in [RFC 8949] section 6.1 Given the CDDL representation types used in the current version of this document, the following rules are relevant:
- A CDDL bstr (i.e., a byte string) is encoded in base64url without padding and becomes a JSON string.
- A CDDL tstr (i.e., a UTF-8 text string) becomes a JSON string[xiii].
4 Trust infrastructure details
4.1 Introduction
To trust the signature over a pseudonym attestation, the Relying Party needs a mechanism to validate that the public key it uses to verify that signature is trusted. Both ISO/IEC 18013-5 and OpenID4VP provide such mechanisms. However, in both cases, additional details need to be specified to fully specify these mechanisms for pseudonym attestations within the EUDI Wallet ecosystem.
4.2 ISO/IEC 18013-5-compliant Pseudonym attestations
4.2.1 OIDs for use in Pseudonym-related certificates
ISO/IEC 18013-5 specifies an X.509-based PKI for the purpose of trusting public keys. This PKI has multiple roots; there is an independent (self-signed) root certificate for every issuer. Annex B of the standard specifies the formats of the X.509 certificates for all participants in the ecosystem.
These certificate formats are mDL-specific, but only because they use some mDL-specific Object Identifiers (OIDs), see Annex B.1.1 of ISO/IEC 18013-5. All other aspects of these certificate profiles can be used for any type of attestation complying with the security mechanisms defined in ISO/IEC 18013-5, including a Pseudonym attestation within the EUDI Wallet ecosystem.
To make the certificate profiles applicable for Pseudonym attestations in ISO/IEC 18013-5compliant EUDI Wallets, a number of pseudonym-specific OIDs have to be defined.
There are ongoing discussions on the OID values specified in [PIDRulebook]. Specification of the necessary pseudonym specific OIDs is postponed until after these discussions have been resolved.
These OIDs SHALL be used in certificates used for pseudonym attributes within the ISOcompliant EUDI Wallet ecosystem, in exactly the same way as the corresponding OIDs specified in ISO/IEC 18103-5 are used within the mobile driving license ecosystem. These new OIDs will have to be officially registered.
4.2.2 Trusted Issuer List
Section 4.2.2. of [TrustModel] describes the concept of a trusted list of Issuers. This document specifies that for pseudonym attestations, such a trusted list SHALL be used. Relying Parties SHALL only trust Pseudonym Issuers that are included in a trusted list of Pseudonym Issuers. Additionally, there SHALL be only a single trusted list (or list-of-lists) of Pseudonym Issuers, which SHALL be generated and maintained by a yet-to-be-determined party. This list SHALL also contain the (root) certificate(s) of each Pseudonym Issuer. The same list MAY be used for PID Providers and other types of (Q)EAA Issuers as well.
Regarding the format of this trusted list, the format specified in ETSI TS 119 612 v2.1.1 SHALL be used.
4.3 SD-JWT-compliant Pseudonym attestations
Details on the trust infrastructure for SD-JWT and OpenID4VP-compliant Pseudonym attestations will be detailed in a future version of ARF.
5 References
| [ARF] | The Common Union Toolbox for a Coordinated Approach Towards a European Digital Identity Framework – The European Digital Identity Wallet Architecture and Reference Framework, June 2023, Version 1.2.0 |
| [ISO18013-5] | ISO/IEC 18013-5, Personal identification — ISO-compliant driving licence –
Part 5: Mobile driving licence (mDL) application, First edition, 2021-09 |
| [SD-JWT] | Selective Disclosure for JWTs (SD-JWT) draft-ietf-oauth-selective-disclosure-jwt-04,
D. Fett et al., 11 April 2023 [xiv] |
| [OpenID4VP] | OpenID for Verifiable Presentations – draft 18, 21 April 2023 16
Retrievable from https://openid.net/specs/openid–4–verifiable–presentations1_0.html |
| [TrustModel] | Trust Model for the EUDI Wallet Ecosystem – generic for all use cases, version 0.9, 2023-07-13 |
| [AttestRevoc] | Attestation revocation in the EUDI Wallet ecosystem – For PID and mDL use cases, version 0.91, NI-Scy, 2023-08-02 |
| [RPAuth] | Relying Party authentication & authorization and User consent in the EUDI
Wallet ecosystem – For PID and mDL use cases, version 0.9.8, NI-Scy, 2023-08-22 |
| [PIDRulebook] | Annex 6 to [ARF]
PID Rule Book for the EUDI Wallet ecosystem v1.0.0. |
| [Issuance] | Epic 23: User requesting for a digital identity, Epic 10: Issuing a (Q)EAA to the EUDI Wallet – Generic for all use cases, NI-Scy, version 0.5.2 (draft), 2023-08-14 |
| [ISO24760-1] | ISO/IEC 24760, IT Security and Privacy – A framework for identity management – Part 1: Terminology and concepts, Second edition, 2019-05 |
| [RFC4122] | RFC 4122 – A Universally Unique IDentifier (UUID) URN Namespace, P.
Leach et al., July 2005 |
| [2015/1502] | COMMISSION IMPLEMENTING REGULATION (EU) 2015/1502 of 8 September 2015 on setting out minimum technical specifications and procedures for assurance levels for electronic identification means pursuant to Article 8(3) of Regulation (EU) No 910/2014 of the European Parliament and of the Council on electronic identification and trust services for electronic transactions in the internal market |
[i] If User recognition succeeds, the Relying Party may obtain meaningful data about the User – for example the last time the User interacted with the Relying Party and what happened during that interaction. But the value of the pseudonym itself does not give the Relying Party any information about the User. Moreover, any meaningful data obtained this way by definition was already present in the Relying Party’s records.
[ii] Note that this requirement implies that the Pseudonym Issuer knows the User’s true identity. However, Relying Parties do not know this identity.
[iii] See requirement 5.
[iv] See also requirement 6.
[v] Note that the pseudonym defined in this document does not comply with this requirement for different Wallet Instances belonging to the same User, either in parallel or consecutively, unless the Wallet Provider provides a synchronization or backup mechanism for data in the Wallet Instance. See section 2.4.
[vi] These requirements are security requirements. The implementation of these requirements by Wallet Instances SHALL be in scope of Wallet Solution certification.. 7 This MAY be a configuration setting of the Wallet Instance.
[vii] This requirement is a security requirement. The implementation of this requirement by Wallet Instances SHALL be in scope of Wallet Solution certification..
[viii] Colluding Relying Parties may try to correlate pseudonyms based on observed characteristics of the User, rather than on pseudonym value. Examples include time, location and frequency of use, or estimated age, height and gender of the User. Such attempts have no relationship to the pseudonym values themselves and are not meant in this requirement.
[ix] Note that this requirement ensures that requirement 4 in section 2.2.1 is complied with. A pseudorandom UUID according to RFC 4122 contains 122 random bits. According to https://en.wikipedia.org/wiki/Universally_unique_identifier#Collisions, 2.7 x 10^18 random UUIDs must be generated to have a chance of 50% of at least one duplicate UUID to be generated. Since there are 448 million EU citizens, this corresponds to roughly 6.0×10^9 UUIDs per EU citizen. Assuming the number of pseudonyms per citizen will not exceed 100, this means a security margin of 6×10^7. This security margin is good enough, especially given the fact that for any practical problem to arise, the two colliding pseudonym values must be known by the same Relying Party. Another illustrative way to look at this is that, in order to generate 2.7 x 10^18 UUIDs, 1 billion UUIDs must be generated per second for about 86 years.
[x] For instance, because the last unused pseudonym value is used in a transaction during which the Wallet Instance is offline. In such cases, new pseudonym values SHALL be issued to the Wallet Instance as soon as the Wallet Instance is able to connect to the Pseudonym Issuer again.
[xi] Note that section 2.3 requires that a Wallet Instance is able to manage at least 100 pseudonym values, so the number of private keys to manage can become considerable.
[xii] Because the MSO or SD-JWT of each pseudonym attestation is released to one Relying Party only, there is no risk that the signature value or digest values in the MSO / SD-JWT will be used to track the User. Consequently, there is no need to limit the number of times a pseudonym attestation can be released to a Relying Party, and the discussion in section 3.3.4 of [AttestRevoc] is in principle not relevant
[xiii] Note that JSON requires escaping certain characters ( ): quotation mark (U+0022), reverse solidus (U+005C), and the „C0 control characters“ (U+0000 through U+001F). All other characters are copied unchanged into the JSON UTF-8 string.
[xiv] The exact version to be referenced is to be determined. [ARF] references v0.2. v0.4 is the latest version available at the time of writing of this document. The level of interoperability between these versions is not known. As [SD-JWT] is still under development, presumably later versions will become available over time. 16 The exact version to be referenced is to be determined. [ARF] references v0.14 of 30 December 2022. Draft 17 is the latest version available at the time of writing of this document. The level of interoperability between these versions is not known. As [OpenID4VP] is still under development, presumably later versions will become available over time.
0 Ergänzungen