Digital IDs are becoming mainstream as wallets and browsers converge

At a glance

What this is: Digital credentials are moving from pilots to mainstream infrastructure as major platforms and the EU align on wallet-based identity presentation.

Why it matters: IAM, IGA, and security teams need to plan for claim-based verification flows that sit alongside passkeys, change data handling, and shift trust boundaries outside the core identity stack.

👉 Read Authsignal's analysis of digital IDs going mainstream in 2026

Context

Digital credentials are verifiable identity claims stored in a wallet and presented selectively to a relying party. The shift matters because identity verification is moving out of static form capture and into cryptographically mediated presentation flows that reduce unnecessary data sharing while increasing the importance of wallet, browser, and verifier trust.

The primary governance question is no longer whether wallets will exist, but how enterprises will accept them, validate them, and govern what data is disclosed. For IAM programmes, this affects onboarding, age verification, KYC flows, consumer identity journeys, and any process that currently assumes the organisation will directly collect and store identity attributes.

Key questions

Q: How should security teams govern digital credential verification in customer journeys?

A: Start by defining the exact claim needed for each journey, then bind that request to a trusted browser and wallet flow. Keep authentication, identity proof, and data retention separate. The goal is to verify eligibility with the least possible disclosure, while preserving clear ownership for the relying party, not the wallet provider.

Q: Why do digital credentials change privacy and IAM design at the same time?

A: Because they move identity proof from central data collection into selective disclosure. That reduces unnecessary storage, but it also forces IAM teams to decide what the verifier may ask for, what it may retain, and how much assurance is sufficient for the transaction.

Q: What breaks when organisations ask for full identity data instead of a single claim?

A: They lose the main privacy and security advantage of digital credentials. Over-asking increases data exposure, expands retention obligations, and creates pressure to build traditional identity stores around a use case that should have required only a narrow proof.

Q: Who is accountable when a wallet-based verification flow is used incorrectly?

A: The relying party remains accountable for the verification design, data handling, and business decision that follows. Wallets and browsers can transport proofs, but the organisation requesting them must justify the claim set, validate the response, and govern what happens next.

Technical breakdown

How the Digital Credentials API changes identity presentation

The W3C Digital Credentials API acts as a browser-mediated handoff layer between a verifier and one or more wallet apps. A website requests a credential type, the browser shows eligible wallets, the user selects one, and the chosen wallet returns a cryptographically verifiable response. The API is protocol-agnostic at the browser layer, which means OID4VP and mdoc can coexist without forcing each relying party to hard-code one presentation path. That separation is what makes broad ecosystem adoption possible, but it also shifts control to the browser, wallet registry, and origin validation flow.

Practical implication: identity teams should treat browser-mediated credential presentation as a new verification surface, not just a UX feature.

Selective disclosure and on-device storage for digital IDs

Selective disclosure lets the holder present only the attribute needed for a transaction, such as age or residency, instead of a full identity record. In the model described here, credentials are stored encrypted on-device, which reduces server-side custody but makes device integrity, wallet trust, and revocation handling central concerns. This is a different governance pattern from traditional account authentication because the verifier receives proof of a claim, not a direct database lookup. The security model depends on minimal disclosure working reliably across issuers, wallets, and verifiers.

Practical implication: teams should define which identity attributes they truly need before accepting wallet-based verification.

Passkeys and digital credentials solve different identity problems

Passkeys prove control of an account, while digital credentials prove something about the person or their eligibility. That distinction matters because many organisations are trying to use authentication tooling to solve verification problems that belong to a separate trust layer. In practice, the two mechanisms complement each other: passkeys can establish the session, then a digital credential can satisfy a higher-assurance claim for age, status, or jurisdiction. Confusing those roles leads to over-collection, weak assurance, or unnecessary re-verification.

Practical implication: architecture teams should model authentication and attribute verification as separate controls with separate assurance requirements.

Threat narrative

Attacker objective: The attacker objective is to induce over-disclosure, weak verification, or misplaced trust in a supposedly privacy-preserving identity flow.

1. Entry occurs when a relying party accepts digital identity claims from a wallet without validating the browser-mediated request path, origin, and credential type rigorously enough for the use case. Escalation follows when overly broad disclosure requests or weak verifier logic let a user present more identity data than the transaction requires. Impact appears when organisations store, process, or trust more identity data than necessary, increasing exposure and reducing the benefits of selective disclosure.

Breaches seen in the wild

• New York Times breach — New York Times source code and credentials exposed via GitHub.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Digital credentials create a governance shift, not just a new login method. The important change is that identity proof becomes a portable claim, validated through wallets and browsers instead of direct collection into every application. That changes custody, assurance, and consent boundaries for IAM programmes. Teams that treat this as a front-end enhancement will miss the control changes underneath it.

Selective disclosure is the real security value, but only if verifiers stop over-asking. The architecture works when a service requests the minimum attribute set needed for the transaction. If relying parties demand full identity payloads by default, the model collapses back into over-collection and weak privacy controls. Practitioners should treat request design as a governance control, not a product detail.

Browser-mediated credential presentation introduces a new trust broker into identity flows. The browser now helps select the wallet, route the request, and carry the response, so identity teams need to think about origin validation and presentation flow integrity. This is especially important for consumer and regulated journeys where phishing resistance and claim integrity are now intertwined.

Claim-based verification will force IAM and IGA teams to separate identity proof from account proof. Passkeys establish control of the account, while digital credentials establish facts about the person or eligibility condition. That separation should sharpen policy design, reduce data retention, and prevent organisations from using one mechanism to compensate for gaps in the other.

Digital ID adoption will expose verifier immaturity long before it exposes wallet immaturity. The ecosystem can only scale when relying parties know what they are asking for, why they are asking for it, and how long they need to retain the result. The next governance problem is not issuance. It is verifier discipline, and teams should prepare for it now.

From our research:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• For a broader view of identity risk across non-human and human access paths, see Ultimate Guide to NHIs , The NHI Market.

What this signals

The operational signal for IAM teams is that verification is fragmenting into reusable claim presentation, and that changes how customer identity programmes should be measured. As wallet-based flows expand, teams will need explicit policy on which claims are acceptable, how they are logged, and whether the verifier can prove why a claim was requested in the first place.

Claim request discipline: the next control gap will be over-requesting, not just weak authentication. Organisations that do not standardise minimum-claim policies will recreate the same data-harvesting patterns wallet ecosystems were designed to reduce, and that will show up in retention, consent, and audit findings.

For practitioners

• Define attribute-minimisation rules for verification flows Map every digital ID use case to the minimum claim set needed for the decision. Reject request designs that ask for full identity records when a single attribute, such as age or residency, is sufficient.
• Separate authentication from identity verification in architecture reviews Treat passkeys as account authentication and digital credentials as claim verification. Document where each control begins and ends so developers do not substitute one for the other.
• Validate wallet and browser trust assumptions Review how the browser, wallet selection process, and origin validation behave in each supported platform. Pay special attention to fallback paths, user prompting, and cross-device flows.
• Update retention and consent policies for presented claims Store only the verification outcome and retention metadata that the business process requires. If the organisation does not need the underlying identity attribute after verification, do not keep it.

Key takeaways

• Digital credentials move identity verification into selective, cryptographic claim presentation rather than broad data collection.
• The main governance challenge is verifier discipline, because requesting too much data erodes the privacy and security benefit of the model.
• IAM teams should separate authentication, claim verification, and retention policy now, before wallet-based flows become routine.

Key terms

• Digital Credential: A digital credential is a cryptographically verifiable statement about a person or attribute that can be presented from a wallet. It is not the same as an account login. In practice it shifts identity proof toward selective disclosure and away from collecting and storing raw personal data in every relying party system.
• Selective Disclosure: Selective disclosure is the ability to reveal only the specific attribute needed for a transaction, such as age or residency, rather than a full identity record. It reduces unnecessary data exposure, but it only works when the verifier asks for the minimum claim set and the wallet ecosystem supports policy-consistent presentation.
• Digital Credentials API: The Digital Credentials API is a browser interface that lets websites request verifiable credentials from compatible wallets. It standardises presentation across wallets and protocols, so identity teams can think in terms of claims and verification outcomes rather than custom app-to-app handoffs.
• Relying Party: A relying party is the service or application that requests and validates a credential before making an access or transaction decision. Its governance responsibility includes defining the claim request, validating the response, deciding what to retain, and proving that the verification matched the business need.

What's in the full article

Authsignal's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step browser flow details for the Digital Credentials API across Chrome and Safari
• Protocol-level handling of OID4VP, mdoc, and cross-device presentation paths
• Specific rollout examples for Google Wallet, Apple Wallet, and the EU Digital Identity Wallet
• Implementation implications for verifier adoption in age checks, onboarding, and KYC flows

👉 Authsignal's full post covers browser support, wallet flows, and verifier adoption details.

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 building or maturing an IAM programme, it is worth exploring.