EUDI-Wallet: Eine Brieftasche voller Schlupflöcher

Bis 2030 sollen achtzig Prozent aller EU-Bürger:innen eine digitale Brieftasche nutzen. Eine Expert:innengruppe erarbeitet dafür die technischen Details. Weil sie sich dabei nicht an die gesetzlichen Vorgaben hält, hagelt es nun Kritik von Bürgerrechtlicher:innen.

Auch Käse hat Löcher. Und manchmal riecht er streng. – Midjourney (A piece of cheese with holes in the shape of the euro symbol, lying on a blue board with a small cutting knife next to it.)

Die digitale Brieftasche ist beschlossene Sache. Im Mai ist die eIDAS-Reform in Kraft getreten. Bis zum Herbst 2026 müssen nun alle EU-Mitgliedstaaten ihren Bürger:innen eine sogenannte „European Digital Identity Wallet“ (EUDI-Wallet) anbieten, mit der sie sich dann online und offline ausweisen können.

Laut EU-Verordnung soll die Wallet freiwillig, kostenlos und vor allem sicher sein. Außerdem sollen die Nutzer:innen transparent darüber bestimmen können, welche Daten sie an wen weitergeben. Doch wie lässt sich das technisch umsetzen? Und wie kann dabei ein datenschutzkonformer Austausch zwischen Bürger:innen, Behörden und Unternehmen erfolgen?

Antworten auf diese Fragen sucht derzeit eine Expert:innengruppe im Rahmen des European Digital Identity Projects. Sie soll, in enger Abstimmung mit der EU-Kommission, ein Architecture and Reference Framework (ARF) erarbeiten. Das Framework ist Teil einer „Toolbox“ – eines Werkzeugkastens –, die die Mitgliedstaaten gemeinsam erstellen. Die finale ARF-Version legt technische Spezifikationen, Richtlinien und Verfahren für die Umsetzung der eIDAS-Reform fest. Vor wenigen Wochen hat das Projekt die Version 1.4 des ARF veröffentlicht.

Die aktualisierten Spezifikationen stoßen bei der Bürgerrechtsorganisation epicenter.works auf massive Kritik. Sie wirft dem Projekt vor, entscheidende Vorgaben der eIDAS-Verordnung zu ignorieren und damit auszuhebeln. Damit drohe das Framework die im politischen Prozess mühsam ausgehandelten grundrechtlichen Errungenschaften wieder zunichte zu machen.

Konkret kritisiert epicenter.works unter anderem neue Schlupflöcher beim Datenaustausch, ein ausgehöhltes Recht auf Pseudonymität sowie Lücken bei der Unbeobachtbarkeit und Unverknüpfbarkeit.

Mehr Datenabfluss als gesetzlich erlaubt

Im ARF selbst heißt es: „Dieses Dokument selbst ist rechtlich nicht bindend.“ Verbindlich seien ausschließlich die beschlossenen Verordnungen wie eIDAS und verbundene Rechtsakte.

Die eIDAS-Reform reguliert die Anwendungsfälle streng, um die Daten der Nutzer:innen vor nicht legitimierten Zugriffen durch andere zu schützen. So sollen etwa sogenannte relying parties (deutsch: „vertrauenswürdige Parteien“) nur jene Informationen aus den Wallets abfragen können, die sie laut Gesetz erhalten dürfen.

Dazu zählen die Kontaktangaben der Nutzer:in oder das Mitgliedsland, in dem sie lebt. Außerdem muss die relying party bei jedem Vorgang gegenüber der Nutzer:in transparent machen, welche Daten sie zu welchem Zweck aus dem Wallet abruft. Vorab müssen sich relying parties in den jeweiligen EU-Mitgliedstaaten registrieren und darlegen, welche Daten sie von den Nutzer:innen anfordern werden. Das soll sicherstellen, dass Nutzer:innen nie mehr Daten preisgeben, als es die Verordnung vorsieht.

Obwohl der Text der eIDAS-Verordnung hier unmissverständlich ist – epicenter.works verweist auf die Artikel 5a und 5b der Verordnung –, macht das ARF derzeit noch keine technischen Vorgaben, die verhindern könnten, dass etwa Unternehmen mehr Daten bei den Nutzer:innen abfragen als sie dürften. Tatsächlich würde das Framework die entsprechenden Paragrafen „komplett ignorieren“, so epicenter.works. Wenn aber die klaren gesetzlichen Vorgaben nur unzureichend umgesetzt würden, mache es keinen Sinn, dass sich relying parties vorab registrieren müssten, kritisiert die NGO.

Pseudonymität wird ausgehöhlt

Um eine Überidentifikation zu vermeiden, sieht die reformierte eIDAS-Verordnung außerdem vor, dass Nutzer:innen immer dann ein Pseudonym verwenden können, wenn sie nicht dazu verpflichtet sind, ihre legale Identität preiszugeben. So können Nutzer:innen mit der Wallet eine Identität bestätigen, ohne persönliche Informationen preiszugeben. Sich mit der legalen Identität auszuweisen, ist dann nur notwendig, um beispielsweise ein Bankkonto zu eröffnen.

Das aktuelle ARF sieht jedoch vor, dass Strafverfolgungsbehörden Pseudonyme rückwirkend auf ihre rechtlichen Identität zurückführen können. Die Bestimmungen stünden damit „in krassem Widerspruch zu den gesetzlichen Vorgaben“, schreibt epicenter.works.

„Das Recht auf Pseudonymität schützt uns davor, dass Unternehmen wie Facebook oder die Schufa uns dazu zwingen, unsere bürgerliche Identität preiszugeben“, sagt Thomas Lohninger von epicenter.works gegenüber netzpolitik.org. „Bei der Umsetzung dieses Rechts wurde aber eine Hintertür eingebaut, die es Strafverfolgungsbehörden ermöglicht, jedes Pseudonym auf eine reale Person zurückzuführen.“

Kommission entfernt Vorgaben zu Pseudonymen

Welche Vorgaben die Expert:innengruppe hier genau machen wird, bleibt der Öffentlichkeit derzeit verborgen. Die Kommission hat das sogenannte Pseudonym Rule Book aus dem Repository entfernt. Es enthält konkrete Anforderungen, wie Pseudonyme innerhalb der EUDI-Wallet zu verwenden sind.

Auf Anfrage von netzpolitik.org teilte die Kommission mit, dass sie gemeinsam mit Fachleuten aus den Mitgliedstaaten in der eIDAS Expert Group übereingekommen sei, dass das Pseudonym Rule Book vor der Veröffentlichung auf GitHub weiter ausgearbeitet werden solle. Dieser Prozess sei derzeit im Gange.

Um eine öffentliche Diskussion über die Anforderungen des ARF zu ermöglichen, veröffentlichen wir die gelöschte Version des Pseudonym Rule Book Version in Volltext.

Expert:innen erfinden einen „Pseudonym-Provider“

Das ARF weicht auch in anderer Hinsicht gravierend von dem Gesetzestext ab, indem es kurzerhand das Konzept eines Pseudonym-Providers erfindet, wie epicenter.works schreibt. Eine solche Instanz ist in der Verordnung nicht vorgesehen. Pseudonyme sollen vielmehr lokal auf den Endgeräten der Nutzer:innen erstellt und gespeichert werden. Dennoch soll laut ARF nun eine externe Instanz für die Nutzer:innen Pseudonyme erstellen – die Behörden dann zum Klarnamen auflösen können.

Damit aber macht der ARF „die EUDI-Wallet zu einem Instrument der willkürlichen Massenüberwachung und autoritären Kontrolle, was mit der Charta der Grundrechte und der eIDAS-Verordnung unvereinbar ist“, schreibt epicenter.works in seiner Analyse. „Jede Verwendung der Wallet wäre damit von staatlicher Seite überwachbar“, fürchtet Thomas Lohninger. „Es drängt sich der Eindruck der Vertuschung auf, denn wir wissen nur durch einen Leak davon. Das relevante Dokument ‚Pseudonyms Rule Book‘ wurde halbherzig von der Website der Kommission entfernt.“

Jegliche Erwähnung eines Pseudonym-Providers müsse aus dem Regelwerk gestrichen werden, fordert epicenter.works. Außerdem dürften nur lokal generierte Pseudonyme zum Einsatz kommen, die verschlüsselt in der Wallet gespeichert werden und nicht mit der rechtlichen Identität einer Nutzer:in in Verbindung gebracht werden können.

Unbeobachtbarkeit kommt nicht vor

Um die Rechte der Nutzer:innen von Wallets zu schützen, sieht die eIDAS-Verordnung außerdem die Prinzipien „Unbeobachtbarkeit“ und „Unverknüpfbarkeit“ von Daten vor.

Unbeobachtbarkeit bedeutet, dass Wallet-Anbieter die in den Wallets gespeicherten Daten weder einsehen noch sammeln dürfen. Nur die Nutzer:innen sollen der Wallet entnehmen können, welche Transaktionen sie getätigt haben.

Diese Anforderung werde im ARF bisher jedoch an keiner Stelle erwähnt, kritisiert epicenter.works. Auch enthalte das Rahmenwerk „keinerlei Schutzmaßnahmen, die das Tracking, die Verknüpfung, die Korrelation oder das sonstige Sammeln von Informationen über das konkrete Nutzungsverhalten verhindern“, so die NGO.

Unzureichende Unverknüpfbarkeit

Das zweite Prinzip „Unverknüpfbarkeit“ besagt, dass verschiedene Identifizierungsvorgänge nicht zusammengebracht werden dürfen. Konkret bedeutet das: Kauft eine Person etwa wiederholt Alkohol im selben Geschäft und weist dabei ihr Alter mittels Wallet nach, darf der Verkäufer die verschiedenen Vorgänge nicht miteinander verknüpfen, um das Kaufverhalten dieser Person über einen längeren Zeitraum nachzuvollziehen.

Aus Sicht von epicenter.works weist das ARF dabei große Lücken auf. Dabei ist die Verordnung sehr klar. Der ARF müsste demnach „technische Verfahren zum Schutz der Privatsphäre ermöglichen, die die Unverknüpfbarkeit gewährleisten, wenn die Attributsbescheinigung keine Identifizierung des Nutzers erfordert.“

Diesem Anspruch werde das ARF nicht gerecht, kritisiert epicenter.works. Die vom ARF vorgesehenen Vorkehrungen würden „weder die Unverknüpfbarkeit in Bezug auf den Identitätsanbieter und die relying party noch die Unverknüpfbarkeit in Bezug auf die Präsentation bei derselben vertrauenswürdigen Partei“ gewährleisten.

Eine ähnliche Kritik am ARF hat vor wenigen Tagen eine internationale Gruppe von Kryptografen vorgebracht. Sie bemängelt, dass der aktuelle Vorschlag Verschlüsselungsverfahren vorsehe, die den Anforderungen der eIDAS-Reform nicht gerecht werden könnten. Das Problem lasse sich nicht schnell beheben, so die Expert:innen. Stattdessen brauche es grundlegend andere kryptografische Lösungen, um die Daten der Nutzer:innen zu schützen.

Für Thomas Lohninger gehen die Probleme inzwischen weit über technische Fragen hinaus. „Unser Vertrauen in den gesamten eIDAS-Prozess ist mit diesem Vorschlag schwer erschüttert. Die gesetzlich verankerten Rechte der Bevölkerung wurden von der Kommission und den Mitgliedstaaten einfach ignoriert“, so Lohninger. „Wenn sich die technische Umsetzung der Wallet nicht drastisch verbessert wird, sehen wir uns gezwungen, vor dem Europäischen Gerichtshof dagegen zu klagen und die Bevölkerung eindringlich vor der Wallet zu warnen.“

 

---

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:

1. 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.

2. 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.
3. 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.
4. 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.
5. The Wallet Instance SHALL allow the User to use multiple pseudonym values at a given Relying Party. In other words, if desired by the User⁷, 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.
6. 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.

7. 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.
8. 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.
9. 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.

10. 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.

11. 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.
12. 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.
13. 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.
14. 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:

1. 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].

2. 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.. ⁷ 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. ¹⁶ 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.

---

Die Arbeit von netzpolitik.org finanziert sich zu fast 100% aus den Spenden unserer Leser:innen.
Werde Teil dieser einzigartigen Community und unterstütze auch Du unseren gemeinwohlorientierten, werbe- und trackingfreien Journalismus jetzt mit einer Spende.