Yes. User authentication proves control of the wallet, but it does not prove the requester is entitled to receive the data. A mature programme must enforce both sides of the transaction, with authentication for the holder and registry-backed authorisation for the relying party.
Why the Two Sides of Digital Identity Must Stay Separate
digital identity flows are easiest to get wrong when a programme treats login as the whole trust decision. Authentication answers one question: who controls the wallet or credential right now. Authorisation answers a different question: is this relying party entitled to receive this specific data or assertion. Keeping those decisions separate reduces over-disclosure and makes policy easier to audit.
This separation matters because the same authenticated holder may interact with multiple relying parties, each with different entitlement, purpose, and data-minimisation rules. A single proof of control should not become a blanket permit to release every attribute, claim, or credential fragment. In practice, the trust model needs both a strong user proof and an independent entitlement check.
For wallet-based and verifiable-credential use cases, the relying party layer is where programme design often becomes either precise or sloppy. The wallet may prove possession, but the programme still has to decide whether the verifier is allowed to ask for the attribute, whether the request is in scope, and whether the presentation satisfies the policy for that transaction. That is why Digital Identity, eID and Identity Wallets Guide is useful context for the wallet side of the trust boundary.
Where Authentication Ends and Relying Party Authorisation Begins
The cleanest design pattern is to treat the holder and the verifier as separate policy domains. Authentication establishes that the person or device controlling the wallet is real enough to present a credential. Authorisation then governs whether the relying party can request, receive, or rely on that credential for a defined purpose, transaction type, or assurance level.
That distinction is not academic. If the two are merged, teams tend to over-trust possession of a wallet or token and under-specify the relying party’s rights. The result is often excessive attribute release, weak consent logic, and brittle integration decisions that are hard to unwind later. A programme should be able to say, in policy terms, that a valid authentication is necessary but not sufficient for disclosure.
A mature identity programme also needs an operating model for who owns each control plane. Authentication policy normally sits with the identity or wallet issuer, while relying party entitlement logic sits with registry, trust framework, or federation governance. Keeping those responsibilities distinct prevents the common failure mode where the verifier’s business need quietly overrides the assurance and privacy rules attached to the credential.
What Good Practice Looks Like in Transactional Identity Flows
Good practice starts with explicit transaction boundaries. The programme should know which attributes can be released, under what proofing and assurance conditions, and to which classes of relying party. That means the authorisation decision must be capable of saying no, even when the wallet proof is valid, if the verifier is not approved for the requested data or transaction.
It also means the trust framework needs to support selective disclosure and purpose limitation, not just login success. If the architecture cannot express “authenticated holder, unauthorised verifier,” then the programme is functionally collapsing two separate controls into one. In regulated or federated ecosystems, that usually becomes a governance problem as much as a technical one.
For programme teams comparing standards and operating patterns, eIDAS 2.0, the EU Digital Identity Framework is a strong reference point because it frames wallet use, trust, and cross-border identity verification as related but distinct obligations.
Risk and Threat Considerations
The main risk is over-authorisation, where a validly authenticated user becomes a shortcut for releasing data to a relying party that has not been properly vetted. That creates privacy exposure, policy drift, and downstream abuse of claims, especially when the same assertion can be reused across services or jurisdictions.
Failure mechanism: The programme accepts wallet authentication as proof that the relying party may process the data, so entitlement checks, registry validation, or transaction-specific policy are skipped or weakened.
Impact: Sensitive attributes may be disclosed to an unentitled verifier, creating data-minimisation failures, trust-framework breaches, and a wider blast radius if the relying party is compromised or misused.
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, OWASP ASVS and NIST SP 800-63 set the technical controls, while EU AI Act defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | Digital identity wallets and relying parties involve external user authentication and entitlement decisions. |
| AC-3 — Access Enforcement | Relying party authorisation must enforce who may receive specific identity assertions. | |
| Recommendation — Require separate authentication and access checks for external users before releasing identity data. Enforce policy that limits which relying parties can obtain each credential or attribute. | ||
| OWASP ASVS | V8 — Authorization | The question centres on separating authentication from authorisation in identity flows. |
| V10 — OAuth and OIDC | Digital identity integrations often depend on federation and token-based trust decisions. | |
| Recommendation — Verify that authenticated identity does not automatically confer access to data or functions. Design federation flows so relying party rights are checked independently of sign-in success. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Digital identity wallets and verifier trust align directly with assurance, federation, and authentication guidance. |
| Recommendation — Apply digital identity assurance rules separately from relying party eligibility and disclosure policy. | ||
| EU AI Act | European Union Artificial Intelligence Act | No material alignment with the identity-wallet authorisation split in this question. |
| Recommendation — Omit | ||
Practitioner Guidance
What to verify: Confirm that your architecture can independently answer two questions for every transaction, who authenticated, and who is entitled to receive the data. If those checks are implemented in the same component, test whether either control can fail open without the other.
Decision rule: If a relying party can obtain data solely because the holder authenticated, treat that as a design defect. The relying party should pass a separate registry, policy, or federation check before any attribute release or trust decision is allowed.
Practitioner takeaway: The programme is stronger when authentication proves the holder and authorisation governs the verifier, because separating them is what stops a valid login from becoming an automatic disclosure decision.
Related resources from NHI Mgmt Group
- How should teams separate identity proof from authentication in digital identity programmes?
- Why do identity programmes struggle when compliance, user experience, and infrastructure complexity are treated as separate problems?
- What are the signs that legacy authentication is no longer fit for digital identity programmes?
- How should teams design third-party authentication so partners can sign in without creating separate identity sprawl?