W3C Verifiable Credentials, Explained in Plain English

Every time you upload a passport photo to yet another app, you are working around a missing piece of internet infrastructure: there has never been a standard way to prove something about yourself online. W3C Verifiable Credentials are the most serious attempt yet to fix that. Here is what they actually are, stripped of the buzzwords.

What a verifiable credential actually is

A verifiable credential (VC) is a set of claims about a subject ("this person is over 18", "this person passed a KYC check", "this person holds a driver's license") packaged together and digitally signed by whoever made the claims. The signature is the whole point. Anyone who receives the credential can check, mathematically, that it was issued by a specific party and that nothing in it has been altered since.

Think of it as the digital equivalent of a tamper-evident document. A paper diploma derives its credibility from the seal and the letterhead; a VC derives its credibility from a cryptographic signature that is far harder to forge and far easier to check.

The W3C standardizes the data model (what a credential looks like, what fields it carries, how proofs attach to it) so that credentials issued by one system can be understood by another. That interoperability is what separates VCs from every proprietary "digital ID" that came before.

The triangle: issuer, holder, verifier

The VC model has three roles, and the relationships between them explain most of its design:

• Issuer is the party that makes and signs the claims. A government issuing a digital ID, a bank attesting that it completed identity verification, a university issuing a diploma.
• Holder is the person (or organization) the claims are about, who stores the credential in a wallet they control.
• Verifier is any party that needs to check a claim. An exchange checking your KYC status, a website checking your age, an employer checking your degree.

The critical structural shift is that the holder sits in the middle. In today's identity systems, verifiers query issuers (or data brokers) directly, and you are mostly a bystander to transactions about your own identity. In the VC model, the credential lives with you, and you decide when and where to present it.

Verification without phoning home

Here is the part that surprises people: the verifier never needs to contact the issuer to check a credential.

When an issuer creates a credential, it signs the contents with its private key. The issuer's corresponding public key is published somewhere discoverable, often via a decentralized identifier (DID) or a well-known web endpoint. When a verifier receives a credential, it fetches that public key and checks the signature locally. If the math works out, the credential is authentic and intact. If a single byte was changed, the check fails.

This has two big consequences. First, verification works at internet scale without the issuer running a high-availability "ask me about this person" API. Second, the issuer doesn't learn where you use your credential. Your bank doesn't get a ping every time you prove your identity to a third party. That property, no phone-home, is one of the strongest privacy arguments for the model.

VC Data Model 2.0: where the standard sits today

The Verifiable Credentials Data Model 2.0 became a W3C Recommendation in 2025, the W3C's highest maturity level, meaning the spec is considered stable and ready for broad implementation. Version 2.0 tightened up the original 1.1 model: a cleaner core data model, better-defined securing mechanisms, and clearer guidance on how credentials are represented and proved.

In practice, the ecosystem around VCs is a family of specifications rather than one document: the data model itself, proof formats, exchange protocols like OpenID for Verifiable Credentials (OID4VC), and related formats such as SD-JWT for selective disclosure. You don't need to memorize the acronyms; the takeaway is that the stack is standardized, layered, and openly specified.

What happens when a credential needs to be revoked

Signatures prove a credential was valid when issued. But what if the issuer needs to invalidate it later? A license gets suspended, a KYC check is superseded, an employee leaves a company.

The standard answer is a status list. Conceptually, the issuer publishes a long compressed list of bits, one position per issued credential. Each credential carries a pointer to its position. A verifier fetches the list, checks the bit at that position, and knows whether the credential is still good.

The privacy trick is herd anonymity: the verifier downloads the whole list, not a per-credential record, so the issuer can't tell which credential is being checked. Revocation works without recreating the phone-home problem.

What verifiable credentials are not

Two misconceptions come up constantly, so let's clear them.

• VCs do not require a blockchain. The data model is deliberately neutral about where issuer keys are published. Some deployments use distributed ledgers for key discovery; many use plain HTTPS endpoints. The cryptography that makes a credential verifiable is ordinary digital signatures, not tokens or chains.
• VCs are not self-attested. You can't write yourself a credential saying you're a licensed physician. Or rather, you can, but it would be signed by you, and no verifier trusts claims signed by their own subject. The trust in a credential comes entirely from who issued it. The model moves data custody to the holder, not the authority to make claims.

Why adoption is finally happening

Verifiable credentials have existed as a concept for years. What changed is that governments started shipping them.

The biggest driver is the European Union: under eIDAS 2.0, every member state must offer citizens a digital identity wallet, and the EUDI Wallet architecture is built on the same open-standards stack: verifiable credentials, OID4VC protocols, selective disclosure formats. That regulatory pull turns VCs from a niche technology into required infrastructure for anyone doing business in Europe.

In parallel, mobile driver's licenses are rolling out in a growing number of US states and other countries using the ISO mdoc/mDL standard, a sibling format with the same issuer-holder-verifier structure and the same cryptographic verification model. The formats differ in encoding details, but the architecture is converging, and most serious wallets and verifiers are building for both.

The pattern is familiar from payments and messaging: once open standards plus regulatory pressure align, adoption stops being a question of if.

Where OpenKYC fits

OpenKYC is building a reusable KYC marketplace on these open standards (W3C Verifiable Credentials, OpenID4VC): verify once, hold the credential in your own wallet, reuse it everywhere, and earn every time it's used. Join the waitlist at openkyc.org.