GDPR: General Data Protection Regulation

EU data protection regulation (2016/679). All EUDI Wallet implementations must comply with GDPR including user consent, data minimization, and right to erasure.

The EUDI Wallet processes some of the most sensitive personal data imaginable: government-issued identity credentials, biometric photos, addresses, and potentially health and financial information. This makes GDPR compliance not just a legal obligation but an existential requirement for the entire ecosystem.

The eIDAS 2.0 regulation explicitly states that the processing of personal data in relation to EUDI Wallets must comply with GDPR. This is reinforced in several specific provisions. Article 5a(14) requires that the processing of personal data by wallet providers shall be limited to what is strictly necessary for the provision of the wallet services. Article 5a(16) mandates that wallet providers shall not collect data on the use of the wallet that is not necessary for the provision of wallet services, and shall not combine personal data from the provision of wallet services with personal data from other services.

This creates a dual regulatory framework: the EUDI Wallet must comply with both eIDAS 2.0 (for its digital identity functions) and GDPR (for all personal data processing). In practice, the EUDI Wallet architecture has been designed from the ground up to satisfy both frameworks simultaneously, with privacy-by-design principles embedded in every component.

Article 5(1)(c) of GDPR establishes the principle of data minimization: personal data shall be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed." The EUDI Wallet implements this principle through several technical and architectural mechanisms.

Selective disclosure: The most direct implementation of data minimization. When a relying party requests identity verification, the user can share only the specific attributes needed. A bar verifying age needs only the "age_over_18" attribute, not the full name, address, or exact date of birth. The wallet technically enforces this by allowing individual claims within a credential to be disclosed independently.

Relying party data request justification: Under the ARF, relying parties must declare which attributes they need and for what purpose. The wallet displays this information to the user before they consent. If a relying party requests more data than appears necessary for the stated purpose, the user can decline the request. This transparency mechanism prevents excessive data collection.

No data retention by wallet providers: The wallet provider (the entity that distributes and maintains the wallet app) must not have access to the credentials stored in the wallet or the transactions the user performs. The wallet provider's data processing is limited to technical operations like software updates and security monitoring, with no visibility into the user's identity data or usage patterns.

GDPR Article 5(1)(b) requires that personal data be collected for "specified, explicit and legitimate purposes." The EUDI Wallet architecture implements purpose limitation through several mechanisms.

Purpose declaration by relying parties: When a relying party requests credentials from the wallet, it must declare the purpose of the data processing. This purpose is displayed to the user in the wallet interface. For example, a bank requesting PID data for KYC must state that the purpose is "customer due diligence under anti-money laundering regulations."

Explicit consent before every presentation: The EUDI Wallet requires explicit user consent before any data is shared. The user must actively approve each credential presentation after reviewing what data will be shared, with whom, and for what purpose. There is no automatic or background data sharing. This goes beyond GDPR's consent requirements by making consent the mandatory legal basis for every credential presentation.

Transaction logging: The wallet maintains a local log of all credential presentations, showing what data was shared, with which relying party, and when. This gives users a complete audit trail of how their data has been used, supporting GDPR's transparency principle. The log is stored locally and is not shared with the wallet provider.

No blanket consent: The wallet architecture prevents relying parties from obtaining blanket consent for future data processing. Each presentation is a discrete event requiring fresh consent. A relying party that needs updated data must request it again, giving the user the opportunity to review and approve (or decline) each request.

GDPR Article 17 establishes the right to erasure ("right to be forgotten"), which has specific implications in the wallet ecosystem.

Deleting credentials from the wallet: Users can delete any credential from their wallet at any time. Since credentials are stored locally on the device, deletion is immediate and complete. The wallet provider cannot prevent or delay deletion, and once deleted, the credential cannot be recovered (the user would need to request a new credential from the issuer).

Deactivating the wallet: Users can deactivate their entire wallet, which triggers the deletion of all credentials, transaction logs, and cryptographic keys. The wallet provider must ensure that any data it processed in connection with the wallet (such as wallet instance identifiers) is also deleted.

Limitations of erasure: The right to erasure does not extend to data that relying parties have already received and processed for legitimate purposes. If a bank received PID data for KYC purposes, GDPR's erasure right applies to the bank's copy of the data under the bank's own data retention policies, but the wallet has no technical ability to force deletion from the relying party's systems after presentation.

Revocation vs. deletion: Deleting a credential from the wallet is different from revoking it. Deletion removes the credential from the user's device. Revocation (performed by the issuer) marks the credential as invalid in the revocation infrastructure, so verifiers will reject it even if a copy still exists. Users who want their PID invalidated must contact their PID Provider to request revocation.

Given the scale and sensitivity of personal data processing in the EUDI Wallet ecosystem, GDPR imposes specific organizational requirements on wallet providers and PID Providers.

Data Protection Officer (DPO): Under GDPR Article 37, wallet providers and PID Providers must appoint a DPO because they are public authorities or bodies, or because they carry out processing which requires regular and systematic monitoring of data subjects on a large scale, or because they process special categories of data on a large scale. The DPO must be involved in all data protection matters from the design phase through ongoing operations, and must have direct access to the highest level of management.

Data Protection Impact Assessment (DPIA): GDPR Article 35 requires a DPIA when processing is likely to result in a high risk to the rights and freedoms of natural persons. The EUDI Wallet clearly triggers this requirement: it processes identity data at national scale, involves new technologies, and enables large-scale systematic processing of personal data. Each member state's wallet implementation must undergo a thorough DPIA covering all processing operations, from PID issuance to credential presentation, including an assessment of the risks to users' fundamental rights.

Privacy by design and by default: GDPR Article 25 requires data protection by design and by default. The EUDI Wallet architecture embodies this principle through local data storage (no central database), selective disclosure (minimum data sharing by default), issuer and verifier unlinkability (preventing tracking), and user-controlled consent for every data sharing event. These are not add-on features but fundamental architectural choices that shape every aspect of the wallet's design.