Broad information sharing increases exposure, creates unnecessary privacy risk, and can make compliance harder across different regions. A proof-based model limits disclosure to the minimum needed for a transaction or policy decision. That approach reduces data handling burden and narrows the attack surface for identity data. Teams should decide what must be known, what can be proved, and what should never be shared.
Why broad disclosure weakens wallet-based identity
Wallet-based identity is strongest when it supports selective disclosure, not when it turns every interaction into a data dump. If a wallet routinely shares more than the transaction requires, you lose the main privacy advantage of the model and increase the amount of identity data exposed to relying parties, processors, and logs. That creates more places for misuse, retention, and secondary access.
Broad disclosure also makes the trust decision less precise. A verifier that receives full identity data is forced to protect and interpret information it may not need, while the holder loses control over how widely the data travels. For identity wallets, the design question is not simply “can this be shared?” but “should this be proved instead?”
That distinction matters because proof-based access reduces the volume of personal and attribute data in motion. A well-designed wallet can confirm age, residency, membership, authorization, or possession of an entitlement without exposing the underlying source data. The less the verifier learns, the less there is to store, correlate, or leak, and the smaller the privacy and compliance footprint becomes.
What proof-based access changes in practice
Proof-based access changes the control model from disclosure to assertion. Instead of sending raw documents or broad profile data, the wallet presents a verifiable proof that a rule has been satisfied. This is the logic behind selective disclosure in modern identity wallet designs, including the Digital Identity, eID and Identity Wallets Guide, where the object is to reveal only what is necessary for the relying party’s decision.
That model is a better fit for access decisions that can be answered with yes, no, or limited attributes. If the only real question is whether the user is eligible, over-sharing full identity data is usually a design failure. Proof-based access lets teams separate identity assurance from data exposure, which is especially valuable when different jurisdictions, business lines, or vendors have different data-handling expectations.
It also changes how you think about trust. A proof is only useful if the verifier can rely on its integrity, freshness, and audience. That is why proof-based flows often pair with tighter policy decisions and stricter relying-party controls, rather than open-ended data exchange. For access models, the safest pattern is often: prove the minimum, then release the minimum.
Where the risk shows up for teams and users
Broad sharing creates risk in three places: privacy, security, and compliance. Privacy risk grows because more identifiers and attributes can be combined across systems. Security risk grows because larger data sets create richer targets for interception, replay, correlation, and downstream abuse. Compliance risk grows because many regimes expect data minimisation and purpose limitation, not default over-disclosure.
In wallet-based identity, this becomes even more visible when organisations try to use the wallet as a convenience layer instead of a policy layer. A wallet that reveals full identity every time may feel simpler, but it also weakens the business case for using the wallet at all. The better pattern is to align the disclosure rule to the transaction rule, then validate that each requested attribute is actually needed before release.
That is why proof-based access is closely related to least disclosure and selective disclosure, even when the implementation is technically different from a traditional login flow. The wallet should answer the access question without turning into a general-purpose identity broadcast mechanism. For a deeper view of how selective disclosure and reusable identity patterns are expected to work, see Digital Identity, eID and Identity Wallets Guide and the eIDAS 2.0 framework at eIDAS 2.0, the EU Digital Identity Framework.
Risk and Threat Considerations
Broad information sharing increases the attack surface of the identity flow because more sensitive data is exposed to more parties, systems, and logs. It also increases the chance that a verifier or intermediary retains data it does not need, which makes later compromise, correlation, or misuse more damaging than it should be.
Failure mechanism: The access decision is made with overbroad disclosure instead of a proof, so the verifier receives unnecessary identity material, stores it, or forwards it into other systems where it can be replayed, correlated, or mishandled.
Impact: The organisation inherits avoidable privacy exposure, greater breach impact, and harder compliance across jurisdictions because the identity transaction now carries more data than the decision truly requires.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Wallet identity still depends on authenticating the holder before disclosure. |
| IA-8 — Identification and Authentication (Non-Organizational Users) | Wallet use by customers or external parties needs controlled proof and access assurance. | |
| AC-6 — Least Privilege | The page’s core issue is avoiding unnecessary disclosure and access. | |
| Recommendation — Require strong holder authentication before any wallet proof is accepted. Apply external-user assurance controls before accepting wallet assertions. Limit each wallet transaction to the minimum attributes required. | ||
| OWASP API Security Top 10 | API3 — Broken Object Property Level Authorization | Over-sharing wallet attributes is analogous to exposing properties beyond what a decision needs. |
| Recommendation — Restrict exposed attributes to the exact properties required for the transaction. | ||
Practitioner Guidance
What to prioritise: Define the minimum decision set before you define the wallet payload. If the business question can be answered with an attribute, eligibility claim, or cryptographic proof, do not ask for the full underlying identity record.
What to verify: Check that each requested field is directly tied to a decision rule, retention need, or legal obligation. If you cannot explain why a verifier needs the raw value, that field is a candidate for removal or proof-based substitution.
Decision rule: If the wallet is being used for repeated access, favour proofs that are bounded to the relying party and the transaction context. If the relying party wants reusable identity data, treat that as a higher-risk design choice that needs explicit justification.
Practitioner takeaway: The safest wallet design is not the one that shares the most, it is the one that can prove enough to authorise action while keeping unnecessary identity data out of circulation.
Related resources from NHI Mgmt Group
- What breaks when teams use shared vault secrets for production access instead of identity-based access?
- Why do AI workloads need least-privileged identity controls instead of broad standing access?
- Why do wallet based identity programmes need both policy alignment and technical integration before broad rollout?
- What breaks when model access is managed with broad allowlists instead of policy-based controls?
