CIAM.wiki

Decentralized identity and verifiable credentials

In the model most CIAM runs on today, you store the customer’s identity and they log in to reach it. Decentralized identity inverts that: the customer holds verifiable credentials in a wallet and presents them when needed, and you verify the proof without holding the underlying data. It is the same instinct behind bring your own identity, taken to its conclusion, where the credential is cryptographic and the issuer is not in the login path.

The moving parts

  • Verifiable credential: a tamper-evident claim (over 18, a verified email, a bank-proofed identity) signed by an issuer and held by the customer.
  • Decentralized identifier (DID): an identifier the customer controls, not issued by your directory, that the credential binds to.
  • Wallet: the app the customer uses to receive credentials and present them selectively.

The standards live at the W3C (Verifiable Credentials, DIDs). This is the machinery behind self-sovereign identity, where the person, not a central provider, holds and controls their credentials.

Why it matters to CIAM

The appeal is reusable, pre-proofed trust with less data for you to hold and breach. A customer proofed once can present that assurance to you without re-proofing, and selective disclosure lets them prove a fact (over 18) without handing over the document behind it. That reduces both onboarding friction and your liability surface.

The honest constraint

Adoption is the hard part, the same two-sided problem every reusable credential faces: customers will not maintain credentials nobody accepts, and businesses will not build acceptance few customers can use. Government and bank-backed wallets (and the EU’s push under eIDAS 2) are the most likely catalysts. For now, treat it as a capability to plan for rather than depend on, and weight a presented credential by the assurance of its issuer, exactly as you would any identity proofing result.

What to ask a CIAM vendor

  • Can the platform accept W3C verifiable credentials and DIDs, and through which wallet ecosystems?
  • How is the assurance of a presented credential recorded and carried into the profile?
  • Does it support selective disclosure, so a customer proves a fact without oversharing?
  • Can a wallet credential be one accepted identity among social, eID, and password, with policy per source?
  • What is the roadmap for eIDAS 2 and government wallet acceptance in our markets?

The buyer takeaway: decentralized identity is a real shift in who holds the data, but adoption decides the timeline, so evaluate it as forward-looking capability and let issuer assurance drive how much you trust any credential. See the wallet and credential players in the market map, then run the vendor matcher.