eIDAS2, the EUDI wallet and the GDPR (IV)

Photo by Growtika on Unsplash

Continuing the exercise from previous posts, where we consider different threats posed by EUDI Wallets, this post focuses on two main questions:

1. Is the EUDI Wallet ecosystem reliable? Can Relying Parties trust my electronic attestations of attributes (credentials) to make correct decisions?
2. If I use the EUDI Wallet in a transaction that is not legally required to keep records or data for audits, can I later deny having made that transaction?

Concerning the first question, we need to analyse Inaccuracy threats within the EUDI Wallet ecosystem. These relate to using obsolete, wrong, incomplete, biased, or low-quality data that may lead to incorrect decisions or actions, potentially causing inconvenience or even harm to the data subject.

In the context of attribute issuance and presentation, inaccuracy threats often arise from data that is not fresh or valid. For example, when identity attributes conveyed by attestations have changed since these attestations were issued. If an electronic attestation of attributes is not up-to-date, it typically means the information it contains (such as age, legal status, or qualifications) has changed since issuance, or, more critically, that the attestation has been revoked or expired.

Furthermore, during identity proofing, inconsistencies or inaccuracies in reference data, such as transliteration differences, homonyms, or incomplete entries, can occur. In addition, any flaw or inaccuracy in the remote identity verification process can materialise this threat, including errors in the software managing identity documents. Finally, there may be explicit attacks in which an adversary compromises the security of information systems used for identity proofing to illegitimately modify information or enforce a specific identity proofing result.

The primary impact of these Inaccuracy threats is the potential for incorrect decisions or actions based on unreliable data, which compromises the assurance level of identity verification processes and the results of authentication or authorization processes that rely on the EUDI Wallet. It has to be considered that the result could be the impersonation (identity spoofing) of the data subject.

Imagine a User holding an electronic attestation of attributes issued by a public sector body. The attestation contains their date of birth and a derived boolean claim stating their age status, such as “age_over_18: False” (if issued when they were 17). The User turns 18 years old. The date of birth remains correct, but the derived, attested attribute value in their possession is now obsolete because the information has changed since the attestation was issued. The User attempts to access an online financial service that requires a legal majority (age ≥ 18) to open an account or apply for public aid or a loan. They present their electronic attestation of attributes to the service (the Relying Party, RP). The RP checks the supplied attribute values. If the RP relies on an obsolete, non-updated boolean attribute value (still “age_over_18: False”), because the issuer did not immediately revoke and reissue a new attestation reflecting the new User’s status, the RP considers them ineligible. The financial service makes an incorrect decision on obsolete data and rejects the User’s application.

To address these risks, the ecosystem may rely on several measures. First, Issuers may revoke and reissue attestations if information related to the user’s identity changes. Second, the EUDI Wallet itself should provide proactive reminders when an attestation is approaching its expiration date or has already expired, directing the user to renew or update the credential. This measure helps the user avoid using attestations that are functionally obsolete, even if not proactively revoked by issuers. Finally, when an RP attempts validation, they must verify that the attestation is still valid, meaning it has not been revoked, it has not expired, or it has not been reported as lost/stolen. In any case, these measures do not completely prevent the threat from materialising. Furthermore, there is the challenge of ensuring that their implementation does not introduce additional privacy threats; for example, as we discussed in previous posts, some mechanisms that allow for revocation pose a risk of linking.

Concerning the second question, Non-repudiation is a threat that prevents the data subject from denying their involvement in a specific transaction where the EUDI Wallet has been used: requesting an attestation, presenting it, etc. Plausible deniability for non-legal transactions relying on the EUDI Wallet should be guaranteed. However, if the transaction mechanisms create a persistent, verifiable link or non-repudiable proof of a user’s actions, the user loses the ability to deny their involvement, even in contexts where privacy is paramount.

This threat can be materialised mainly due to cryptographic mechanisms that are inherently linkable, such as linkable signatures included in the attestation formats currently specified for the EUDI Wallet (ISO mDL and SD-JWT), and attestation binding (device binding, attribute-based binding, etc.).  In addition, due to potential collusion among parties participating in transactions, such as Issuers, RPs, and Wallet providers.

The main impacts of this threat are profiling and surveillance, coercion, and stigmatization. Although in the most extreme cases the physical integrity of the data subject could be at risk. Imagine a user having two different attestations in their EUDI Wallet: one certifying their identity data (issued by a government body) and another certifying their residency in City X (issued by the City Registry). The User needs to present both simultaneously to a third-party service (the Relying Party, RP) to confirm they qualify for participate in union elections, make a contribution to a civil rights organization or a local political party, or access a reproductive health clinic. To prevent fraud, the RP requires proof of cryptographic binding between attestations, demonstrating that both attestations are bound to the same Wallet Secure Cryptographic Device (WSCD) controlled by the User. The User presents the attributes, and the Wallet generates this proof, a non-repudiable signature that definitively confirms that the User, on their specific certified device, presented that exact combination of credentials for that transaction.

If the government then changes to an authoritarian one and any of those activities become suspicious or illegal, the User cannot plausibly deny their involvement in the performed transaction. The non-repudiable signature creates a forensic, permanent record linking them, their device, and the combined data set to the exact time of the transaction. This failure to preserve plausible deniability undermines the User's privacy and could expose them to the already mentioned impacts, as they cannot deny having executed the specific action of combining and presenting that data to that RP.

Current mitigation strategies rely on issuing short-lived attestations or providing batches of single-use credentials that the user can randomize. However, the optimum solution should be based on anonymous credentials and Zero Knowledge Proof (ZKP) mechanisms.

All the mentioned technical and governance safeguards, along with other high-level requirements, must be integrated in the EUDI Wallet ARF to ensure future solutions mitigate inaccuracy and non-repudiation 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 (III) [october 2025]
• eIDAS2, the EUDI wallet and the GDPR (II) [june 2025]
• eIDAS2, the EUDI wallet and the GDPR (I) [january 2025]