Every time you log into Google, hand your driver’s license to a bartender, or give your home address to some shoping website, you’re giving someone information about you. That information is repeated and duplicated again and again across hundreds to thousands of accounts, all with your real information, and any of which can, and eventually will, get breached.
Decentralized Identities (DID) flips that model on its head. Instead of some company holding your identity and granting you access to it, you hold your identity and present cryptographic proof of whatever claims you need to make. There’s no intermediary, no middleman, and it’s all your data, so there is no “we regret to inform you of a data breach.”
This article covers how that technology works, why it’s meaningfully more secure than what we have today, where it’s being used right now, and (the harder problem) how adoption actually happens. I’m looking at you companies who STILL haven’t implemented passkeys..
The Current Model Is Structurally Broken
I firmly believe that the federated identity model that dominates the internet is built on a flawed premise. It assumes that centralized authorities like Google, Apple, your employer, a government DMV database, etc. are trustworthy, competent, and permanent. Two out of three might be true at any given moment. All three simultaneously is… Optimistic.
For example:
When you use “Sign in with Google,” Google knows every site you authenticate to and every time you do it. That’s surveillance infrastructure masquerading as convenience. When LinkedIn or Experian get breached (it’s when, not if), your identity and data are now permanently exposed, you had zero control over that risk, and zero ways to avoid it.
The deeper issue is that you don’t actually own your identity in this model. You’re a record in someone else’s database. Your identity can be suspended, restricted, shared, duplicated, and/or revoked at any time by an entity that has its own business interests (and not your own) at heart.
That’s the problem Decentralized Identity is trying to solve.
How It Actually Works
Ok. Here’s the technical part, and I’ll try not to make it a spec dump.
The Three-Legged Stool
The foundation of Decentralized Identities rests on three core components working together:
1. Decentralized Identifiers (DIDs)
A DID is a unique identifier that you generate and control that is anchored to a decentralized registry. This registry is typically a blockchain or distributed ledger, but doesn’t have to be. It will look something like this:
did:web:example.com:users:alice
did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9y34a2fA5XWrfDsThat “method” (the part after did:) defines how the DID is resolved (how you look up the associated public key and metadata). There are dozens of DID methods. Some anchor to Ethereum, some to Bitcoin, some to web infrastructure (did:web), and again, some don’t use a blockchain at all but are just as secure. This is because the did:key is essentially just an inline public key.
Each DID points back to a DID Document a JSON-LD object that contains the public keys that the DID subject controls, and optionally service endpoints for communication.
2. Verifiable Credentials (VCs)
This is where identity data lives. There’s a bit of newer nomenclature here, so bear with me. A Verifiable Credential (sometimes called the Digital Credential) is a tamper-proof document that is issued by an authority (called an Issuer) to a subject (you the Holder), that a third party (the Verifier) can verify cryptographically without having to call home to the Issuer.
Think of it like this.. Right this second, your driver’s license essentially just says that the DMV vouches for your age, DOB, address, and driving privileges. In the VC model, the DMV is the Issuer. They cryptographically sign a credential saying “yep, that’s the right information”. You hold that credential in a digital wallet until someone, say a bar (Verifier), needs to check that signature and the non-revocation proof. This check is done without needing to contact the DMV in real time. If the credential is tampered with, the proof will show it.
For those of you who know public-key cryptography: VCs are signed using the Issuer’s private key and the Issuer’s public key is published in their DID Document. That way, the verification chain is fully self-contained and secure.
3. Digital Wallets
Your wallet, like the above example states, stores your DIDs and your Verifiable Credentials. It handles key management, credential presentation, and selective disclosure (meaning you actually get to choose what to discole to the Verifier). This is the user-facing piece that every-day people would use.
The Presentation Exchange Flow
When you need to prove something to a Verifier, you don’t actually hand them the raw credential. What you do is construct a Verifiable Presentation (VP). The VP is a subset of claims from one or more credentials, signed with your own DID key to prove you’re the legitimate holder.
The sequence looks like this:
- Verifier sends a Presentation Request specifying what claims they want/need access to
- Wallet selects the matching credentials
- Wallet applies selective disclosure (only the requested attributes are exposed)
- Holder signs the VP with their private key and returns it
- Verifier checks: Is the credential signature valid? Is the credential unexpired? Is it unrevoked? Is the presenter actually the subject?
All of this can happen without the Issuer having to know that a verification occurred. That’s a fundamental privacy shift from today’s federated systems.
The Revocation Problem (And How It’s Solved)
One thing people tend to ask is if the Issuer isn’t involved in verification, how do you revoke a credential?
The most widely adopted answer right now is Status List 2021 (and its successor, the Bitstring Status List spec). The Issuer publishes a compressed bitstring to a known endpoint. Each credential contains a pointer to its position in that bitstring. Verifiers check the bit. Flipping the bit (from 1 to 0) means the credential is revoked. The Issuer doesn’t know who checked or why, they just maintain the list.
It’s elegant, but of course, requires internet access.
Why This Is Actually More Secure
No Central Honeypot
The thing attackers love most about centralized identity systems is that they’re efficient targets. One breach will get them millions of records and just as many dollars for the information. Decentralized Identity eliminates that attack surface by removing the central store of user identity data to steal because the credentials live in a wallet that the user controls.
(Yes, technically wallets can be compromised. But that’s a targeted attack against an individual, not a bulk harvest. The juice typicaly isn’t worth the squeeze if the attacker has to do 10k attacks to get 10k users vs 1 attack for the same amount.)
Cryptographic Binding, Not Passwords
Every interaction in the DID model is backed by public-key cryptography. There’s no shared secret to phish or a password database to crack. A Verifier can’t be fooled by a replay attack because presentations are scoped, time-limited, and signed fresh.
Phishing-Resistant by Design
Presentation flows are bound to the Verifier’s DID or domain. Presenting a credential to a phishing site that’s spoofing a real Verifier will always fail beacuse the wallet can detect the DID mismatch. This isn’t 100% foolproof (nothing is), but it’s structurally more resistant than anything OTP-based.
Real Use Cases
DID and VCs are live and in production. A few examples worth knowing:
EU Digital Identity Wallet (EUDIW)
The EU’s eIDAS 2.0 regulation mandates that every EU member state offer citizens a digital identity wallet by 2026. While that date keeps getting pushed back, these wallets will carry government-issued VCs: driving licenses, national IDs, diplomas, prescriptions, etc. The EUDIW architecture is explicitly built on W3C DID and VC standards. This is the largest real-world DID deployment happening right now, and hopefully will drive global adoption.
Education Credentials
MIT, Arizona State, and others have been issuing blockchain-anchored diplomas via Blockcerts for years now. The W3C VC spec has since standardized this further. A graduate can share a digital diploma with any employer, anywhere, without the employer needing to call MIT’s registrar to validate it.
Healthcare
The COVID pandemic accelerated work on health credential wallets like vaccine records, test results, and medication data. SMART Health Cards (if any of you have used them) are a VC-adjacent format. The VCI (Vaccine Credential Initiative) has built a real-world deployment at scale.
Employee Identity and Verifiable Employment
Some forward-thinking companies are experimenting with issuing VCs to employees for things like access badges, role assertions, and employment history. These are credentials the employee retains even after they leave and can present to the next employer or to a background check service to speed up and streamline the process.
The Adoption Problem
Here’s the problem… Just like we all saw with passkeys. The technology is ready, but the adoption isn’t.
Decentralized Identity has a bootstrapping problem that’s difficult. It requires issuers, holders, and verifiers to all exist at the same time before the system has any value.
I see the path forward as adoption is pulled from different directions:
Government-Driven Mandates
The EU eIDAS 2.0 mandate is the most powerful forcing function in existence right now. Governments issuing wallets to citizens creates an issuer and a holder base overnight. Verifiers will follow because the credentials will have to be there. Watch the EU because whatever gets built there will become a reference implementation for the rest of the world.
Employer-to-Employee Issuance
Enterprises already issue credentials (badges, access cards, role assignments). Migrating those to verifiable credentials costs relatively little and creates a natural on-ramp. This is a closed-loop deployment that doesn’t require public adoption to have value and can dramatically lower the cost of employee onboarding.
Sector-Specific Trust Frameworks
Depending on the sector, adoption is going to happen irregularly for most organizations. Healthcare, finance, and education will all have their own trust requirements. Trust frameworks like the ToIP (Trust Over IP) Foundation and OpenID for Verifiable Credentials (OID4VC), which builds VC presentation on top of existing OAuth/OIDC infrastructure, will let each sector define its own rules while maintaining interoperability and flexibility.
OID4VC is worth a separate deep-dive, but the short version is that it lets you issue and verify credentials using OIDC endpoints. That way, if you already have an OIDC provider, you don’t have to start from zero.
Wallet UX Must Get Better
Right now, a lot decentralized identity wallets are being built by people who don’t think about UX. The key management experience alone is enough to make a normal person just give up. Until wallets feel as seamless as Apple Pay or a solid password manager (e.g. with a ‘common user’ in mind) mainstream adoption will not happen.
The good news (or bad news) is that the big platform players like Apple, Google, Microsoft are building or integrating wallet capabilities into their systems already to get ahead of the government mandates. These implementations won’t be fully decentralized in the ideological sense, but they’ll hopefully accustom (and not trap) people to the model.
Drive Adoption By Reducing Verifier Burden
If you want to push adoption in your organization or your product, the lever is on the Verifier’s side. You should be making it trivially easy to verify a credential. You hsould build VC verification into your existing IAM stack and support OID4VC if you’re already on OIDC. Once verifiers can accept these credentials, issuers have a reason to issue them, and holders have a reason to carry them.
TL;DR
- Decentralized Identity gives users cryptographic control over their own identity attributes so no central authority holds or gatekeeps the data
- DIDs are self-generated, cryptographically anchored identifiers; Verifiable Credentials are signed attestations from issuers that holders present to verifiers without the issuer being involved in real time
- The security advantages are structural: no centralized data for attackers, no shared secrets to phish, selective disclosure by default, and cryptographic binding throughout
- Real deployments exist now like EU eIDAS 2.0, education credentials, and healthcare, but adoption is painfully slow
- Adoption will happen through mandates, employer issuance, sector trust frameworks, and making verifier integration easy
- OID4VC is probably the most realistic on-ramp for teams already running OIDC