The biggest mistake is asking for document-level identity when attribute-level proof would satisfy the purpose. That creates extra friction, expands data liability, and makes the process feel intrusive. If the business only needs an age check, the flow should not demand a full birthdate or identity scan.
When wallet-based identity should stop asking for full identity
The mistake is treating every onboarding flow like a full identity proofing event. If the purpose is only to verify one attribute, such as age or residency, the right design is selective disclosure or an equivalent attribute proof, not a broader identity capture flow that collects more data than the business actually needs.
That distinction matters because wallet-based onboarding is not just a UX problem. It shapes what personal data enters your systems, how much liability you create, and whether the flow matches the actual assurance requirement instead of defaulting to the most invasive option.
For wallet and identity-wallet patterns, the better mental model is purpose-first verification, then only the minimum claim needed to satisfy that purpose. Digital Identity, eID and Identity Wallets Guide is useful here because it explains how wallets, verifiable credentials, and selective disclosure change the verification design.
Why over-collecting identity data backfires
Over-collecting identity data creates avoidable friction, especially in onboarding where abandonment is already a risk. It also widens the blast radius if the data is stored, logged, forwarded to vendors, or retained longer than necessary. In practice, the extra fields often do not improve assurance at all when the business decision only depends on a single verified attribute.
The operational problem is mismatch: a full identity scan can be the wrong control for a narrow eligibility check. A wallet can support proof of a claim without exposing the underlying document set, but only if the integration is designed around the claim the business truly needs.
Good onboarding design starts with the minimum question the business must answer, then maps that to the smallest evidence set that can answer it. If the answer is “is this person over 18?”, the flow should not drift into “prove your full legal identity” unless a separate legal or fraud requirement justifies that step.
That principle also helps reduce unnecessary processing of sensitive data. eIDAS 2.0, the EU Digital Identity Framework is relevant because wallet-based identity flows are expected to support selective disclosure and reusable identity patterns, which are most effective when the relying party asks only for the attribute it needs.
What a better wallet-based onboarding flow looks like
A better flow separates three decisions: what attribute is needed, what level of assurance is needed, and what data can be withheld. That means the onboarding team should decide whether the use case needs an age assertion, a residency assertion, a membership assertion, or a full identity proof, and then use the matching wallet capability rather than one generic “verify identity” button.
Where the relying party can accept a cryptographically signed claim, the flow should request only that claim. Where higher assurance is needed, the design should explain why. The user should not have to guess why a document scan is being requested when the product only needs a binary yes or no.
This is also where policy and implementation often diverge. Teams frequently know they need “verification,” but they have not defined the minimum acceptable proof. Without that definition, product teams overbuild the form, compliance teams over-request evidence, and users experience the result as surveillance rather than validation.
For teams choosing an implementation pattern, Identity Proofing and KYC Guide provides the broader assurance context, while Identity Verification Buyer’s Guide is useful when you are comparing vendors and want to avoid buying a document-heavy process when a lighter proof would do.
Risk and Threat Considerations
Over-asking for identity data increases privacy exposure, retention burden, and the impact of any compromise because the organisation collects more than it needs. It also creates a trust problem: users are more likely to abandon onboarding or supply poor-quality data when the request feels disproportionate to the service.
Failure mechanism: The flow conflates proof of an attribute with proof of a full identity, so the application collects documents and birth data even when a narrower verifiable claim would satisfy the control objective.
Impact: That mismatch increases data liability, enlarges the attack surface for stolen identity material, and makes the onboarding process slower and less credible to users.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS and NIST SP 800-63 set the technical controls, while EU AI Act and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| EU AI Act | Risk Management and Transparency Obligations | Wallet identity flows can involve AI-assisted verification decisions and disclosure. |
| Recommendation — Document when automated verification influences onboarding decisions and user disclosure. | ||
| OWASP ASVS | V8 — Authorization | The flow must request only the claims needed for the authorised onboarding decision. |
| V14 — Data Protection | Collecting full identity when an attribute proof would suffice creates avoidable data exposure. | |
| Recommendation — Restrict the onboarding request to the minimum identity claim needed for the decision. Minimise stored personal data and verify claim-based handling in the onboarding flow. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | The question hinges on choosing the right assurance level for the purpose, not defaulting to full proofing. |
| Recommendation — Match the assurance level to the actual onboarding purpose before requesting stronger evidence. | ||
| ISO/IEC 27001:2022 | A.5.34 — Privacy and Protection of PII | The mistake directly affects how much personal data is collected and exposed during onboarding. |
| Recommendation — Limit identity collection to the minimum personal data required for the stated purpose. | ||
Practitioner Guidance
What to prioritise: Start by defining the minimum claim the business actually needs, then decide whether the control objective is attribute verification, identity proofing, or both. If the need is only eligibility, design the flow around the eligibility signal, not around the full identity record.
What to verify: Check whether the wallet integration is requesting more attributes than the downstream decision uses. If the relying party stores a full identity scan but only consumes a yes or no response, that is usually a design defect, not a security enhancement.
Common mistake: Teams often assume that more identity data means better assurance. In wallet-based onboarding, the better question is whether the extra data changes the decision outcome; if it does not, it should not be collected.
Practitioner takeaway: The strongest onboarding design is usually the one that proves the smallest fact necessary, because lower data collection reduces friction, liability, and misuse without weakening the business decision.
Related resources from NHI Mgmt Group
- Why do wallet-based identity journeys change data minimisation requirements?
- Why does single-method identity verification fail in consumer onboarding?
- How should security teams combine bank-based verification with identity document checks for onboarding at scale?
- Why does selfie-based verification reduce identity fraud in digital onboarding?