eIDAS2, the EUDI wallet and the GDPR (II)

Photo by NordWood Themes on Unsplash.

The eIDAS2 regulation aims to ensure data protection and privacy for EU Digital Identity Wallets. Even so, the following questions arise in the new scenario:

1. If I use my wallet  when I am buying products or accessing private or public services, is the issuer of the digital attestation (governmental or private) able to learn anything about my activities? Even in real time?
2. If I use my wallet to disclose anonymously that I am a student, old enough to access adult services, member of an association or any other condition, is it possible to track my activity because all my accesses can be linked?  And, therefore, is it possible to monitor or profile me? Who could do it?

eIDAS2 requires to ensure the unlikability property, so it is impossible to associate different data items or actions to a specific data subject. This property is crucial because it prevents the tracking and correlation of the data subject's activities, avoiding profiling and surveillance, even in the event of data breaches or collusion between different parties involved in the personal data processing.

The Architecture and Reference Framework (ARF) provides a set of common standards, technical specifications, and best practices that Member States should follow when implementing wallets. The lack of a comprehensive approach to unlinkability in this ARF is concerning. Despite eIDAS2's mandate for privacy-preserving techniques, the current situation is that we have no details about how unlinkability will be technically achieved, leaving room for implementations that might not adequately protect user’s personal data. However, the ARF is still in development, to complete it, 23 different items (called topics) are being addressed and discussed up to end of 2025. And several of them face this issue.

The answer to question 1 depends on the decisions made for the ARF final version and on how (and to what extent) it guarantees unlinkability with respect to electronic attestations issuers, that may be governmental or private entities. They should not be able to know or learn anything about when, where, and to which service providers (Relying Parties or RPs) a data subject presents their electronic attestations relying on the EUDI wallet. This is often called unobservability. Suppose the issuer of a +18 age credential is storing all unique element values (salts, hashes, public key, signatures value) in all the issued credentials. If one or more RPs share with the issuer the value of any of the unique elements in a received attestation (even indirectly, for example, through the revocation mechanism), the issuer can link the transaction to the corresponding data subject, track at which RPs they present their attestations (adult websites, gambling platforms, alcohol stores, etc.) and profile them. This is exactly what should be avoided.

The answer to question two depends again on the final ARF and whether it guarantees unlinkability with respect to RPs (service providers), too, across different presentations. Suppose the user presents an Electronic Attestation of Attributes to an RP during different sessions or transactions.  In that case, the RP should not be able to know or learn (relying on additional data or information such as metadata, data not explicitly revealed by the user or additional data sets) that these transactions correspond to the same user. Furthermore, if the user presents an Electronic Attestation of Attributes to different RPs, they should not be able to know or learn that these transactions correspond to the same user. This is often called multi-show unlikability. Suppose a user wants to be part of a discount or loyalty program relying on the wallet. Unique element values may allow all the parties offering discounts to link all the transactions to the corresponding data subject that may be subject to behavioural profiling or price differentiation. Again, this should be avoided.

Furthermore, in this case a different unlinkability can be considered when RPs and issuers collude, sharing information, or a third party manages to compromise both parties (for example, in the event of a data breach at the RP and the issuer). In this case, the issuer providing attestations to the user should not be able to know or learn anything about the user from the information known at the RP. And the other way around. This is often called full unlikability or untraceability, as it means that the issuers and RPs cannot trace a user's attestations usage and their transactions. If we go back to the example of the +18 age credential, in this case one or more RPs could collude with the attestation issuer to cross-check information and link transactions to specific data subjects and build profiles. Or both parties would suffer a data breach and anyone with access to their information could combine it and build the same profiles of the data subjects.

As seen in the examples, in general, a linking threat can be materialised directly through unique identifiers or indirectly by combining different data about the data subject or profiling their behaviour.

The eIDAS2 regulation promotes unlinkability. However, the current ARF proposes using ISO mDL (mobile Driver's License) and SD-JWT (Selective Disclosure JSON Web Token) attestation formats, which might not be sufficient for ensuring strong unlinkability because they rely on signatures for validation.

These signatures are unique identifiers that allow recognising a data subject's signature across multiple presentations, even if only selective information is disclosed. If an electronic attestation provider issues a digital driver's license containing attributes such as name, birth date, and address, RPs and the attestation provider, with their help, could track the data subject's presentations of this license in the same RP and across different RPs through the signature, even if the user only discloses their age or address each time. Multi-show unlikability and full unlikability (or untraceability) are not possible in this case. The same would happen with other possible unique persistent identifiers, explicit or implicit (within metadata, for example, IP addresses).

A different example would be materialising the linking threat, taking advantage of the mandatory revocation mechanisms required by eIDAS2. If the revocation mechanism requires the RP to contact the issuer or a central authority to check the validity of an electronic attestation, this interaction could create a linkable trace. The RP could potentially infer that multiple presentations with the same revocation status or timestamp originated from the same data subject, even if the attributes disclosed are different in each presentation. On the other hand, revocation mechanisms involving the attestation issuer in the validation process may also be a problem from this issuer point of view. Even if the issuer only learns about the revocation status and not the specific attributes being presented, the fact that the data subject interacts with the RP at a particular time and location may be tracked. This creates a trail of the data subject activity that the issuer can correlate with other information.

The most severe linking threat arises when the revocation mechanism allows both the issuer and the RP to collect information about the data subject activity. If both parties can access the revocation status, timestamps, or other identifiers associated with the electronic attestation, they can collude to track the user across different transactions and RPs.

The ARF, the implementing acts, and different community proposals, suggest reducing the scope or the frequency of potentially linkable interactions. For example, issuing short-lived attestations or batches of multiple credentials for only a few uses or one unique use. Furthermore, limiting revocation checks to attributes with a validity period exceeding 24 hours. However, these solutions may cause usability problems due to the required data subject involvement when asking for, storing and managing a vast number of electronic attestations, for example. In addition, they could cause substantial operational costs for issuers and do not prevent all mentioned threats.

The best approach could be to rely on cryptographic techniques like randomised or blind signatures, zero-knowledge proofs (for example, to prove the validity of an electronic attestation credential without revealing any identifying information to the RP or the issuer), anonymous credentials or revocation mechanisms based on cryptographic accumulators, to mention only some examples. The question would be: are there effective and secure designs and implementations of these techniques, supported by hardware, that could be standardised, certified and state-approved? There is a need for continuous research, development, and collaboration to create privacy-preserving solutions that align with the goals of the eIDAS2 regulation. 

Future posts will analyse and illustrate other threats different than linking. 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 (I) [january 2025]
• Identity as a right [june 2024]