Verifiable Credentials vs DIDs: What Each One Does
A DID (decentralized identifier) is an identifier, such as did:web:university.example, that resolves to a document listing public keys. A verifiable credential is a signed set of claims about a subject. A DID answers who holds which key; a credential answers what someone vouched for. Credentials often use DIDs, but neither requires the other.
The one-line difference
A DID is a name with a public key attached. A verifiable credential is a signed letter. You need to know whose key signed the letter before the signature means anything, which is why the two specifications are so often used together, and why people searching for one keep running into the other.
What a DID is
A decentralized identifier is a URI with three parts: the did: scheme, a method name, and a method-specific identifier, as in did:web:university.example. A resolver turns it into a DID document listing verification methods (public keys), which keys may be used for authentication or for making assertions, and optional service endpoints.
The method decides where that document lives. did:web serves it over HTTPS from the named domain, so control of the DID follows control of the domain. did:key encodes the public key in the identifier itself, so it needs no registry but cannot be updated. Other methods anchor documents on blockchains or other ledgers.
DID Core 1.0 has been a W3C Recommendation since 19 July 2022. Version 1.1 was published as a Candidate Recommendation in March 2026, according to the W3C.
What a verifiable credential is
A verifiable credential is a set of claims, such as a degree awarded or a role held, that an issuer makes about a subject and secures with a cryptographic proof. It has an issuer, a credentialSubject, optional validity dates and status information, and a proof. The W3C Verifiable Credentials Data Model 2.0 became a Recommendation on 15 May 2025.
How they work together
Take a university that issues a degree credential. Its issuer field is did:web:university.example, and that DID resolves to a document like this:
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/multikey/v1"
],
"id": "did:web:university.example",
"verificationMethod": [{
"id": "did:web:university.example#key-1",
"type": "Multikey",
"controller": "did:web:university.example",
"publicKeyMultibase": "z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2"
}],
"assertionMethod": ["did:web:university.example#key-1"]
}
The credential's proof names did:web:university.example#key-1 as its verificationMethod. A verifier resolves the DID, finds key-1, confirms it is listed under assertionMethod, and checks the signature with it. The graduate's own DID sits in credentialSubject.id. When the graduate later sends the degree to an employer, they sign the presentation with a key listed under authentication in their DID document, proving they are the subject rather than someone holding a copy.
Using one without the other
The VC specification allows any URL as an issuer, so an organisation can issue credentials identified by an ordinary HTTPS URL and publish keys another way. In the other direction, DIDs are used for sign-in and for signing messages with no credential involved. What a DID cannot do alone is say anything about its controller. A brand-new DID with no credentials attached is as anonymous as a fresh wallet address.
What this means for hiring teams
The practical risk sits at the issuer DID. did:web inherits trust from the domain, so a verifier can ask whether university.example really is the university. A did:key carries no such link, so an issuer using one needs to be confirmed out of band or through a trust registry. A candidate's DID proves only that the same person controls the same key across presentations; tying that key to a real person still takes a credential from someone who checked.
| Aspect | DID | Verifiable credential |
|---|---|---|
| What it is | An identifier that resolves to a DID document | A signed set of claims about a subject |
| Question it answers | Who is this, and which key is theirs? | What has an issuer vouched for? |
| Example | did:web:university.example | A degree credential issued by that DID |
| Main contents | Keys, key purposes, service endpoints | Issuer, subject, claims, validity, status, proof |
| Who creates it | The controller, often for themselves | An issuer, about someone else |
| Changes over time | Keys can be rotated if the method allows | Fixed once signed; withdrawn via status lists |
| W3C standard | DID Core 1.0 Recommendation, 2022 | VC Data Model 2.0 Recommendation, 2025 |
| Useful alone? | For authentication and signing | Yes, with an issuer key found another way |
Frequently asked questions
- Do you need a DID to issue verifiable credentials?
- No. The VC Data Model lets an issuer be identified by any URL, and credentials secured with JOSE or COSE signatures can rely on keys published by other means. DIDs are popular because they give issuers and holders a standard way to publish and rotate keys, and because did:web is easy to set up on a domain an organisation already controls.
- Are DIDs stored on a blockchain?
- Some are, many are not. The DID method decides. did:web documents are ordinary files served over HTTPS, and did:key needs no storage at all because the key is encoded in the identifier. Ledger-based methods write DID documents or their updates to a blockchain, which helps with update history but means the records are public and hard to remove.
- Is a DID the same as a digital identity?
- Not on its own. A DID is an identifier with keys, so it proves continuity: the same controller across interactions. Identity in the everyday sense, a named person with a history, comes from credentials that issuers attach to that DID, such as a government ID, a degree, or an employment record. Without those, a DID says nothing about who controls it.