What is a verifiable credential?

The W3C Verifiable Credentials Data Model v2.0, published as a W3C Recommendation on 15 May 2025, describes credentials in terms of roles that any person, organisation or device can play:

• Issuer. Makes claims about one or more subjects, turns them into a verifiable credential, and gives it to a holder. A university issuing a degree or an employer issuing a staff badge are examples.
• Holder. Possesses one or more credentials, keeps them in a wallet or other store, and presents them. The holder is often, but not always, the subject the claims are about.
• Verifier. Receives a credential, or a presentation built from credentials, and checks it. Other specifications call this the relying party.

A fourth role, the verifiable data registry, covers wherever identifiers, keys, schemas and revocation lists are published.

The spec defines a verifiable credential as a tamper-evident credential whose authorship can be cryptographically verified. In practice that means a digital signature or a similar proof from the issuer.

A credential is a set of claims made by one issuer, plus metadata. The data model defines properties for:

• the issuer, identified by a URL, which can be a decentralised identifier (DID);
• the credentialSubject, holding the claims themselves;
• a validity window, through validFrom and validUntil;
• optional credentialStatus, which points to where a verifier can find out whether the credential has been suspended or revoked;
• the proof that secures it.

The spec recognises two ways to secure a credential. An embedded proof sits inside the credential; the W3C Data Integrity specification defines one, and the spec’s own example uses an EdDSA cryptosuite. An enveloping proof wraps the whole credential, as the W3C JOSE and COSE securing specification does. Both let a verifier check the issuer’s signature against the issuer’s public key.

Instead of handing over a raw credential, a holder can build a verifiable presentation from one or more credentials and share it with a specific verifier. Presentations add something the credential alone cannot give: evidence that the presenter is taking part now.

The data model warns that it does not on its own prevent replay. Its example is an event ticket presented by several people, all admitted on the same credential. The defence it lists is a challenge supplied by the verifier and included in the presentation, with the verifier refusing any challenge it has already seen. The Data Integrity specification provides challenge and domain properties for this, the domain tying a proof to the security domain it was made for. This is challenge-response authentication applied to credentials.

Verification, as the spec defines it, means checking that the credential conforms to the data model, that its securing mechanism is satisfied, and, if a status entry is present, that the status check succeeds. The first two need only the credential and the issuer’s public key, so a verifier that already holds the key can do them offline.

The status check is where offline use gets harder. The Bitstring Status List specification has an issuer publish a compressed list in which each credential has a position, and recommends that verifiers cache the list they retrieve. A verifier that refreshed its copy before going offline can still check status, but only as of that copy. A revocation published since then is invisible to it until it syncs again.

Two further limits come from the data model itself:

• Verification is not truth. The spec states that verifying a credential does not imply evaluating the truth of its claims. Whether to rely on a given issuer for a given claim is the verifier’s own business rule.
• Possession is not authorisation. The data model does not include a way to establish that the holder is authorised to present the claims. It suggests binding credentials to strong authentication or adding proof of control in the presentation.

The W3C model is one format for an issuer-signed credential. Others follow the same idea with different encodings. Mobile driving licences use the ISO mdoc format, and ISO/IEC 18013-5:2021 covers proximity presentment, where a phone presents the credential to a nearby reader. The Multipaz libraries from the OpenWallet Foundation implement that, alongside the IETF SD-JWT VC format.

Verifiable credentials are often discussed together with self-sovereign identity, where people hold their own credentials and choose what to present. The data model supports that but does not require it. An app can also use credentials purely so that a field device can check a signed statement with no server to ask.