What is decentralized identity in simple terms?

It is a model where people hold their own digital credentials in a wallet and present them directly to whoever needs to verify them, instead of relying on a central provider to broker every login or check.

Is decentralized identity ready for production in 2026?

For government wallets, mobile driver's licenses and reusable identity verification, yes: OpenID4VCI 1.0, OpenID4VP 1.0 and HAIP 1.0 were all Final by December 2025 and EU wallets are due by the end of 2026. As a wholesale replacement for enterprise SSO, no. Treat it as a targeted addition alongside federated identity.

Which credential format should I use: SD-JWT VC, mdoc or W3C VC?

Choose by verifier. For EU wallet interoperability, SD-JWT VC or ISO mdoc under HAIP. For driver's licenses and age checks, mdoc. For JSON-LD ecosystems that need unlinkable proofs, W3C VC 2.0 with Data Integrity. AnonCreds remains common in Hyperledger Indy networks.

Do I need blockchain to use decentralized identity?

No. The core W3C standards do not require a ledger, did:web uses ordinary domains and TLS, and the EU wallet and mDLs anchor trust in X.509 certificate chains. Blockchain is one option for anchoring identifiers, not a requirement.

What is the difference between decentralized identity and an identity provider?

An identity provider authenticates you and vouches for you to each service at login time. Decentralized identity gives you a signed credential you hold and present yourself, so a verifier can check it without contacting the issuer in real time.

What does "supports OpenID4VP" mean when a vendor says it?

It can mean draft 14, draft 20 or 1.0, and those versions do not interoperate. Ask which version, whether the product is conformance-tested against HAIP 1.0, and whether it uses DCQL or the older Presentation Exchange query language.

Decentralized Identity Explained: A Practical Guide

Decentralized identity lets people and organizations hold cryptographically signed credentials in a wallet and present them directly to a verifier, who checks the issuer's signature instead of calling a central identity provider. This guide is the practitioner view: which formats and protocols matter, how a verifier decides to trust an issuer, what changed in 2025 and 2026, and how to run a pilot. For the conceptual primer, read what is decentralized identity and what is self-sovereign identity.

Verdict as of November 2026: build to the 1.0 Final OpenID4VC specs profiled by HAIP, issue SD-JWT VC or mdoc if you need EU or mDL interoperability, and start where you repeat identity verification. Do not plan to replace SSO.

The core idea

Today a central identity provider sits between you and every service, authenticating you and vouching for you. Decentralized identity removes that runtime dependency. You hold verifiable credentials in a wallet and present them directly, and the verifier trusts the issuer's signature, not a live connection to a provider.

The trust triangle: issuer, holder, verifier

Every interaction has the same three roles, the issuer, holder, verifier triangle:

The issuer signs and grants a credential (a university, a government, an employer).
The holder stores it and decides when and to whom to present it.
The verifier checks the signature, the issuer, and the revocation status, offline if needed.

The verifier's ability to check a credential without calling the issuer is what makes the model scale and preserves privacy.

What changed in 2025 and 2026

Date	Milestone
15 May 2025	W3C Verifiable Credentials Data Model 2.0 becomes a Recommendation, with Bitstring Status List v1.0
9 July 2025	OpenID4VP 1.0 Final
16 September 2025	OpenID4VCI 1.0 Final
November 2025	SD-JWT published as RFC 9901
24 December 2025	HAIP 1.0 (High Assurance Interoperability Profile) Final
5 March 2026	DID 1.1 Candidate Recommendation Snapshot
23 July 2026	EU Architecture and Reference Framework (ARF) v3.0.0
End of 2026	Every EU member state must offer at least one EUDI Wallet

Dates and sources are on each linked standards page. The practical effect: the years of competing drafts are over, and "which spec version" is now a procurement question with a right answer.

Choosing a credential format

If your verifiers are	Use	Why
EU wallet relying parties	SD-JWT VC or ISO mdoc under HAIP	The only formats the ARF names for person identification data
Driver's license and age checks	ISO/IEC 18013-5 mdoc	What US state mDLs and phone wallets issue
JSON-LD ecosystems needing unlinkable proofs	W3C VC 2.0 with Data Integrity, later BBS	BBS cryptosuite is still a Candidate Recommendation
Existing Hyperledger Indy networks	AnonCreds	Zero-knowledge predicates, ledger-anchored

SD-JWT gives selective disclosure: the issuer signs a digest of each claim, and the holder reveals only the claims requested, bound to a fresh nonce. Zero-knowledge proofs and BBS signatures add unlinkability across presentations.

How a verifier decides to trust an issuer

A valid signature proves only that someone holding a key signed the credential. Trust comes from knowing whose key it is:

X.509 and trusted lists. HAIP requires issuers to carry X.509 certificate chains, the EU wallet uses trusted lists, and US mDLs chain to state roots published in AAMVA's Verified Issuer Certificate Authority List. This is the PKI path, and it dominates government deployments.
DIDs. did:web resolves an issuer key from a domain the issuer controls; ledger methods resolve it from a chain. Pair either with a trust registry that says which issuers are accredited for which credentials.

Revocation works the same way in every format: the issuer publishes a status list, and the verifier fetches the whole list rather than asking about one credential. SD-JWT VC and mdoc use the IETF Token Status List; W3C credentials use Bitstring Status List.

Where it is real in 2026

Government wallets: eIDAS 2.0 puts a state wallet in every EU citizen's hands; public authorities must accept it from the end of 2026, and regulated private relying parties within 36 months of the December 2024 implementing acts.
Mobile driver's licenses: ISO/IEC 18013-5 mDLs are shipping into phone wallets, and Google's documentation says Google Wallet accepts mdoc IDs online over OpenID4VP 1.0 through the Digital Credentials API. Track schemes in digital IDs by country.
Reusable identity and KYC: verify once, reuse the credential. This is the clearest enterprise ROI, covered in reusable identity and KYC with verifiable credentials.

How it fits with what you already run

Decentralized identity does not replace federated identity. SAML and OIDC remain the right tools for workforce SSO. The realistic picture is hybrid: federated for existing sign-in, verifiable credentials for reusable proofs and portability, stitched by an identity fabric.

Pitfalls we see

Draft drift. A product built on OpenID4VP draft 14 or 20 will not talk to a 1.0 wallet. Microsoft Entra Verified ID, for example, documents VC Data Model 1.1, OpenID4VCI draft 11 and did:web only, with no SD-JWT or mdoc support.
Cross-device phishing. A QR code can be relayed from an attacker's session to a victim. HAIP requires same-device redirects to return to the original session; the Digital Credentials API adds the verifier's origin.
Building to the ARF alone. The implementing acts are the binding text and are being amended. Track act numbers, not just ARF releases.
Skipping status checks. Check revocation on every presentation.

Should it be on your roadmap?

Ask three questions:

Do you repeat identity verification on the same people across products or partners? Reusable credentials pay off fastest here.
Do you operate in or serve the EU? eIDAS 2.0 is moving wallet acceptance from optional to expected.
Do you issue credentials (certifications, memberships, employment) that should be portable and holder-controlled? You may be an issuer, not just a verifier.

If none apply, watch the space. If any do, run a scoped pilot: pick one credential and one verifier, choose the format from the table above, require HAIP 1.0 conformance from vendors, and keep your existing KYC path as fallback. For vendors, walt.id and Procivis document OpenID4VCI 1.0 and OpenID4VP 1.0, MATTR and Spruce ID focus on mDL and government credentials, and Trinsic accepts existing digital IDs through one API. Our choosing a decentralized identity platform guide covers selection, and best decentralized identity platforms ranks the market.

Where to go next

Build details: verifiable credentials implementation guide. Architecture: DID methods compared. Protocols: OpenID4VC. Vendors: decentralized identity directory.