eIDAS2, the EUDI wallet and the GDPR (III)

Photo by Brett Jordan on Unsplash.

The eIDAS2 regulation aims to ensure data protection and privacy for EU Digital Identity Wallets. However, a central question arises: Can I use my wallet to anonymously prove specific conditions, such as being a student, being of legal age, or being a member of an association, without revealing my identity? If not, who has the ability to identify me and by what means?

In the context of EUDI Wallets, identifying threats arise when parties such as issuers, Relying Parties (RPs), or Wallet providers inappropriately or unnecessarily learn a user's real-world identity. This becomes particularly relevant depending on the use case. For example, certain scenarios, such as border crossing or payment, require secure identification and authentication of the user. In contrast, other scenarios, such as age verification, only require proof of a specific attribute and should preserve the user's anonymity. Identifying threats, sometimes referred to as over-identification, can be materialized directly or indirectly (resulting from a failure to decouple a user's identifying attributes from their pseudonymous or non-identifying transactions). 

With direct approaches, a RP requests the user to identify when it is not necessary. Safeguards should ensure that a Relying Party cannot request user identification unless it is strictly necessary, and that the EUDI Wallet supports pseudonyms to help prevent over-identification.

RPs intending to use the EUDI Wallet must register in the Member State where they are established. During registration, they must specify their intended use of the Wallet, including the exact data they will request and the reasons for doing so. RPs are not allowed to request any additional data from users beyond what they have registered. This process prevents practices such as an RP asking for a user's full name when only age verification is required and serves as a key enforcement tool for data minimization and the prevention of identification threats.

The EUDI Wallet framework enhances transparency by making RP registration information publicly available online in a user-friendly format. The Wallet Unit must read the RP's intended use from this registration and alert the user if extra information is requested (data that was not intended for the registered purpose, for example, to identify the user), giving the user the option to reject the transaction. This allows users to accept or decline presentations and prevent over-identification.

Furthermore, the EUDI Wallet must let users create and manage their own pseudonyms. RPs cannot reject pseudonyms unless required by law. Ensuring data minimization and data protection by design and by default can be achieved by using pseudonyms as the default option, revealing identity only when strictly necessary. Identification data must be processed only when required, usually for legal KYC needs.

To ensure that using a pseudonym does not itself become a mechanism for tracking, the Wallet Unit must generate pseudonyms local to each Relying Party (different for each, specific, and not shared). This ensures that the use of a pseudonym with one RP cannot be linked to the use of the same pseudonym with a different RP, thereby preventing cross-RP correlation. Furthermore, pseudonyms should be unlinkable to identities for the different Relying Parties and other parties participating in the ecosystem.

With indirect approaches, a particularly critical context arises when parties such as RPs and issuers collude to combine their knowledge and infer identity data beyond what each party knows independently. This is exacerbated if linking threats are also realized.       

Suppose a user relies on their EUDI wallet for two different purposes: one that requires anonymity (like age verification) and another that requires full identification (such as registering for a regulated online service). In this scenario, the user possesses a digital driver's license (a PID) issued by a government authority, which includes attributes such as name, Date of Birth, and Address. The issuing authority maintains all unique element values (including salts, hashes, and signature values) associated with each attestation it provides.

RP A is a private online adult content site that only needs proof that the user is “over 18” (an anonymous claim). RP B is a regulated financial service (such as a bank or a cryptocurrency exchange) that needs full Know-Your-Customer (KYC) identification, including the user's full name and possibly additional information, as required by law.

The user accesses RP A and uses selective disclosure on their digital driver's license to show only proof of being “over 18”. Even with selective disclosure, the presentation to RP A must include unique, non-revocable elements from the original attestation, like the issuer's signature and cryptographic fingerprints (salts or static hashes) for validation.

The user then registers for RP B, the financial service, which requires full identification, including Name and Date of Birth. The user presents the same digital driver's license (or an instance from the same batch) to RP B, fully revealing identity data. This presentation also contains the same unique, persistent identifiers or cryptographic elements as the one used for RP A.

RP A and/or RP B collude with the original issuer by sharing the unique elements they received (e.g., the specific signature value or salt value). Since the issuer stores all unique element values associated with the user’s true identity at the time of issuance, and RP A/RP B provide the linking element, the issuer can correlate the anonymous transaction at RP A with the identified transaction at RP B. The colluding parties successfully link the user's full, real-world identity to their otherwise anonymous activity (adult content consumption). The user's profile has been derived beyond what was explicitly known to RP A (which only knew “over 18”) or the issuer (who should not know where the credential was used). This scenario leads to unauthorized surveillance and profiling via the unique identification of the data subject.          

The user's expectation of privacy, based on selective disclosure, is violated when unintended data is exposed. This outcome highlights that selective disclosure alone does not sufficiently protect privacy without additional measures such as guarantees of unlinkability. 

Decisions on other EUDI Wallet aspects may also affect identifying threats. These aspects include transaction logs (that may contain identity data about the user), Embedded Disclosure Policies (mechanism for controlling the release of attributes from the EUDI Wallet to RPs), attestation binding (to the device or the holder), authentication, or combined presentation of attestations. The EUDI Wallet ARF is in development. Twenty-three items, referred to as Discussion topics, are under review until the end of 2025. All the mentioned technical and governance safeguards, along with other high-level requirements, must be integrated in this ARF to ensure future wallets mitigate identification threats and meet the GDPR's principles and requirements. 

Future posts will analyse and illustrate other threats. This post is related to some other materials published by the Innovation and Technology Division of the AEPD, such as:

• eIDAS2, the EUDI wallet and the GDPR (II) [june 2025]
• eIDAS2, the EUDI wallet and the GDPR (I) [january 2025]