A Verifiable Credential Example, Annotated Field by Field

The example credential

Here is an employment credential that a former employer might issue to a backend engineer when they leave. It follows the W3C Verifiable Credentials Data Model 2.0, which became a W3C Recommendation on 15 May 2025, and is secured with a Data Integrity proof. Domains use the reserved .example suffix, and the long key and signature values are shortened, so treat it as a teaching copy rather than something to paste into production.

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "urn:uuid:4a1c7f0e-2b8d-4c6a-9e51-7d3f0b2a9c11",
  "type": ["VerifiableCredential", "EmploymentCredential"],
  "issuer": {
    "id": "did:web:issuer.example",
    "name": "Example Labs"
  },
  "validFrom": "2026-06-30T00:00:00Z",
  "validUntil": "2031-06-30T00:00:00Z",
  "name": "Employment record",
  "description": "Confirms role and dates of employment at Example Labs.",
  "credentialSubject": {
    "id": "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH",
    "employment": {
      "role": "Senior Backend Engineer",
      "startDate": "2022-03-01",
      "endDate": "2026-06-30"
    }
  },
  "credentialSchema": {
    "id": "https://issuer.example/schemas/employment.json",
    "type": "JsonSchema"
  },
  "credentialStatus": {
    "id": "https://issuer.example/status/3#94567",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "revocation",
    "statusListIndex": "94567",
    "statusListCredential": "https://issuer.example/status/3"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "created": "2026-06-30T09:12:44Z",
    "verificationMethod": "did:web:issuer.example#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z58DAdFfa9SkqZMVPxAQpic7ndSayn1PzZs6ZjWp1CktyGes..."
  }
}

Field by field

Every property below is defined by the W3C specification or its companion specs. Only four are required: @context, type, issuer, and credentialSubject. A credential also needs a securing mechanism, here the embedded proof, before anyone can call it verifiable.

What the candidate sends: a verifiable presentation

A hiring team rarely receives the bare credential. The candidate's wallet wraps it in a verifiable presentation and signs that wrapper with the candidate's own key:

{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "type": ["VerifiablePresentation"],
  "holder": "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH",
  "verifiableCredential": [ "...the signed credential above, unchanged..." ],
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "verificationMethod": "did:key:z6MkpTHR8VNs...#z6MkpTHR8VNs...",
    "proofPurpose": "authentication",
    "challenge": "8f2b6c1e-one-time-value-from-the-verifier",
    "domain": "https://careers.employer.example",
    "proofValue": "z3FXQjecWufY46yg5abdVZsXqLhxhueuSoZgNSARiKBk..."
  }
}

Three details do the work. holder matches the credentialSubject id, so the person presenting is the person the claims are about. proofPurpose is authentication rather than assertionMethod, because the candidate is proving control of a key, not making claims. challenge and domain are values the verifier supplied for this session; Data Integrity defines them to stop a captured presentation being replayed somewhere else.

What the verifier checks, in order

1. Shape. Parse the JSON, confirm the v2 context comes first, confirm the type values, and optionally validate the claims against credentialSchema.
2. Issuer key. Resolve did:web:issuer.example, find key-1, and confirm it is listed under assertionMethod in the DID document. A key listed only for authentication should not be accepted for issuing.
3. Issuer signature. Recompute the signed data and check proofValue against that public key. Any edited character, such as a changed endDate, breaks the check.
4. Validity window. Confirm the current time falls between validFrom and validUntil.
5. Status. Fetch the status list credential, verify its own proof, and read bit 94567. The list covers many credentials, so the fetch does not reveal which one is being checked.
6. Presentation. Verify the holder's signature, confirm challenge and domain match what this verifier issued, and confirm holder equals credentialSubject.id.
7. Validation. Decide whether this issuer is trusted to make employment claims. The specification separates this business judgement from cryptographic verification.

What the example does not prove

The specification states plainly that verifiability does not imply the claims are true. This credential proves that whoever controls issuer.example signed a statement that the subject held a role between two dates. It does not prove the engineer was good at the job, or that issuer.example is a real company rather than a domain registered last week. That last gap is why step 7 exists, and why teams that accept credentials keep a list of issuers they trust for each kind of claim.

Variations you will meet

• Version 1.1 credentials use the https://www.w3.org/2018/credentials/v1 context with issuanceDate and expirationDate. Many systems still emit them.
• JOSE or COSE secured credentials carry the same claims but are signed as a JWT or CBOR envelope instead of an embedded proof block, under the W3C VC JOSE COSE specification.
• SD-JWT credentials hash each claim so the holder can reveal only some of them, for example dates without the job title.
• Open Badges 3.0, from 1EdTech, builds course and skill badges on the verifiable credentials data model, so badge platforms can emit credentials shaped much like this one.