Eudi wallets and oauth 2.0: what verifiers must change

At a glance

What this is: This is Curity's analysis of how EUDI wallets change verifier identity, digital credential presentation, and OAuth 2.0 architecture for enterprises.

Why it matters: It matters because IAM teams will need to treat wallet verification as a governed identity pattern, with separate controls for authentication, authorization, APIs, and external verifier trust.

Context

EUDI wallets are a digital identity pattern in which a user presents cryptographically signed credentials to a verifier, while selectively disclosing only the attributes needed for a transaction. The identity governance question is not whether wallets exist, but how enterprises adapt verifier identity, token design, and API control when authentication and authorization are separated.

For IAM practitioners, the key shift is that wallet-based verification can reduce manual KYC friction, but it does not remove the need for an enterprise-controlled authorization architecture. The verifier must be trusted, registered, and able to consume wallet attributes without collapsing them directly into access decisions.

The article also shows that wallet adoption is not limited to a single jurisdiction. That makes interoperability, verifier registration, and privacy-preserving attribute handling a broader identity architecture issue rather than a regional experiment.

Key questions

Q: How should security teams govern verifier identity in EUDI wallet flows?

A: Treat the verifier as a registered trust anchor, not just an application endpoint. Security teams should define who may request wallet attributes, what purpose they declare, and how that trust is recorded, reviewed, and revoked when the relationship changes.

Q: Why do EUDI wallets not replace OAuth 2.0 for enterprise access control?

A: Wallets can authenticate a user or prove attributes, but they do not issue the enterprise access token that protects APIs. OAuth 2.0 remains the layer where scopes, audiences, and policy decisions are controlled, so authorization must stay inside the enterprise boundary.

Q: What are the main governance risks in wallet-based identity flows?

A: The main risks are weak issuer trust, poor revocation handling, inconsistent assurance levels, and unclear consent records. If those controls are not explicit, selective disclosure can create uncertainty about what the relying party is allowed to trust, which turns portability into fragmented decision-making instead of stronger governance.

Q: How should IAM teams handle privacy when wallets use distinct identifiers per verifier?

A: They should stop assuming that the same user identifier will be available across services. Instead, they need attribute-based governance, minimal logging, and carefully designed correlation rules that do not depend on persistent cross-service tracking.

Technical breakdown

Why verifier identity becomes a control point in wallet flows

In wallet-based identity flows, the verifier is the party asking for user attributes and must be known to the wallet before trust can be established. That means the verifier itself becomes part of the security model, not just the application consuming data. Enterprises therefore need a cryptographic identity and a registration model that lets wallets distinguish legitimate relying parties from arbitrary clients. The control problem is less about proving the user and more about proving who is allowed to ask for credentials and under what declared purpose.

Practical implication: Treat verifier registration and trust establishment as part of identity governance, not as an application afterthought.

How OAuth 2.0 remains the authorization layer for EUDI wallets

Digital credentials from wallets are primarily for authentication and attribute presentation. OAuth 2.0 still has to issue the access token that authorizes calls to protected APIs, which keeps token scope, claims, and audience control inside the enterprise boundary. OpenID4VCI and OpenID4VP can integrate with OAuth 2.0, but they do not replace it. The architecture therefore separates externally issued wallet credentials from internally controlled authorization decisions, which is the right boundary for least privilege and API policy.

Practical implication: Design wallet integration so external credentials feed authorization input, while your authorization server still mints and governs access tokens.

Why anti-tracking wallets change enterprise data handling

EUDI wallets use distinct keys and identifiers per verifier, which makes cross-service tracking cryptographically infeasible by design. That is a privacy feature, but it also changes how enterprises think about correlation, logging, and repeated user verification across services. The same design that protects user privacy limits the organisation's ability to infer identity across transactions without explicit consent and purpose. In practice, this makes data minimization and purpose limitation architectural concerns, not only legal ones.

Practical implication: Review logging, correlation, and attribute collection practices so they do not depend on persistent cross-service identity links.

NHI Mgmt Group analysis

Verifier identity is becoming the new trust boundary in wallet ecosystems: the hard problem is no longer only whether a user can present a valid credential, but whether the relying party itself can be trusted by the wallet. That shifts governance from user onboarding alone to verifier registration, purpose declaration, and cryptographic identity assurance. Practitioners should treat verifier trust as a first-class identity control, not an integration detail.

OAuth 2.0 remains the enterprise authorization anchor even when the credential arrives from a wallet: EUDI credentials can prove attributes, but they do not replace the need for access tokens, scope design, and API enforcement. This preserves the separation between authentication and authorization that modern IAM architectures depend on. The implication is clear: wallet support belongs inside the authorization architecture, not beside it.

Anti-tracking by design creates an identity correlation ceiling: if each verifier receives distinct keys and identifiers, then persistent cross-service tracking is structurally constrained. That is a privacy gain, but it also means enterprise architectures must stop assuming stable identifiers will be available for downstream governance or analytics. Pracititioners need to design for attribute-based decisions, not identity reuse.

Wallet adoption is forcing a boundary reset between federation and local control: credential presentation can be federated, but access control still has to be local, policy-driven, and auditable. This makes the verifier role, not the wallet app, the governance object that enterprises must inventory and review. The practical conclusion is that wallet readiness is an IAM programme issue, not only a customer experience issue.

Verifier registration will become a lifecycle problem, not a one-time technical setup: once organisations can issue or verify credentials, they inherit ongoing obligations to explain attribute use, keep purpose statements current, and maintain trust with member-state ecosystems. That is classic identity lifecycle governance applied to a new actor type. Teams that ignore lifecycle management will end up with stale verifier trust and brittle wallet integrations.

What this signals

Verifier trust is now part of identity architecture: teams that want wallet support need a governed model for who can ask for attributes, how those parties are identified, and how that trust is revoked if the relationship changes. This is where verifier registration, lifecycle control, and federation policy converge.

Wallet integration should preserve the enterprise authorization boundary: external credentials can supply high-assurance claims, but access tokens, scopes, and API policy still need to be issued and enforced locally. That distinction keeps authentication separate from authorization and prevents uncontrolled claim-to-access shortcuts.

For practitioners

• Define the verifier trust model Inventory every service that will ask wallets for attributes, then decide how each verifier is identified, registered, and authorised to request data.
• Keep OAuth 2.0 as the authorization layer Use wallet credentials for authentication and claims intake, but continue to mint and govern enterprise access tokens inside your authorization server.
• Separate attribute presentation from API access Do not map wallet attributes directly to resource access. Translate verified claims into policy-controlled token attributes before APIs evaluate them.
• Review privacy and correlation assumptions Remove dependencies on persistent cross-service identifiers where wallets are expected to use distinct keys and identifiers for each verifier.
• Prepare for issuer and verifier lifecycle governance Document who can issue credentials, who can verify them, and how registration, purpose statements, and trust status will be maintained over time.

Key takeaways

• EUDI wallets move the verifier role into the centre of enterprise identity design, because the wallet must trust the party asking for attributes.
• The architecture still requires OAuth 2.0 for authorization, so wallet credentials do not replace enterprise token issuance or API policy.
• Privacy-preserving presentation changes how teams handle correlation, logging, and lifecycle governance, especially when verifier trust must be maintained over time.

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.
• Selective Disclosure: Selective disclosure is the practice of sharing only the identity attributes needed for a specific decision. In credential-based systems, it reduces oversharing, lowers retention burden, and limits exposure when a verifier does not need the full record to make a trustworthy judgment.
• Wallet-Ready Authorization: Wallet-ready authorization is an enterprise design in which external wallet credentials inform, but do not replace, local access decisions. The organisation still issues its own access tokens and enforces scope, policy, and API control inside its boundary.
• Attribute-Based Identity Verification: A verification approach that confirms specific claims such as age, address, or residency rather than exposing full identity documents. It improves privacy and data minimisation, but governance must still prove that each attribute is trusted, current, and sufficient for the regulated decision being made.

Deepen your knowledge

NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.