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.
Related resources from NHI Mgmt Group
- How should organisations design digital identity apps so users retain control of their personal data?
- How should organisations design tenant identity flows so users can share financial data securely across multiple services?
- How should organisations design digital identity systems that minimise unnecessary data sharing during authentication?
- Why do organisations struggle to keep secrets management and non-human identity governance under control as environments expand?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
