DID Method Selector
Select your project requirements
Recommended DID Method
is the optimal choice for your requirements.
Why this recommendation:
Key Characteristics
When building digital identity solutions, Verifiable Credential is a cryptographically secure, tamper‑evident digital attestation that can be issued, held, and verified without a central authority. Pair it with a Decentralized Identifier (DID) - a globally unique, blockchain‑anchored identifier that lives in a DID Document - and you get a self‑sovereign identity framework that lets users control their own data.
What Are Verifiable Credentials?
At their core, Verifiable Credentials are structured statements about a subject (a person, organization, or thing). The W3C Verifiable Credentials Data Model v2.0 defines three roles:
- Issuer: creates the credential and signs it with a private key.
- Holder: stores the credential in a wallet or Verifiable Data Registry (VDR).
- Verifier: checks the signature and optionally the credential’s status.
Because the credential is signed, anyone can verify its authenticity without contacting the issuer, as long as they trust the public key associated with the DID.
How DIDs Work
A DID looks like did:method:unique‑string. The method part tells you which underlying network resolves the identifier - for example, did:key (pure cryptographic keys), did:ion (Microsoft’s ION on Bitcoin), did:web (HTTPS‑based), or the newer did:kery. When you create a DID, a DID Document is generated containing:
- Public keys for verification and encryption.
- Service endpoints (e.g., a DIDComm messaging URL).
- Authentication methods.
These documents are stored on a Verifiable Data Registry, often a blockchain, ensuring immutability and global accessibility.
Core Architecture Layers
Implementations typically follow five layers (GS1 reference):
- Data Model Layer: follows the W3C VC Data Model and defines the JSON‑LD structure.
- Identity Layer: handles DID creation, resolution, and method selection.
- Credential Issuance Layer: supports formats like JSON‑LD and JWT for different ecosystems.
- Proof Layer: adds cryptographic signatures, Linked Data Proofs, JWT Proofs, and optionally Zero‑Knowledge Proofs (ZKP) for selective disclosure.
- Revocation Layer: tracks credential status via Status Lists, blockchain anchoring, or centralized revocation lists.
Issuance and Verification Flow
The end‑to‑end process looks like this:
- The issuer creates a credential JSON‑LD document, adds claims (e.g., name, birthdate), and signs it with a private key tied to its DID.
- The holder receives the signed credential and stores it in a digital wallet that can render the credential for human consumption.
- When asked to prove a claim, the holder creates a presentation - a package that may include a subset of claims.
- The verifier resolves the issuer’s DID, fetches the public key, checks the signature, and optionally queries the Revocation Layer for status.
This separation lets the holder disclose only what’s needed (Selective Disclosure) while keeping other attributes private.
Privacy Enhancements
Privacy is baked in through two main techniques:
- Selective Disclosure: using BBS+ signatures or ZKPs, the holder can prove a statement (e.g., age > 18) without revealing exact data.
- Zero‑Knowledge Proofs: cryptographic protocols that let a party prove knowledge of a secret without exposing the secret itself.
These tools make VCs suitable for GDPR‑compliant use cases where data minimization is required.
Revocation Strategies
Because credentials can become outdated, revocation is crucial. Three common approaches are:
- Status List: a compact bitmap stored on‑chain; each credential points to a bit indicating its validity.
- Blockchain Anchoring: the issuer posts a transaction with the credential’s hash; revocation is a new transaction marking the hash as revoked.
- Centralized Revocation List: a REST API that returns revocation status; useful when on‑chain costs are prohibitive.
The choice depends on performance, cost, and regulatory requirements.
Real‑World Use Cases
Organizations are already experimenting with VCs and DIDs across sectors:
- Travel passports: border agencies verify a traveler’s visa credential without accessing the full passport record.
- Academic certificates: universities issue tamper‑proof diplomas that employers can instantly validate.
- KYC/AML compliance: banks accept a verified email or phone credential, reducing onboarding friction.
- Community membership: online forums grant access tokens that prove membership without exposing personal data.
Choosing the Right DID Method
| Method | Underlying Tech | Pros | Cons |
|---|---|---|---|
| did:key | Pure cryptographic keys | Fast, no on‑chain registration | No persistent identifier; not ideal for long‑term claims |
| did:ion | Bitcoin Layer‑2 (ION) | Decentralized, public resolution | Higher latency, Bitcoin fees |
| did:web | HTTPS + DNS | Easy to host, no blockchain costs | Relies on central domain ownership |
| did:kery | KERI (Key Event Receipt Infrastructure) | Strong key rotation, auditability | Still emerging, limited tooling |
Pick a method that matches your trust model, cost tolerance, and ecosystem support.
Getting Started Checklist
- Define the credential schema (claims, types, JSON‑LD context).
- Select a DID method and register the issuer DID.
- Implement signing using a library that supports Linked Data Proofs or JWT.
- Choose a wallet solution for holders (e.g., mobile VC wallets).
- Decide on a revocation mechanism and integrate status checks.
- Test end‑to‑end flow: issue → store → present → verify.
Following this checklist reduces integration risk and helps you hit the market faster.
Frequently Asked Questions
How does a Verifiable Credential differ from a regular digital certificate?
A regular certificate usually ties to a centralized PKI and requires the verifier to contact the issuing CA. A Verifiable Credential is self‑contained: the signature and the issuer’s DID are enough for verification, eliminating the need for a central authority during the check.
Can I store a VC on a public blockchain?
Storing the full credential on‑chain is possible but inefficient. Most implementations keep the credential off‑chain and store only a hash or a pointer on the blockchain for tamper evidence.
What is the role of Zero‑Knowledge Proofs in VCs?
ZKPs let a holder prove a statement (e.g., age > 21) without revealing the underlying data. This adds privacy while still providing the verifier with cryptographic assurance.
Are there any regulatory concerns?
Regulators are still catching up. However, because VCs support data minimization and audit trails, they align well with GDPR, eIDAS, and emerging self‑sovereign identity guidelines.
How do I choose a wallet for holders?
Look for wallets that support W3C VC JSON‑LD, allow selective disclosure, and provide a user‑friendly QR‑code flow. Examples include Trinsic, Veramo, and the open‑source SSI‑Kit.
9 Comments
Bert Martin
Really solid breakdown. I've been playing with did:web for internal tools and it's been smooth as butter. No blockchain fees, easy to host, and our devs didn't need to learn anything new. Just DNS and HTTPS - genius simplicity.
Ali Korkor
Man this stuff is wild. Think of it like digital ID cards you actually own. No more sending your whole passport just to prove you're 21. Just show the age part. Boom. Done. This is how the future works.
madhu belavadi
They say this is decentralized but let's be real - who's really controlling the keys? Big tech is just putting on a blockchain mask. This is just another way to lock you in. You think you own your data but you're still just a product.
Dick Lane
I tried implementing this at my startup last year and honestly it was a nightmare at first
But once we got the wallet flow right and started using BBS+ for selective disclosure
Man it changed everything
Our compliance team stopped screaming
Our users actually smiled when signing up
It's not magic but it's close
Norman Woo
you know theyre using this to track us right
blockchain is just a fancy ledger
every time you use a vc they log it
and soon theyll know what you bought when you slept and who you talked to
theyre building the panopticon and calling it freedom
Serena Dean
YES YES YES this is the future!!
Just had a client use a VC to verify their nursing license - took 12 seconds instead of 3 days
They cried. I cried.
And no one had to email a PDF or wait for a notary.
THIS IS WHAT WE’RE BUILDING FOR.
James Young
Everyone's acting like this is some revolutionary breakthrough but it's just W3C specs wrapped in buzzwords
Did you read the spec? It's a JSON-LD document with a signature - that's it
You could have done this in 2018 with a simple API and JWT
Blockchain is just marketing fluff for VCs
Stop pretending this is new tech
Chloe Jobson
did:key for internal use
did:ion for public-facing credentials
did:web for legacy integrations
and always pair with status lists for revocation
avoid centralized lists unless you're in a regulated sandbox
and yes - ZKP is non-negotiable for GDPR
Andrew Morgan
So I built a thing last month where a local library used VCs to verify student IDs
no cards no apps no login
just scan a QR and boom they get access
old lady with a flip phone got it on the first try
and her grandkid was like 'wait this is magic'
we didn't even need a blockchain
just did:web and a simple API
and people actually trusted it
that's the real win right here