How should organisations design digital identity flows so users keep control of their data under eIDAS 2.0?

Organisations should build identity journeys around explicit consent, selective disclosure, and data minimisation. The user must control what is shared, with whom, and for which purpose. In practice, that means designing wallet-based flows that verify only the attributes required for the transaction, while keeping identity data separate from unrelated services and avoiding unnecessary data aggregation.

Designing user-controlled identity journeys under eIDAS 2.0

Under eIDAS 2.0, the design goal is not just authentication, it is user-directed disclosure. Organisations should structure flows so the user can see what is requested, approve each release of data, and rely on the wallet to present only the minimum attributes needed for the transaction. That makes identity design a consent and data-governance problem, not just an integration task.

Designing for control means the organisation should treat identity data as purpose-bound rather than reusable by default. The wallet pattern is effective only when the service asks for a narrow attribute set, uses verifiable claims instead of broad profile collection, and avoids building a hidden secondary use case around the same identity event.

For the eIDAS 2.0 legal baseline, the clearest reference point is the eIDAS 2.0, EU Digital Identity Framework, which frames digital identity around interoperable wallet-based exchange and cross-border trust. In practice, the policy direction supports selective disclosure, but the implementation quality depends on whether the relying party actually limits requested data to what the transaction requires.

How selective disclosure changes the architecture

Selective disclosure shifts the architecture away from centralised identity repositories and toward attribute-by-attribute presentation. That means the relying party should verify only the claim it needs, for example age eligibility, residency, or entitlement, rather than pulling a full identity profile. The flow should also make it clear which party is controller of which data element at each step.

The practical consequence is that identity journeys need tighter boundaries between authentication, attribute verification, and downstream service provisioning. If the same integration silently fans out into CRM, analytics, fraud, and product personalisation, the user may still be authenticated correctly while losing meaningful control over how their identity data is reused.

Where teams need a protocol-level pattern for delegated presentation or token exchange, OpenID Connect Core 1.0 and RFC 8693: OAuth 2.0 Token Exchange illustrate the separation between the subject, the token presented, and the service consuming it. Those patterns help teams design flows where the credential or assertion is scoped to one purpose instead of becoming a reusable access trail.

Teams that want a broader privacy lens should also consider the separation and minimisation principles in the EU General Data Protection Regulation (GDPR), especially where identity attributes may be personal data or sensitive data. The design takeaway is simple: if a field is not necessary for the transaction, do not ask for it, store it, or propagate it.

What organisations should verify before going live

The hardest control problem is not proving that the wallet can release a claim, it is proving that the service does not collect more than the claim it needs. Organisations should verify the attribute request set, the consent screen, retention rules, downstream data sharing, and whether the same identity event is being reused for unrelated profiling or account creation.

It is also worth checking whether failure modes push the system back toward overcollection. If a missing attribute causes the product to fall back to full document capture, manual upload, or bulk profile import, the user-control model has effectively been bypassed. Good design preserves utility without silently expanding the data footprint.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 sets the technical controls, while GDPR and ISO/IEC 27001:2022 define the regulatory obligations.

Framework	Control / Reference	Relevance
GDPR	A.5.15 — Data Protection by Design and Default	Selective disclosure and minimisation are core to user-controlled identity flows.
Recommendation — Minimise requested attributes and default identity flows to the least data needed for the transaction.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Wallet-based identity flows rely on controlled lifecycle handling of tokens and assertions.
	AC-6 — Least Privilege	Attribute release should be limited to the minimum necessary claims and permissions.
	IA-8 — Identification and Authentication (Non-Organizational Users)	Consumer digital identity journeys authenticate external users through wallet-based assertions.
Recommendation — Scope and rotate identity credentials or tokens so they are not reused beyond the intended transaction. Restrict attribute access and release to the minimum set required for each relying party. Validate external-user identity with phishing-resistant, wallet-compatible authentication flows.
ISO/IEC 27001:2022	A.5.12 — Classification of information	Identity attributes should be classified to control what can be shared and retained.
	A.5.15 — Access control	Only the requesting service should receive the claims needed for the stated purpose.
Recommendation — Classify identity attributes so release and retention rules follow the data sensitivity. Limit service access to the specific identity attributes needed for the transaction.

Practitioner Guidance

What to prioritise: Start with the attribute set, not the login flow. The most important design decision is which claims are actually required for the transaction and which systems are allowed to retain them after verification.

What to verify: Confirm that consent is granular, revocable where the legal model requires it, and visible to the user at the moment of release. If the service cannot explain why it needs a field, the field does not belong in the request.

Common mistake: Treating wallet integration as a front-end change while leaving the back-end data model untouched. That usually preserves legacy overcollection, only now it is wrapped in a modern identity layer.

Practitioner takeaway: The real test of an eIDAS 2.0 flow is not whether it authenticates the user, but whether it prevents unnecessary identity reuse after the transaction ends.