When proofing and authorisation are mixed, organisations tend to overgrant access because a verified identity claim is treated as a permission decision. That breaks auditability, weakens policy design, and makes it difficult to explain why a user or organisation was allowed into a specific workflow.
Why Mixing Proofing and Permission Decisions Breaks Wallet Flows
Wallet-based identity proofing establishes that a wallet holder is who they claim to be. Authorisation decides what that holder may do next. When those functions are merged, the proofing event starts to act like a standing access grant, so a strong identity signal can be misread as approval for a business workflow, entitlement, or transaction.
The result is usually policy leakage. Teams encode trust in the identity assertion instead of the access rule, which makes the wallet feel like a universal pass even when the organisation intended a narrow verification step. That creates confusion between who was proved and what they were permitted to do.
A cleaner model keeps the wallet as a trust input and pushes the permission decision into a separate policy layer. That separation matters because proofing evidence can be high assurance without being sufficient for every action, especially where step-up checks, contextual conditions, or role-based restrictions should still apply.
Where Auditability and Policy Design Start to Fail
Once proofing and authorisation are blended, the audit trail often stops answering the most important question: why was access granted? Instead of recording a decision based on policy, the record shows that an identity was verified, which is a weaker explanation and much harder to defend during review, dispute handling, or access recertification.
Policy design also becomes brittle. If every verified wallet claim can be interpreted as permission, controls drift from explicit rules toward implicit trust in the credential or presentation layer. That makes it difficult to apply least privilege consistently, because the system is no longer evaluating the specific action, resource, or workflow state on its own terms.
For digital identity wallets, the distinction is especially important because the same wallet can support multiple relying parties and multiple use cases. A proofed identity is not automatically a mandate to enter a regulated process, obtain a benefit, or assume an entitlement without a separate authorisation decision.
Why the Misdesign Creates Overgranting and Weak Explanations
When organisations collapse proofing into permissioning, they tend to overgrant access because the safest-seeming identity event gets reused as a control shortcut. That can make onboarding faster, but it also increases the blast radius of a single trust decision and makes exceptions harder to spot.
The control failure is usually structural rather than technical. The proofing layer was built to answer “is this wallet holder credible enough to trust for this identity claim?” while the authorisation layer must answer “is this actor allowed to do this specific thing now?” If those questions share the same decision point, the organisation loses separation of duties between identity assurance and access governance.
At the workflow level, that weakens explainability. A reviewer should be able to trace a permission back to a rule, condition, or policy decision, not only to the fact that a wallet was accepted. Without that separation, challenge cases, appeals, and internal control reviews become much harder to justify.
Risk and Threat Considerations
Mixing proofing and authorisation increases the chance that one high-assurance identity event unlocks broader access than intended. It also creates a convenient abuse path if a wallet presentation is accepted as proof of entitlement rather than just proof of identity, because the resulting overgrant can persist across workflows and reviews.
Failure mechanism: The system uses identity assurance as a proxy for permission, so a verified wallet claim bypasses the separate policy decision that should constrain scope, time, and purpose.
Impact: Excess access, weak audit trails, and difficult-to-defend authorisation outcomes, especially where regulators, auditors, or counterparties need a clear basis for each decision.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IAL — Identity Assurance Levels | Wallet proofing hinges on identity assurance, distinct from permission. |
| Recommendation — Separate identity assurance from access decisions before granting workflow access. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Merging proofing and authorisation tends to overgrant access beyond need. |
| AU-2 — Audit Events | The issue weakens the ability to explain why access was allowed. | |
| Recommendation — Require the smallest entitlement set that covers the specific action. Log the policy basis for each access decision, not only the identity proof. | ||
| OWASP ASVS | V8 — Authorization | The core failure is confusing authentication or proofing with authorisation. |
| Recommendation — Enforce a separate authorisation check for every protected action. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control must be based on explicit policy, not proofing alone. |
| Recommendation — Define access rules independently from identity verification steps. | ||
Practitioner Guidance
What to verify: Confirm that the wallet proofing event and the access decision are produced by different control points, with the authorisation layer checking action, context, and policy separately from identity assurance. If one artefact is doing both jobs, the model is too coarse.
Decision rule: If a wallet claim is being used to approve a workflow, require an explicit policy decision or entitlement check before the action is allowed. Treat proofing as an input to trust, not as permission in itself.
What good looks like: An auditor can point to the exact rule or policy condition that authorised the action, while the wallet only explains how the identity was established. That separation is the practical sign that the control design is sound.
Practitioner takeaway: Keep proofing and authorisation independent, because the moment identity assurance is allowed to stand in for permission, overgranting becomes a design feature instead of a failure.