3 Fixes Engineers Need for DIDs vs Verifiable Credentials in Web3

A decentralized identifier (DID) is a portable, URL-based identifier a subject controls; a verifiable credential (VC) is a tamper-evident, cryptographically signed claim about that subject. They’re independent W3C standards that are usually paired: a VC’s proof often points back to a DID document for its verification key. If you’re designing for identity portability, start with the DID. If your priority is trustworthy attestations, start with the VC schema.

TL;DR:
DIDs are ideal for creating portable, long-lasting identifiers that are resilient across platforms, while VCs are best for portable, verifiable claims issued by trusted authorities.
Most production systems pair DIDs with VCs because a DID provides a stable verification anchor, but VCs can reference other identifiers like URLs or UUIDs.
Verification workflows involve issuing, storing, presenting, and validating credentials with checks on signature, revocation status, and proper resolution of the issuer’s DID.
Support for different DID methods varies, with options suited for ephemeral use, web-based resolution, or strong decentralization, and resolution guarantees are often handled by interoperability layers like the Universal Resolver.
Many challenges in deploying DIDs and VCs relate to wallet usability, key recovery, method fragmentation, and establishing trustworthy issuer frameworks—operational discipline is key to scaling.

Verifiable Credentials vs DID: Roles, Storage, and Verification at a Glance
What Do DID Documents and VC Fields Actually Contain?
How Does the Issuance-to-Verification Workflow Work?
Which DID Method Should You Actually Use?
Linked Data Proofs, JWT Proofs, and Zero-Knowledge Options
What Should You Watch for in Production Deployments?
Where Do DIDs and VCs Actually Get Used?
Why Do So Many DID and VC Projects Stall?
How Ditgold Applies DIDs and VCs to Data Asset Verification
Specs and Research Worth Reading Next
The Real Lesson Behind the DID vs VC Debate
Sources

Verifiable Credentials vs DID: Roles, Storage, and Verification at a Glance

Confusing these two specs is the most common mistake engineers make when scoping an identity architecture, and it’s an understandable one. Both live under the W3C umbrella, both show up in the same wallet apps, and both get lumped into the catch-all term “decentralized identity.” But they solve different problems, and the confusion tends to disappear once you see them side by side.

A DID answers “who is this, and how do I reach their public keys?” A VC answers “what has an authority claimed about this subject, and can I trust it?” You can have a DID with zero credentials attached (an identifier with no attestations yet). You can also have a VC that references a plain HTTPS URL or a UUID instead of a DID, since the VC Data Model doesn’t mandate DIDs at all. In practice, though, most production systems pair them, because a DID gives a credential’s proof section something stable and resolvable to check against.

Here’s the quick reference worth pinning to your architecture doc:

Dimension	Decentralized Identifier (DID)	Verifiable Credential (VC)
Purpose	Identify a subject or controller	Assert a claim about a subject
Typical actor	Any entity: person, org, device	Issuer creates it, holder carries it
Storage	DID document on a registry or ledger	Wallet (edge) or credential repository (cloud)
Discovery	DID resolution to a DID document	Presented directly by the holder
Proof type	Verification methods (keys) in the document	Linked Data Proof, JWT, or ZKP-derived proof
Privacy model	Identifier can be pairwise/pseudonymous	Selective disclosure of claim fields

A DID looks like this in the wild: did:web:ditgold.com. A VC payload, by contrast, carries structured fields: an issuer, a credentialSubject object holding the actual claim, and a proof block with the signature. One is an address. The other is a signed letter mailed to that address.

The rule of thumb: adopt a DID when you need an identifier that outlives any single platform or app. Adopt a VC when you need a portable, verifiable claim that a third party can check without calling the issuer directly. Adopt both when you’re building anything resembling KYC, credentialing, or supply chain provenance, which is most of what shows up later in this piece.

What Do DID Documents and VC Fields Actually Contain?

Specs matter here because the informal explanations that circulate online tend to blur field names and responsibilities. Getting this wrong means shipping a verifier that silently accepts malformed data.

A DID is a URI with three parts: the scheme (did), the method (web, key, ion, etc.), and a method-specific identifier. Resolving that DID return a DID document, a JSON structure with a defined set of fields:

id: the DID itself, restated inside the document
verificationMethod: an array of public keys and their types, used to check signatures
authentication, assertionMethod, keyAgreement: pointers into verificationMethod that scope which keys can be used for which purpose
service: optional endpoints, such as a DIDComm messaging service or a credential status endpoint

That assertionMethod field is the one that matters most for VCs: it tells a verifier exactly which key the issuer is allowed to use for signing claims, separate from keys used for authentication or key agreement. Miss that distinction and you risk accepting a credential signed with a key that was never authorized for issuance.

A Verifiable Credential, per the W3C Verifiable Credentials Data Model v2.0, has its own required and recommended fields:

type: declares the credential as a VerifiableCredential plus any subtype (e.g., KYCCredential)
issuer: the identifier of the entity making the claim, frequently a DID but sometimes an HTTPS URL
credentialSubject: the actual claim data, keyed to a subject identifier
proof: the cryptographic signature, its type, and the verification method it references
credentialStatus: optional, points to a revocation mechanism

Pro Tip: Don’t assume issuer and credentialSubject.id are always DIDs. The spec explicitly allows plain UUIDs or HTTPS URLs, which matters if you’re integrating with legacy identity systems that haven’t adopted DIDs yet.

One detail that trips up new implementers: a single DID document can list multiple verification methods, some for authentication, some for signing credentials, and some for encrypted key agreement. Treating verificationMethod as one undifferentiated bag of keys is a common source of subtle authorization bugs. The ACM’s analysis of DID and VC adoption flags exactly this kind of field misuse as a recurring source of interoperability failures across early implementations.

How Does the Issuance-to-Verification Workflow Work?

Every VC system, regardless of industry, runs through the same four-role sequence. Knowing the sequence cold makes debugging integration failures dramatically faster.

Issuer creates and signs the VC. The issuer builds a credentialSubject payload, signs it with a key referenced in their DID document’s assertionMethod, and transmits it to the holder.
Holder stores the VC. The holder’s wallet, whether an edge app or a cloud service, persists the credential and its proof for later use.
Holder creates a Verifiable Presentation (VP). When a verifier asks for proof of something, the holder wraps the relevant VC (or a derived, selectively disclosed version of it) inside a VP, signs the presentation itself, and sends it.
Verifier checks the presentation. This means resolving the issuer’s DID, confirming the proof against the correct verification method, checking the credential hasn’t expired or been revoked, and confirming the presentation itself was signed by the expected holder.

Transport is where implementations diverge. DIDComm suits peer-to-peer wallet-to-wallet exchanges where both parties maintain long-lived DIDs. OIDC4VC (OpenID for Verifiable Credentials) fits scenarios where you want to bolt VC issuance and presentation onto existing OAuth/OIDC infrastructure, which is increasingly the pragmatic choice for teams that already run identity providers. Plain HTTPS with a defined API contract works fine for simpler, closed-ecosystem deployments where you control both issuer and verifier code.

Pro Tip: If your team already runs an OIDC identity provider, OIDC4VC is almost always the fastest path to a working pilot, since it reuses token endpoints and scopes your developers already understand instead of building a DIDComm agent from scratch.

A verifier that skips status checks isn’t really verifying anything beyond “this signature is mathematically valid at some point in time.” W3C’s own verification guidance is explicit that format validation, proof verification, and credential status checks are three separate steps, and a robust verifier implementation needs all three, not just the cryptographic check.

Which DID Method Should You Actually Use?

The DID specification defines the syntax and document model, but it deliberately leaves the “method” open, meaning anyone can define how a specific DID scheme gets created, resolved, updated, and deactivated. This is both the spec’s greatest strength and its biggest operational headache.

did:key: The simplest method. The identifier is derived directly from a public key, with no external registry needed. Great for ephemeral or test scenarios; poor for key rotation, since rotating the key means the DID itself changes.
did:web: Resolution happens over plain HTTPS, hosted at a domain you control. Fast to deploy and easy to debug, but it inherits DNS and web hosting as a trust dependency, which some architects consider a step back toward centralization.
did:ion: An implementation of the Sidetree protocol anchored to Bitcoin. It offers strong decentralization guarantees and supports key rotation without changing the identifier, at the cost of higher operational complexity and slower resolution in some deployments.
KERI-based methods (did:webs, did:tow): Key Event Receipt Infrastructure decouples identifier control from any single ledger, using cryptographic key event logs instead. These methods are gaining traction where long-term key rotation history matters more than ledger anchoring.

Resolving any of these consistently is where the Universal Resolver earns its keep: it’s a widely used interoperability layer that lets a verifier query multiple DID methods through one interface instead of writing a custom resolver per method. Most production ecosystems still define an explicit interoperability profile limiting which methods they’ll accept, because “support any DID method” is a much bigger promise than most verifier codebases can responsibly keep.

Key rotation deserves its own line item in your risk assessment. did:key can’t rotate without changing the identifier. did:web rotates as easily as updating a JSON file, which is convenient but only as secure as your web server. did:ion and KERI-based methods support rotation with full historical accountability, which matters most in regulated or long-lived credential scenarios.

Linked Data Proofs, JWT Proofs, and Zero-Knowledge Options

The proof format you choose shapes verifier complexity, wallet compatibility, and how much data a holder is forced to expose. Get this decision wrong early and you’ll be re-issuing credentials across your entire user base later.

Linked Data Proofs embed the signature directly inside the JSON-LD credential structure, preserving rich semantic meaning about what each field represents. They’re expressive and self-describing but require verifiers to handle JSON-LD canonicalization correctly, which has historically been a source of implementation bugs.

JWT proofs wrap the credential as a signed JSON Web Token, trading semantic richness for compatibility with the enormous existing ecosystem of OAuth and OIDC tooling. If your verifiers already parse JWTs for other purposes, this format cuts integration time significantly.

Zero-knowledge proofs (ZKPs) let a holder generate a derived claim, like “this person is over 21,” without revealing the underlying birthdate at all. According to GS1’s technical landscape report, UK-based presentation schemes preserve considerably more privacy than schemes that reveal full credential fields, since the verifier never sees data beyond what the derived claim strictly requires.

Selective disclosure isn’t exclusive to ZKPs, either. The emerging SD-JWT specification lets issuers structure a JWT-based credential so holders can reveal only specific claims from within it, without needing a full ZKP circuit.

For revocation, three patterns dominate: status lists (a bitstring the verifier checks against an index), registries (a queryable service that returns current status), and blockchain anchoring (status changes recorded on a public ledger for tamper resistance). Each trades off verifier complexity against issuer control and query privacy.

Before shipping any verifier, run this checklist:

Does it validate the credential’s structural format against the expected schema?
Does it resolve the issuer’s DID and confirm the correct verification method?
Does it check credential status against the declared revocation mechanism?
Does it confirm the presentation itself, not just the underlying credential, is properly signed?

What Should You Watch for in Production Deployments?

Most DID and VC pilots work fine in a demo and then fall apart at scale, usually for the same handful of reasons.

Wallet architecture is the first fork in the road. Edge wallets, where keys live on the holder’s own device, give users direct control and reduce your liability for custody, but they push key recovery entirely onto the user, which is a genuine usability problem if someone loses their phone. Cloud wallets simplify recovery through familiar account recovery flows but reintroduce a centralized custodian your architecture was arguably trying to avoid in the first place. Most production systems land on a hybrid: device-bound keys with a social or institutional recovery mechanism as a backstop.

Pro Tip: Test your key recovery flow before you test your issuance flow. Teams routinely build elegant issuance pipelines and only discover the recovery gap after a real user loses a device in production.

Encoding choice ripples through your whole stack. JSON-LD gives you semantic interoperability across ecosystems that don’t share a schema registry, at the cost of canonicalization overhead. JWT-based credentials integrate faster with existing web infrastructure but carry less inherent semantic meaning, meaning your schema governance has to do more of the work that JSON-LD context files would otherwise handle automatically.

A few operational habits separate resilient deployments from fragile ones:

Run resolver redundancy, not a single Universal Resolver instance, since resolution downtime blocks every verification in your pipeline.
Monitor revocation and status endpoints separately from your main verification uptime metrics, since a status service outage silently makes every credential look valid.
Establish a written trust framework for which issuers your verifiers accept by default, rather than letting that list grow ad hoc through support tickets.
Run interoperability tests against at least two independent implementations of whatever DID method and proof format you choose, since the ACM’s research on DID and VC adoption documents recurring cross-implementation inconsistencies even among spec-compliant libraries.

Governance is the part engineering teams underinvest in the most. A trust framework isn’t just a legal document; it’s the operational answer to “which issuers do our verifiers trust by default, and what happens when one gets compromised?” Skipping that conversation until after launch is how ad hoc trust models become permanent liabilities.

Where Do DIDs and VCs Actually Get Used?

Abstract specs earn their keep once you map them onto real deployment scenarios. Four patterns cover most of what teams are building right now.

Supply chain provenance: An organization holds a DID; a certifying body issues a VC attesting to a batch’s origin or compliance status. Verifiers along the chain check the VC’s proof against the certifier’s DID document rather than calling the certifier’s database directly, which is the pattern the GS1 technical landscape report documents extensively for goods traceability.
Privacy-preserving KYC: A financial institution issues a VC attesting a user passed identity verification. Later, that user presents a selectively disclosed derivative, proving “verified” status without re-exposing the underlying documents each time.
Academic credential portability: A university issues a VC for a degree, tied to the student’s DID. Years later, an employer verifier checks the credential’s proof against the university’s DID document without ever contacting the registrar’s office.
IoT device identity: A device gets its own DID at manufacture time, and VCs attached to that DID assert firmware version, certification status, or manufacturer claims that other devices or gateways can verify autonomously.

Each of these reduces to the same underlying pattern: an organizational or individual DID anchors the trust root, and a VC carries the specific claim that needs checking. The scenarios differ mainly in who issues, who holds, and how often the claim needs re-verification.

Why Do So Many DID and VC Projects Stall?

The technology rarely fails because the cryptography is weak. It stalls because of three practical friction points that show up in nearly every deployment attempt.

Wallet usability is the biggest one. Asking non-technical users to manage private keys, understand recovery phrases, and grasp what a “presentation” even means is a genuinely hard UX problem that most teams underestimate until real users start losing access to credentials. DID method fragmentation compounds this: if your ecosystem partners choose different methods with incompatible resolution requirements, every integration becomes a custom project instead of a standard one.

Wallet UX and key recovery remain the most cited barriers to mainstream adoption, according to academic analysis of DID and VC deployments.
DID method fragmentation forces ecosystems to publish explicit interoperability profiles rather than accepting “any compliant DID.”
Bootstrapping issuer trust without a pre-existing legal or institutional relationship is still largely unsolved at scale.

Given those constraints, it’s worth asking honestly whether your use case needs DIDs and VCs at all, versus a mature federated identity approach like OIDC. If your trust relationships are already centralized (a single employer, a single financial institution, a closed partner network), OIDC federation will get you to production faster with less risk. DIDs and VCs earn their complexity when you need portability across organizational boundaries that don’t already trust each other, or when you need a holder to control their own credentials independent of any single issuer’s platform.

A sensible phased path: issue VCs against your existing identifiers first, even centralized ones, to validate the claim schema and verifier logic. Introduce DIDs once you’ve confirmed the credential model works and you actually need cross-organizational portability. Building the full decentralized identifier stack before proving out the credential logic is how promising pilots die in committee.

How Ditgold Applies DIDs and VCs to Data Asset Verification

Data marketplaces face a version of this same trust problem: how do you verify where a dataset came from, who’s licensed to sell it, and who’s cleared to buy it, without building a centralized gatekeeper that undermines the entire point of decentralization? Ditgold’s approach treats DIDs as the identity layer for marketplace participants, buyers, sellers, and validation agents alike, while VCs carry the specific claims that matter: dataset provenance, licensing terms, and compliance attestations tied to tokenized data assets like DitAu.

Selective disclosure is the piece that makes privacy-first KYC actually workable at marketplace scale. A participant can prove they’ve cleared identity verification without re-exposing raw documents to every counterparty they transact with, echoing the same derived-claim pattern used in age verification and financial KYC elsewhere in this article. That pattern underpins how Ditgold’s privacy KYC tool is designed to work: verify once, present a minimal proof repeatedly.

For dataset provenance specifically, VCs anchored to organizational DIDs let a buyer verify a dataset’s origin and licensing chain without trusting a single centralized registry, a pattern explored further in Ditgold’s dataset verification methods coverage and its broader decentralized data marketplace architecture. If you’re evaluating how tokenized data assets get valued once provenance and licensing are verifiable on-chain, Ditgold’s data asset tokenization guide walks through that connection in more depth.

Specs and Research Worth Reading Next

Start with the primary sources rather than secondary summaries, since DID method behavior and VC field requirements change with spec revisions. The W3C Verifiable Credentials Data Model v2.0 is the normative reference for VC fields and verification expectations. GS1’s technical landscape report frames real industry deployments and DID method tradeoffs in more operational detail than the specs alone provide. For a clear-eyed look at where the technology still struggles, the ACM’s analysis of DID and VC limitations is the most candid academic treatment available. If your architecture needs selective disclosure over JWTs specifically, the SD-JWT draft is worth tracking as it matures.

The Real Lesson Behind the DID vs VC Debate

The conventional explainer treats DIDs and VCs as a matched pair you must adopt together, and that framing does readers a disservice. The research is clear that they’re independent standards, and plenty of working systems use VCs without DIDs at all, anchoring proofs to plain HTTPS identifiers instead. Engineers who internalize that independence design more flexible systems, ones that can start with credentials on existing identity infrastructure and add decentralized identifiers later, once the actual need for cross-organizational portability shows up.

What’s underrated is how much of the real difficulty sits in wallet UX and key recovery, not cryptography. The math has worked for years. What hasn’t matured nearly as fast is the operational discipline: resolver redundancy, revocation monitoring, and honest governance over which issuers a verifier trusts by default.

If you’re building anything resembling verifiable data provenance or licensing, prioritize the credential schema and verifier logic before you commit to a DID method. Get the claims right first. The identifier layer can catch up once you know what you’re actually trying to prove.

— Greg