What should I look for in a decentralized identity platform?

Support for the 1.0 Final OpenID4VCI and OpenID4VP specifications, the credential formats your verifiers use (SD-JWT VC, ISO mdoc or W3C VC), a clear wallet strategy, status list revocation, issuer trust through X.509 trusted lists or a trust registry, and interoperability evidence such as a HAIP 1.0 conformance result or eIDAS ARF alignment.

What is the best decentralized identity platform?

There is no single best platform; the right one depends on your role. Government and EU wallet work favors HAIP-aligned stacks such as Procivis, walt.id or MATTR. Microsoft-centric workforce use cases fit Microsoft Entra Verified ID. Accepting many existing digital IDs through one API fits an acceptance network such as Trinsic. Shortlist by role, then test interoperability.

Should I buy a platform or build on open standards myself?

Buy when you need issuance and verification in production quickly, want managed wallets and revocation, or must interoperate with government wallets. Build on open libraries when your needs are narrow and you have the cryptographic engineering depth to own key custody, status lists, and the upgrade path as SD-JWT VC and DID 1.1 move toward final versions.

Which decentralized identity vendors should I evaluate?

The field includes Microsoft Entra Verified ID, MATTR, SpruceID, Procivis, walt.id, Dock, Indicio, Gataca, Affinidi, Dentity and Trinsic. Shortlist by your use case (issuer, verifier, wallet, government interoperability or private ecosystem) rather than by brand, and confirm current scope: Trinsic sold its decentralized identity platform to Dentity in December 2024.

Does a decentralized identity platform need a blockchain?

Usually not. The EU wallet framework anchors issuer trust in X.509 certificates and trusted lists, mDLs chain to issuing-authority roots, and did:web resolves over HTTPS from a domain you control. Ledger-based DID methods suit specific ecosystems, such as Hyperledger Indy networks using AnonCreds, but they are not a requirement for issuing or verifying credentials.

What does HAIP conformance tell me about a vendor?

HAIP 1.0, final since 24 December 2025, pins one interoperable set of choices: SD-JWT VC or ISO mdoc, ES256 signatures, PKCE, PAR and DPoP for issuance, wallet attestation, DCQL queries, signed requests with x509_hash, and Token Status List. A vendor that passes HAIP tests can talk to EU-style wallets; one that only cites earlier drafts may not.

How to Choose a Decentralized Identity Platform

A decentralized identity platform is the software that lets an organization issue, verify, or hold verifiable credentials: signed, tamper-evident claims a person keeps in a wallet and presents without the verifier calling the issuer. To choose one in 2026, decide your role first (issuer, verifier, or wallet), then require the 1.0 Final OpenID4VC specifications as profiled by HAIP, support for the formats your verifiers actually accept, and proof of interoperability with someone else's wallet. Brand and roadmap come last.

This buyer guide is for architects and product owners shortlisting vendors. If you are still deciding whether you need one, start with decentralized identity explained.

Decision table: start from your use case

The single biggest filter is what you are trying to do. Use this before you look at any vendor.

Your role	What you need most	Formats to require	Where to look first
Verifier only (accept credentials others issue)	Verification SDK, OpenID4VP 1.0, broad wallet compatibility	SD-JWT VC and ISO mdoc	Acceptance APIs and verifier SDKs
Issuer (make your data portable)	Signing and key custody, schemas, revocation, OpenID4VCI 1.0	Whatever your verifiers accept	Managed issuance platforms
EU or government interoperability	HAIP 1.0 conformance, ARF alignment, X.509 trust	SD-JWT VC and mdoc, per the EUDI Wallet ARF	Public-sector and EUDI-aligned stacks
Driver's license and age checks	mdoc presentation in person and online	ISO mdoc (mDL)	Verifiers with ISO 18013-7 and Digital Credentials API support
Private ecosystem or consortium	Governance tooling, trust registry, privacy	Often W3C VC; AnonCreds in Indy networks	Ecosystem-building vendors
Microsoft-centric workforce use	Low friction inside an existing tenant	JWT-VC	Your IAM vendor's built-in service

Most enterprises start as a verifier: it is the lowest lift and does not require issuance infrastructure.

The 2026 standards check

Version numbers decide interoperability, so ask for them explicitly. Status as of 5 November 2026:

OpenID4VP 1.0 and OpenID4VCI 1.0 are Final, and the High Assurance Interoperability Profile (HAIP) 1.0 was published as Final on 24 December 2025 (OpenID Foundation specifications). HAIP requires SD-JWT VC or ISO mdoc, ES256, PKCE, PAR and DPoP for issuance, wallet attestation, DCQL queries, signed requests with the x509_hash client identifier, and Token Status List for SD-JWT VC.
W3C VC Data Model 2.0 became a W3C Recommendation on 15 May 2025, alongside Bitstring Status List v1.0.
SD-JWT is RFC 9901, but SD-JWT VC is still an Internet-Draft: draft-24, in IESG evaluation with a DISCUSS open. HAIP pins draft-13, so "supports SD-JWT VC" needs a draft number.
DIDs: DID Core 1.0 is a Recommendation; DID 1.1 is a Candidate Recommendation.

A vendor's own standards page is the fastest test. Microsoft Entra Verified ID, for example, lists VC Data Model v1.1, JWT-VC, did:web as the only entity identifier, OpenID4VCI draft 11, and DIF Presentation Exchange v2.0.0. That is a working stack inside Microsoft's ecosystem, but it is not the HAIP profile. By contrast, walt.id lists OID4VCI 1.0, OID4VP 1.0, SD-JWT VC and ISO mdoc.

The capabilities that matter

Evaluate every shortlisted vendor against these:

Standards support: genuine W3C VC, SD-JWT VC, mdoc and OpenID4VC 1.0, not a proprietary format wrapped in the vocabulary.
Wallet strategy: does it provide a wallet, integrate third-party wallets, or both? Who owns the holder relationship?
Revocation and status: Token Status List or Bitstring Status List, with caching guidance. Bitstring Status List requires lists of at least 16KB uncompressed so a status check hides in a crowd.
Issuer trust: X.509 trusted lists (the EU model), a trust registry, or manual allowlists that will not scale.
Privacy: selective disclosure at minimum, batch issuance to limit correlation, and BBS signatures or ZKPs if unlinkability matters. The W3C BBS cryptosuite is still a Candidate Recommendation.
Key custody: HSM-backed issuer keys, rotation, and a recovery runbook.
Interoperability evidence: conformance results, HAIP alignment, EU large-scale pilot participation.

Failure modes to test for

Decentralized identity moves the weak points, it does not remove them. Use real incidents to shape your evaluation:

Issuer signing key compromise. In Storm-0558, an acquired Microsoft signing key let an actor forge tokens that a validation flaw then accepted. A stolen issuer key forges credentials the same way. Ask where keys live and how fast a vendor can rotate and revoke.
Verifiers that do not validate signatures properly. SimpleHelp's OIDC token forgery (CVE-2026-48558) came from signatures that were not properly validated. Test that a verifier rejects tampered, expired, and wrong-issuer presentations.
Replay without holder binding. A copied credential accepted on its issuer signature alone is the credential version of token replay against unbound endpoints. Require key binding checks against your nonce.
Cross-device relay. A QR code can be relayed from an attacker's session to a victim, the same pattern as an AitM phishing proxy. HAIP's same-device rules and signed verifier requests are the defense.
Document archives as honeypots. DigiCert disclosed in October 2026 that a system archiving customer identity-validation documents was reachable and accessible through self-registered accounts. Platforms that store copies of source documents recreate the problem credentials are meant to solve.

Questions that separate substance from marketing

"Which credential formats, draft numbers and DID methods do you support in production, not on a roadmap?"
"Show me an interop test result against another vendor's wallet or verifier, and your HAIP result."
"How does revocation work, and what does a verifier do offline or with a stale list?"
"Where are issuer keys held, and what is the rotation and compromise procedure?"
"If we leave, what happens to issued credentials and the holder wallets?"
"Which eIDAS ARF version are you aligned to?" (v3.0.0 was released 23 July 2026; see the eIDAS 2 page.)
"Who owns the company and the product line today?"

The last question matters in a consolidating market. Trinsic sold its decentralized identity platform, Trinsic Ecosystems, to Dentity on 12 December 2024 and now focuses on its Identity Acceptance Network, so buyers searching for Trinsic's decentralized identity products now need to evaluate Dentity for issuance and Trinsic for acceptance.

Buy vs build

Buy a platform when you need production issuance or verification quickly, want managed wallets and revocation, or must interoperate with government wallets. Build on open libraries (walt.id and SpruceID both publish them, and Procivis offers an open-source edition) when your scope is narrow and you can own key management and upgrades. As a planning estimate, not a measured figure, budget for at least one format or draft upgrade per year while SD-JWT VC and DID 1.1 are still moving.

The vendor landscape

The decentralized identity vendor directory profiles the active platforms, including MATTR, Dock, Indicio, Gataca and Affinidi. Best decentralized identity platforms and best decentralized identity for enterprises rank them. Shortlist three to five by role, then run the questions above against each.

Where to go next

Build details: verifiable credentials implementation guide. Architecture: DID methods compared. KYC angle: reusable identity and KYC.