Selective disclosure is often described as if it were a GDPR compliance feature. It is not — it is a cryptographic capability that lets a wallet reveal only specific attributes from a credential rather than the entire signed object. Whether that capability actually produces a GDPR-compliant data flow depends entirely on what the relying party requests, why, and what happens to the data afterwards. A verifier that requests fifteen attributes because the wallet technically supports asking for them is no more compliant than one still scanning full ID documents.
What selective disclosure actually changes
In SD-JWT VC and mdoc formats, an issuer signs a credential containing multiple attributes, but the presentation protocol lets the holder disclose a subset while preserving the cryptographic proof that the disclosed attributes come from a genuinely issued, unaltered credential. Practically, this means a relying party can ask for and receive a single boolean — "is over 18" — without ever seeing a date of birth, a document number, or a photograph.
This is a genuine architectural improvement over document scanning, where minimisation was impossible because the whole document had to be captured to extract any single fact. But the improvement is only realised if the relying party's request is actually scoped to the minimum necessary — the protocol does not enforce that on your behalf.
Data minimisation is still your legal obligation, not the protocol's
Article 5(1)(c) GDPR requires personal data to be adequate, relevant and limited to what is necessary for the purpose. When you define a presentation request, you are making a data protection decision, not just a technical one. The question to answer before writing the request is not "what could this credential tell us" but "what is the single fact that satisfies our actual legal or contractual purpose".
- Age verification for a restricted product: request an age-over-18 boolean, not a date of birth.
- Professional licensing checks: request a licence-valid boolean and licence category, not the full professional registry record.
- Employment verification: request an employment-status attribute from an employer-issued attestation, not a full employment contract extract.
- Residency checks for regulatory purposes: request a country-of-residence attribute rather than a full address.
Each of these substitutions is only possible because non-qualified attestations and PID fields are granular enough to support attribute-level requests. Designing that request list is, in practice, the main data protection design decision in a wallet integration.
Lawful basis does not disappear because the data is verified
A common misconception is that because a wallet credential is cryptographically verified and consented to at the point of presentation, the relying party's GDPR lawful basis obligations are somehow simplified. They are not. The wallet's consent screen governs the user's disclosure decision within the wallet ecosystem; it does not itself constitute your organisation's lawful basis under Article 6. You still need to identify and document whether your basis is contractual necessity, legal obligation, legitimate interest, or consent obtained through your own privacy notice — and it must match the actual attribute set you request.
The wallet's consent screen tells the user what you are asking for. It does not tell your DPO why you are legally allowed to ask for it.
DPIA obligations for relying parties
Verifying wallet credentials at scale typically involves systematic processing of identity attributes tied to a unique, cryptographically bound identifier, which commonly triggers the criteria for a Data Protection Impact Assessment under Article 35, particularly where special category data, large-scale processing, or automated decision-making based on the verified attributes is involved. A DPIA for a wallet integration should specifically address:
- The precise attribute set requested and the necessity justification for each one.
- Retention periods for both the raw presentation response and any derived record (such as "age verified on [date]").
- Whether verification results are logged in a way that could be re-identified or combined with other data to build a broader profile.
- The role and data flows of any intermediary Relying Party used for the technical verification, including what it retains versus what it forwards.
- Cross-border transfer implications if the intermediary or issuer sits in a different Member State's trust infrastructure.
The over-asking risk is now a visible one
Document-based onboarding hid over-collection inside a single capture step — nobody saw exactly what was extracted from a scanned ID. Wallet presentation requests are the opposite: the user's wallet displays precisely which attributes are being requested and by which organisation, before consenting. A request for a home address to verify age, or a request for a full name and national identifier to check professional licensing status, is now visible to the user at the point of the ask, not buried in a privacy policy. Over-asking is a reputational and regulatory risk that is now user-facing by design, which raises the practical cost of getting the request scope wrong.
Retention: verified does not mean storable
A verified attribute is still personal data once stored, and GDPR's storage limitation principle applies exactly as it would to any other personal data. In most onboarding scenarios, the defensible pattern is to retain only the outcome of the check (a boolean, a timestamp, and a reference to the verification event) rather than the underlying attribute value, and to define a retention period tied to the purpose — for example, the duration of an active contractual relationship plus any statutory retention period, not indefinite storage on the basis that verification was convenient to obtain.
How intermediation affects the compliance picture
Using an intermediary Relying Party changes the data flow, and your DPIA and records of processing need to reflect that accurately: the intermediary typically handles the raw signature verification and trust chain checks, and forwards to your systems only the specific attribute result you requested. This is itself a minimisation benefit — your infrastructure never touches signed credential payloads it does not need — but it also means your processing agreement with the intermediary needs to clearly define what is processed on your behalf, what the intermediary retains for its own audit and conformance obligations, and for how long. Arkadiz's model is built around forwarding only the requested attribute outcome to relying parties, which keeps the minimisation benefit of selective disclosure intact end to end rather than reintroducing over-collection at the intermediary layer.