Skip to content
Deepak Gupta markCIAM Compass
architecture

Decentralized Identity and Verifiable Credentials: What CIAM Teams Should Know

Updated · 11 min read · By

On this page
  1. Where decentralized identity actually lives in 2026
  2. The technical stack
  3. DID methods and resolution: did:key, did:web, did:pkh
  4. Web3 authentication and how it relates to decentralized identity
  5. The CIAM integration pattern
  6. The specific use cases that pay back today
  7. EUDI Wallet specifically
  8. US state mDL and the consumer-side path
  9. When to wait
  10. Implementation guidance

Key takeaways

  • Decentralized identity in 2026 is mostly government-driven: EUDI Wallet (eIDAS 2.0, mandated by end of 2026), US state mDL programs, education credentials.
  • DIDs and Verifiable Credentials are the W3C-standardized technical substrate. OpenID for Verifiable Presentations (OID4VP) is the protocol that connects wallets to relying parties.
  • The CIAM-side impact is additive, not replacement. RPs accept wallet-presented credentials alongside existing identity proofing. Federated SSO and password infrastructure stay.
  • For B2C with EU users, EUDI Wallet acceptance moves from optional differentiator to compliance requirement through 2027. Plan integration timing.
  • The right framing: not whether decentralized identity is 'the future', but where it produces specific value today (high-friction IDV, regulated workloads, cross-border identity).

Where decentralized identity actually lives in 2026

The honest 2026 landscape:

  • EU: EUDI Wallet rolls out via member-state issuers; mandatory acceptance for very large online platforms and regulated industries by 2027.
  • US: state-by-state mDL deployment, no federal mandate, TSA airport acceptance expanding, growing private-sector acceptance in age-verification contexts.
  • Education / professional credentials: scattered deployment (issuing universities, professional licensing bodies) without standardization on acceptance.
  • Consumer / commercial: largely experimental, opt-in for relying parties; commercial product strategies for "wallet" usage are uneven (Apple Wallet handles mDL but not generalized VC; Microsoft Authenticator has verified ID but limited adoption).

The substrate is mature; the commercial-side adoption is still ramping. Plan integration based on actual user demand and regulatory timeline, not on the philosophy.

The technical stack

The W3C-and-IETF-standardized stack:

DIDs (Decentralized Identifiers, W3C v1.0, 2022). URIs of the form did:method:identifier that resolve to DID Documents containing public keys and service endpoints. The subject controls the DID cryptographically without depending on a central issuer.

Verifiable Credentials (W3C VC Data Model v2.0, W3C Recommendation 15 May 2025). Cryptographically-signed digital credentials with three parties: issuer (signs), holder (stores), verifier (validates). Issuer-to-holder issuance, holder-to-verifier presentation, no callback to issuer at verification time.

SD-JWT VC. The IETF SD-JWT-based format for Verifiable Credentials with selective disclosure. The EUDI Wallet default presentation format.

OpenID for Verifiable Presentations (OID4VP 1.0, final July 2025). The protocol that connects digital wallets to relying parties. Uses OAuth 2.0 / OIDC patterns; RP sends a presentation request, wallet collects user consent and disclosure, returns the verifiable presentation.

OpenID for Verifiable Credential Issuance (OID4VCI, draft). The corollary protocol for issuers to deliver credentials to wallets.

For CIAM, OID4VP is the integration point. Existing OIDC infrastructure handles most of the request/response shape; the verifiable-presentation handling is the new code.

DID methods and resolution: did:key, did:web, did:pkh

A DID has the form did:<method>:<identifier>. The method decides how the identifier is created and how it resolves to a DID Document, the record holding public keys and service endpoints. DID Resolution standardises that lookup across methods.

MethodHow it resolvesGood for
did:keyDecoded from the identifier itself; no network callEphemeral, device-bound, and test identities
did:webFetches /.well-known/did.json over HTTPS from a domainOrganisations and issuers that already own a domain
did:pkhDerived from a blockchain account addressBridging crypto wallets into DID-based flows
Ledger methods (did:ion, others)Read from a distributed ledgerLong-lived identifiers with key rotation and no domain dependency

For CIAM, did:web is the pragmatic issuer choice because trust follows the domain you already control. On the holder side, wallets and devices often use did:key. DID authentication means proving control of a DID by signing a challenge with a key from its DID Document. In a CIAM flow that proof normally rides inside an OID4VP presentation.

Web3 authentication and how it relates to decentralized identity

Web3 authentication signs users in with a crypto wallet. The site presents a message and the wallet signs it. The server verifies the signature and starts a session. Sign-In with Ethereum (EIP-4361) standardises that message, including domain, nonce, and expiry, to block replay and phishing across sites.

Wallet sign-in proves control of an address. It says nothing about who the person is, whether they are over 18, or whether they passed KYC. That is what verifiable credentials add. Teams building for crypto-native users often combine the two: wallet sign-in for the session, plus a credential presentation when a regulated action needs verified attributes. Treat the wallet as one more authenticator in the CIAM, with the same session, recovery, and account takeover controls as any other login method.

The CIAM integration pattern

How decentralized identity fits into an existing CIAM deployment:

  1. User authenticates to the CIAM as usual (passkey, password+MFA, federated SSO).
  2. CIAM identifies an operation requiring verified attributes: age verification for a regulated purchase, identity proof for a financial onboarding, professional license verification for a registration.
  3. CIAM initiates an OID4VP presentation request to the user's wallet (via deep link, QR code, or web flow). The request specifies which credentials and which fields are needed.
  4. User's wallet prompts them to disclose; user reviews and consents; wallet generates a verifiable presentation with only the requested (and consented) data.
  5. Wallet returns the presentation to the CIAM (or directly to the application). Cryptographic verification confirms the issuer's signature, the selective-disclosure correctness, and the presentation's authenticity.
  6. CIAM stores the verified attributes as user-record metadata, tagged with the verifying issuer and timestamp.
  7. Subsequent operations check the verified attributes from the user record; re-verification when the credential expires or the operation requires fresh proof.

The CIAM handles the broader identity lifecycle (authentication, sessions, federation); the wallet handles the credential presentation; the application orchestrates when to ask.

The specific use cases that pay back today

The decentralized-identity value is concentrated in specific use cases:

High-friction IDV. Replacing document-capture-plus-selfie-plus-liveness with wallet-presented government credentials. Lower latency, better privacy, harder to spoof. For B2C onboarding where IDV is required, wallet acceptance materially reduces friction for users who have wallets.

Cross-border identity. EU citizens accessing services in any member state via one EUDI Wallet credential. The pre-EUDI alternative was per-country IDV integration; the EUDI alternative is one OID4VP integration.

Regulated workloads. Healthcare provider verification, financial-services KYC, professional licensing, workloads where the relying party historically had to integrate with authoritative-data providers directly. Wallet-presented credentials from authoritative issuers replace some of that integration work.

Privacy-sensitive disclosure. Age verification for restricted content, residency verification for jurisdiction-specific services, single-attribute checks, anywhere selective disclosure produces a meaningful data-minimization win over full-document presentation.

Re-verification at recovery. For high-assurance account recovery, presenting a fresh wallet credential is stronger and lower-friction than re-running document IDV.

For convenience-driven consumer flows, decentralized identity is currently not a clear value-add: passkeys handle the friction problem; the wallet integration cost doesn't pay back near-term.

EUDI Wallet specifically

The eIDAS 2.0 mandate creates the largest planned digital-identity rollout of the decade:

  • 2024: regulation in force; member-state implementation planning begins.
  • 2026: all EU member states must offer EUDI Wallet to citizens.
  • 2027: very large online platforms (under the Digital Services Act) and regulated industries (finance, healthcare, telecom) must accept EUDI Wallet for identity, authentication, and certain signed attestations.
  • 2028+: broader acceptance across EU public services and increasingly private-sector flows.

The compliance and integration work for B2C services with EU users:

  • Identify: which user flows currently require identity proofing (IDV at signup, age verification, address verification)? Each is a candidate for EUDI Wallet acceptance.
  • Architecture: OID4VP integration on the CIAM side, presentation request flows, verified-attribute storage.
  • Scope: selective disclosure pattern, request only the fields needed.
  • Fallback: parallel paths for users who don't yet have an EUDI Wallet (still most users in 2026, decreasing through 2027-28).

The timeline is firm; the integration is non-trivial. Planning starts in 2026; production deployment by mid-2027 is the right pacing for most affected services.

US state mDL and the consumer-side path

US adoption is state-by-state and not unified by federal mandate. As of 2026, production mDL programs exist in Arizona, Colorado, Maryland, Delaware, Georgia, Kentucky, Mississippi, Ohio, Oklahoma, Utah, and others, with continued expansion. TSA airport acceptance is at select airports. Apple Wallet supports mDL in supporting states; Google Wallet has similar capability.

The CIAM-side opportunity:

  • Age verification flows: where state mDL is available, accepting mDL for age verification is materially better UX than ID upload.
  • Identity proofing for high-friction signup: financial services, regulated industries, anything that currently asks for driver's license image upload.
  • Sharing economy onboarding: hosts, drivers, providers who need identity verification: mDL presentation is faster and harder to spoof than image upload.

The integration is ISO/IEC 18013-5-based, with vendor SDKs (Apple PassKit, Google Wallet API) handling the wallet-side protocol. The acceptance UX (NFC tap, Bluetooth, QR) varies by deployment.

When to wait

Honest accounting of where decentralized identity is not the right near-term investment:

  • Consumer convenience flows with no IDV requirement. Passkeys handle the friction; wallet integration adds complexity without proportional benefit.
  • B2B SaaS without regulated identity needs. The integration cost doesn't pay back near-term unless your customers explicitly demand wallet acceptance.
  • Markets without wallet adoption. Outside EU and select US states, wallet usage is still minimal; integration produces little user value yet.
  • Use cases where existing IDV is adequate. If your current IDV flow performs acceptably and you're not facing the EUDI mandate, the wallet integration is opt-in.

The 2026 honest framing: decentralized identity is a real and important infrastructure shift, but the right investment timing depends on specific use cases. EU exposure forces planning; non-EU consumer flows are mostly opt-in.

Implementation guidance

  1. For B2C with EU users: plan EUDI Wallet integration. The 2027 acceptance requirement is firm; integration takes 6-12 months of work for a non-trivial CIAM deployment.
  2. For US-targeted services with IDV: evaluate mDL acceptance for the states your users come from. Add as a parallel path to existing document upload.
  3. Use OID4VP as the integration protocol. Existing OIDC infrastructure handles most of the shape; the verifiable-presentation handling is the new code.
  4. Selective disclosure by default. Request only the fields you need; the GDPR posture and user-trust both benefit.
  5. Pair wallet acceptance with traditional IDV as fallback for users without wallets. Don't force the wallet path; offer it as an alternative.
  6. Plan for credential revocation. The wallet model supports revocation; verifying-side handling matters for high-trust use cases.
  7. Track standards evolution. OID4VP, SD-JWT VC, and the broader wallet protocols are in active draft. The 2026-2027 standardization will shape integration patterns.
  8. For high-assurance recovery flows (Account Recovery Design): wallet re-presentation is strong recovery evidence, better than re-IDV in most scenarios.

Related guides

Where to next

FAQ

What is decentralized identity?
An identity model where the user holds their credentials (in a personal wallet app) and controls when and how they're shared, rather than depending on identity providers (Google, Microsoft, governments) for daily access. The technical substrate is W3C Decentralized Identifiers (DIDs), W3C Verifiable Credentials (VCs), and protocols like OpenID for Verifiable Presentations (OID4VP) that connect wallets to relying parties. Production deployment is most advanced in EU government identity (EUDI Wallet, eIDAS 2.0) and US state mobile driver's licenses.
Is decentralized identity replacing CIAM?
No. The relationship is additive. CIAM still handles authentication, sessions, profile, federation, and the bulk of identity operations. Decentralized identity adds the capability to accept user-presented credentials issued by authorities (government IDs, education credentials, professional licenses) as an alternative to the relying party's own identity verification. The CIAM verifies the cryptographic signature and consumes the disclosed claims; the rest of the auth flow continues normally.
When should B2C apps integrate EUDI Wallet?
The eIDAS 2.0 timeline forces this for EU users: member states must issue EUDI Wallet to citizens by end of 2026; very large online platforms must accept it for identity and authentication by 2027. Realistic planning is to begin integration in 2026, with production support by mid-2027. For B2C without EU exposure, decentralized identity is opt-in based on use case: high-friction IDV and regulated workloads benefit; convenience-driven consumer flows are less impacted near-term.
What's the difference between mDL and EUDI Wallet?
mDL (Mobile Driver's License, ISO/IEC 18013-5) is a US-led standard for digital driver's licenses, deployed state-by-state. EUDI Wallet is the EU-wide regulatory framework for digital identity (eIDAS 2.0), broader in scope (national ID, education credentials, professional licenses, payment) and unified across member states. Technically they share the W3C VC substrate; commercially they're different ecosystems with different acceptance footprints.
Do DIDs require a blockchain?
No. DIDs are identifiers; the 'method' part of `did:method:identifier` determines where the DID resolves. `did:web` uses a regular HTTPS URL; `did:key` embeds the public key directly; `did:ion` uses Bitcoin only as a timestamp anchor. The 'decentralized' in DID refers to issuance and control (the subject controls the identifier without a central authority), not necessarily to blockchain storage.
What about selective disclosure?
Selective disclosure is the privacy-defining property: the credential holder reveals only specific fields to a verifier ('age over 21' without revealing birthdate, name, or address). Two cryptographic schemes implement it: SD-JWT VC (IETF draft, 2024, the EUDI Wallet default) and BBS+ signatures (zero-knowledge proofs over the credential). For GDPR-sensitive use cases, selective disclosure is the architectural answer to data minimization at the credential layer.
What is the W3C Verifiable Credentials Data Model 2.0?
It is the W3C standard that defines how a verifiable credential is structured: an issuer, a subject, claims, and a cryptographic proof, plus how credentials are bundled into presentations. Version 2.0 became a W3C Recommendation on 15 May 2025. It supports securing credentials with JOSE, COSE, SD-JWT, or Data Integrity proofs.
What is did:key?
did:key is a DID method in which the identifier is derived directly from a public key, so resolving it needs no network lookup or registry. It is ideal for short-lived or device-bound identities and testing. Because the key cannot be rotated without changing the DID, it suits ephemeral use better than long-lived organisational identity.
What is DID resolution?
DID resolution is the process of turning a DID into its DID Document, the JSON record that lists the subject's public keys, verification methods, and service endpoints. Each DID method defines how to resolve it: did:key decodes the identifier itself, did:web fetches a file over HTTPS, and ledger-based methods read a blockchain.
What is DID authentication?
DID authentication proves control of a DID by signing a challenge with a private key listed in the DID Document. The verifier resolves the DID, finds the verification method, and checks the signature. In CIAM it usually happens inside an OID4VP presentation, so the wallet proves both key control and the credential in one step.
What is Web3 authentication?
Web3 authentication lets users sign in by signing a message with a crypto wallet key instead of a password. Sign-In with Ethereum (EIP-4361) standardises the message so the site can verify it and issue a normal session. It proves control of a wallet address, not a real-world identity, so pair it with verifiable credentials when identity attributes matter.
Can AI agents use DIDs and verifiable credentials?
Yes, and it is an active area. An agent can hold a DID and present credentials that state who it acts for and what it may do, which a verifier checks without calling the issuer. Most production agent identity today still uses OAuth tokens, covered in the authentication for AI agents guide.

Sources

Last reviewed 2026-09-28.