Eudi wallets and oauth 2.0: what verifiers must change

At a glance

What this is: This analysis explains why EUDI wallets make verifier identity, credential presentation, and OAuth 2.0 architecture central to enterprise identity design.

Why it matters: IAM teams need to treat wallets as a change in trust boundaries, because the verifier becomes part of the identity model across NHI, agentic, and human-facing workflows.

👉 Read Curity's analysis of EUDI wallets, verifier identity, and OAuth 2.0

Context

EUDI wallets are a digital credential model that lets users present signed attributes to a verifier while selectively disclosing only what is needed. For identity teams, the important change is not just user convenience. It is that verifier identity, token issuance, and authorization design now have to work together across wallet-mediated flows and enterprise APIs.

The current gap is architectural: wallets can handle authentication and credential presentation, but they do not replace the need for OAuth 2.0 authorization, access tokens, and policy-based control of APIs. That means IAM, IGA, and API security teams must decide where wallet trust ends and where enterprise authorization begins.

Key questions

Q: How should security teams integrate EUDI wallets with existing OAuth 2.0 architectures?

A: Security teams should place wallet verification ahead of token issuance and keep OAuth 2.0 as the authorization layer. The wallet proves attributes or identity claims, while the authorization server converts approved claims into scoped access tokens. That separation preserves API governance, avoids confusing authentication with permission, and keeps policy changes centralised.

Q: Why do digital credentials not replace authorization controls in enterprise systems?

A: Digital credentials prove something about the subject, but they do not by themselves decide what that subject can do. Enterprises still need access tokens, audience restrictions, scopes, and policy checks to protect APIs and resources. If teams treat wallet presentation as authorization, they create an implicit trust path with no resource-level control.

Q: What breaks when verifier identity is not governed in wallet-based flows?

A: Wallet-based flows break when the verifier is treated as a generic application instead of a trusted identity actor. Users may then disclose attributes to parties that have not been registered, contextualised, or restricted. That weakens privacy, undermines anti-tracking design, and can turn selective disclosure into uncontrolled disclosure.

Q: How can organisations decide where wallet logic should live in the identity stack?

A: Wallet logic should live in the identity layer, ideally in the authorization server, not inside individual apps. That approach lets teams manage protocol changes, attribute mapping, and trust rules in one place. It also reduces implementation drift across applications and makes later wallet standards easier to adopt.

Technical breakdown

How EUDI wallet presentation changes verifier identity

EUDI wallets rely on cryptographically signed digital credentials, often presented through OpenID4VP, to share selected attributes with a verifier. The verifier is not a passive recipient. It must be a trusted party with its own cryptographic identity, registration context, and attribute consumption rules. This differs from traditional SSO because the wallet is carrying evidence, not merely asserting a login event. Selective disclosure and anti-tracking properties reduce overcollection, but they also make verifier design more explicit. The enterprise must be able to prove who it is before the wallet releases meaningful attributes. Practical implication: treat verifier identity as a controlled trust object, not just an application integration.

Practical implication: register and govern verifier identities separately from application access, because wallet trust depends on the verifier itself.

Why digital credentials do not replace OAuth 2.0 authorization

Digital credentials primarily support authentication and attribute presentation, not authorization. After a wallet verifies identity or attribute claims, the enterprise still needs OAuth 2.0 to issue access tokens and enforce resource-level decisions. Curity's framing is important here because it preserves the separation between proof of identity and permission to use an API. Wallets can feed verified attributes into the authorization server, but the server remains the control point for access scope, audience, and policy. Without that boundary, organizations risk turning credential presentation into an implicit authorization mechanism, which is a common design error. Practical implication: keep wallets upstream of authorization and let OAuth 2.0 own API permissioning.

Practical implication: preserve OAuth 2.0 as the authorization layer, and do not let wallet presentation become a shortcut to API access.

What wallet-ready architecture means for enterprise APIs

A wallet-ready architecture externalizes credential integration complexity into the identity layer instead of scattering it across applications. In practice, the authorization server consumes wallet-derived attributes, then issues enterprise tokens that applications and APIs already know how to validate. That keeps policy changes out of code paths and makes wallet adoption easier to evolve over time. It also supports a cleaner boundary between citizen identity, business identity, and service access. The same pattern matters when wallets are used in human journeys, NHI-supported workflows, or federated service interactions, because the enterprise still needs stable access-token semantics. Practical implication: centralize wallet exchange logic in the authorization server so application teams do not own credential protocol churn.

Practical implication: centralize wallet integration in the authorization server to avoid hard-coding credential logic into applications.

NHI Mgmt Group analysis

Wallets create a verifier identity problem before they create a user experience problem. The article shows that the enterprise cannot treat wallet support as a front-end convenience layer, because the verifier must itself be cryptographically trusted before any attributes are released. That moves identity governance upstream into registration, trust establishment, and verifier accountability. The implication is that wallet adoption forces enterprises to govern who can ask for attributes, not just who can present them.

Digital credentials do not collapse authentication and authorization into one control. Wallets provide high-assurance attribute presentation, but the article correctly separates that from OAuth 2.0 access-token issuance and API authorization. This matters because many identity programmes still blur proof of identity with permission to act. The implication is that teams must preserve a hard boundary between verified identity claims and resource access decisions.

Wallet-ready architecture is an identity abstraction strategy, not just a standards integration exercise. The strongest operational pattern in the article is to keep wallet exchange logic in the authorization server so applications do not absorb protocol churn. That aligns with NIST Cybersecurity Framework 2.0 thinking around control centralisation and with zero-trust design principles. The implication is that identity teams should design for protocol change at the edge and policy stability in the core.

Cross-border wallet adoption will expose governance inconsistency faster than it exposes technical weakness. The article shows that member states, verifiers, and issuers each need registration, context, and trust rules, which means policy alignment becomes the limiting factor. Different national and sector implementations will make interoperability a governance challenge, not just a standards challenge. The implication is that practitioners should expect policy friction to shape rollout speed more than cryptography does.

From our research:

• 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• For a broader control lens, OWASP Non-Human Identity Top 10 helps teams map wallet-adjacent identity risk to NHI governance and API access control.

What this signals

Verifier identity will become a governance object, not just an implementation detail. As wallet adoption expands, identity teams will need to decide which parties are trusted to request attributes and under what registration conditions. That makes verifier lifecycle management part of IAM architecture, especially where citizen and business wallets feed API access or supplier onboarding.

Anti-tracking credentials change the evidentiary model for identity teams. Distinct keys and identifiers make cross-service correlation harder by design, which is good for privacy but harder for audit teams used to stable identifiers. The practical response is to anchor evidence in the authorization server and registration records, not in wallet-held identifiers alone.

Wallet integration should follow a centralised identity pattern, not app-by-app experimentation. Keeping credential exchange in the core identity layer protects application teams from protocol churn and gives governance teams one place to update policy. The same design instinct that reduces NHI secret sprawl also reduces wallet implementation drift across portfolios.

For practitioners

• Separate verifier governance from application onboarding Define who can act as a verifier, what attributes they may request, and which registration evidence they must supply before any wallet interaction is enabled.
• Keep OAuth 2.0 as the authorization boundary Use wallet-verified attributes as input to token issuance, but continue to enforce audience, scope, and policy decisions in the authorization server.
• Externalize wallet protocol handling from apps Route OpenID4VCI and OpenID4VP handling through the identity layer so application and API teams do not carry credential exchange complexity in code.
• Map wallet attributes to least-privilege API claims Translate only the minimum verified attributes into access tokens and avoid copying raw credential contents into downstream services.
• Review trust boundaries for citizen and business wallets Treat EUDI wallets and business wallets as distinct trust objects with different issuance, verification, and attribute-consumption rules.

Key takeaways

• EUDI wallets improve attribute presentation, but they do not replace enterprise authorization.
• Verifier identity is now part of the trust model, which means registration and governance matter as much as cryptography.
• The safest rollout pattern centralises wallet exchange in the identity layer and leaves API permissioning to OAuth 2.0.

Key terms

• Verifier Identity: The verifier identity is the cryptographic and governance identity of the party asking a wallet user for attributes. It matters because a wallet should only disclose data to a trusted, registered requester, and that trust must be explicit rather than assumed from an application name or network location.
• Digital Credential: A digital credential is a signed set of claims that can be presented by a wallet to prove an identity attribute or entitlement. In wallet ecosystems, the credential is used for authentication or evidence, while downstream systems still need policy and authorization logic to decide access.
• Selective Disclosure: Selective disclosure is the practice of revealing only the minimum attributes needed for a transaction. It reduces unnecessary data sharing, but it also shifts governance to the verifier, because the recipient must be trusted to request and consume only what is justified.
• Wallet-Ready Architecture: Wallet-ready architecture is an identity design that centralises credential exchange and attribute mapping in the identity layer instead of embedding it in applications. It helps organisations absorb new wallet standards without rewriting every app when protocols or trust rules change.

What's in the full article

Curity's full article covers the operational detail this post intentionally leaves for the source:

• Protocol flow detail for OpenID4VCI and OpenID4VP issuance and presentation.
• How the authorization server consumes wallet attributes and converts them into access token claims.
• Examples of wallet-ready API architecture that keeps integration complexity out of application code.
• The verifier registration model for enterprises that want to consume wallet attributes.

👉 Curity's full article covers wallet protocols, verifier registration, and API integration detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.