Verifiable Credentials Guide: VCs, DIDs and SD-JWT

Verifiable credentials let any organisation check a signed claim about a person, company or device without calling the issuer, but only if the verifier knows which formats, keys, status lists and issuers to trust. The standards have settled quickly: the W3C Verifiable Credentials Data Model 2.0 and Bitstring Status List became Recommendations in May 2025, OpenID for Verifiable Presentations and OpenID for Verifiable Credential Issuance reached final status later that year, and SD-JWT is now RFC 9901. Europe's wallets are due by the end of 2026. This guide explains the data model, decentralised identifiers, the competing credential formats, issuance and presentation protocols, revocation, trust registries and privacy, and what an enterprise should actually build. It is for architects, IAM and CIAM engineers and product owners who issue or accept credentials; the wallet and regulatory view is in the Digital Identity Wallets Guide.

Key takeaways

• Verification is not validation. Cryptographic checks prove a credential is authentic and current; whether the issuer is trusted for that claim is a separate, policy decision the verifier must make and document.
• There is no single format. W3C VCDM 2.0, IETF SD-JWT VC and ISO mdoc all have real deployments. Verifiers should expect to accept more than one and abstract the differences behind a policy layer.
• Holder binding and status checks are where implementations cut corners. A credential without proof of key possession is a bearer token, and a skipped status check accepts revoked credentials.
• Trust lives in registries and governance, not in DIDs. A DID or certificate tells you which key signed; a trust list or framework tells you whether that signer may assert the claim.
• Privacy has to be designed in. Selective disclosure hides attributes, but stable identifiers, reused signatures and status lookups can still correlate a holder across verifiers.

The model: issuer, holder, verifier

The W3C Verifiable Credentials Data Model v2.0 (Recommendation, 15 May 2025) defines a verifiable credential as "A tamper-evident credential whose authorship can be cryptographically verified." Five roles appear in the model.

• Issuer: asserts claims about one or more subjects, creates the credential and sends it to the holder. Examples: a government, university, bank, employer or identity verification provider.
• Holder: possesses credentials, usually in a wallet, and generates verifiable presentations from them. The holder is often, but not always, the subject.
• Subject: "A thing about which claims are made": a person, an organisation, a device or a software agent.
• Verifier: receives credentials, usually inside a presentation. OpenID and eIDAS documents call it a relying party.
• Verifiable data registry: any system that mediates identifiers, keys, schemas and revocation data, from a DNS-hosted DID document to a national trust list.

A VCDM 2.0 credential must carry @context (first entry https://www.w3.org/ns/credentials/v2) and type, and typically issuer, credentialSubject, validFrom, validUntil, credentialStatus and credentialSchema. The media types are application/vc and application/vp. The specification separates two checks that products often blur. Verification is "The evaluation of whether a verifiable credential or verifiable presentation is an authentic and current statement": conformance, signature and status, not the truth of the claims. Validation is whether a claim from a specific issuer satisfies the verifier's business requirements, which the specification leaves to the verifier.

Decentralised identifiers and issuer keys

Decentralized Identifiers (DIDs) v1.0 has been a W3C Recommendation since 2022; v1.1 was a Candidate Recommendation Snapshot in March 2026. A DID is a URI of the form did:<method>:<method-specific-id> that resolves to a DID document holding verification methods (public keys) and verification relationships such as authentication and assertionMethod. Each DID method defines how to create, resolve, update and deactivate identifiers.

• did:web: the DID document is served over HTTPS from the issuer's domain. Easy to adopt, and trust reduces to DNS and web PKI, which most enterprises already manage.
• did:key: the public key is encoded in the identifier itself. Useful for holder keys and tests; it cannot be rotated, so it is a poor choice for long-lived issuer identity.
• Ledger and event-log methods: methods anchored in distributed ledgers or key event logs add rotation history without a central host, at the cost of resolver infrastructure. GLEIF's vLEI ecosystem uses KERI-based Autonomic Identifiers for organisations and their officials.
• Not DIDs at all: SD-JWT VC issuers publish keys through JWT VC Issuer Metadata at /.well-known/jwt-vc-issuer or carry an X.509 chain in the x5c header, and ISO mdoc uses issuer certificates. Many large ecosystems use X.509 because it fits existing trust lists.

Whatever the identifier, the issuer's signing key is the single most valuable asset in the system. Hold it in an HSM, rotate it on a schedule and plan for emergency revocation. See the Cryptographic Key Management Guide.

Credential formats compared

Choosing a format: follow your ecosystem. A verifier in the EU wallet ecosystem or accepting mobile driving licences needs mdoc and SD-JWT VC. Education, professional and supply chain credentials often use VCDM 2.0. If you are the issuer and no ecosystem dictates the choice, SD-JWT VC is simplest for teams that already run JWT infrastructure; VCDM with Data Integrity suits linked-data use cases and unlinkable BBS proofs.

Issuance and presentation protocols

OpenID for Verifiable Credential Issuance 1.0

OpenID4VCI (final, 16 September 2025) is an OAuth 2.0-protected API: the wallet is the client and the credential issuer is a resource server. Issuers publish metadata at /.well-known/openid-credential-issuer and start issuance with a Credential Offer.

• Authorization code flow: the user authenticates to the issuer and consents. Use it when the issuer can authenticate the user strongly at issuance time.
• Pre-authorized code flow: the issuer has already established the user (for example after onboarding) and sends a code that "MUST be short lived and single use". Add a transaction code (tx_code) sent over a separate channel, otherwise whoever intercepts the offer QR code receives the credential.
• Proof of possession: the wallet proves control of the key to be bound, with the issuer as audience and a fresh c_nonce from the Nonce Endpoint. Key attestations and wallet attestations let the issuer require hardware-backed keys from approved wallets.

OpenID for Verifiable Presentations 1.0

OpenID4VP (final, 9 July 2025) adds a vp_token response to OAuth 2.0. Verifiers express requests in the Digital Credentials Query Language (DCQL); earlier drafts used DIF Presentation Exchange and its presentation definitions, which you will still meet in older deployments. It supports SD-JWT VC, ISO mdoc and W3C credentials.

• Verifier identification: client identifier prefixes such as x509_san_dns, x509_hash, verifier_attestation, decentralized_identifier and openid_federation let the wallet authenticate the verifier and show the user who is asking. Requests using the redirect_uri prefix cannot be signed.
• Replay protection: the verifier must create a fresh, random nonce for every request, and the holder binding proof must include it.
• Cross-device: use direct_post (or encrypted direct_post.jwt) with request_uri. Browser-mediated presentation through the W3C Digital Credentials API uses the reserved origin identifier, taken from the calling website.

Signed, audience-restricted assertions from subscriber-controlled wallets count as phishing-resistant under NIST SP 800-63B-4 section 3.1.7.4, which is why nonce and audience checks are not optional.

Revocation and status

• Assign indexes randomly and keep one large list per issuer: both specifications warn that per-credential lists or sequential indexes defeat herd privacy and let issuers track verification.
• Host lists on a CDN or behind a privacy relay so the issuer does not learn when and where each credential is checked.
• Decide fail-open or fail-closed per use case. High-value transactions should fail closed when the list cannot be fetched or has expired.

Trust registries and governance

A valid signature from an unknown issuer proves nothing useful. Verifiers need a trust anchor that says who may issue which credential type at what assurance level.

• EU: Regulation (EU) 2024/1183 (eIDAS 2.0), in force since 20 May 2024, requires member states to provide EU Digital Identity Wallets by the end of 2026, and the Commission states that providers legally required to identify customers "will be obliged to accept the wallet for authentication". Acceptance duties and relying party registration are covered in the wallets guide.
• UK: the UK digital verification services trust framework 1.0 is listed by GOV.UK as current from 9 June 2026, for certified digital verification services operating under the Data (Use and Access) Act 2025.
• Organisational identity: GLEIF's vLEI framework issues Legal Entity, Official Organizational Role and Engagement Context Role credentials through Qualified vLEI Issuers, so a counterparty can verify that a person acts for a registered company. See the KYB Guide.
• Private ecosystems: consortia and enterprises publish their own trust registry, an allowlist of issuer identifiers, credential types (vct or type values) and schemas, ideally as a signed, versioned document with an owner.

For each accepted credential type, the verifier should be able to answer: which issuers, which key sources, which assurance level, which status mechanism, and who approved the entry.

Privacy: selective disclosure and unlinkability

VCDM 2.0 section 8 names the correlation risks: identifier-based (the same subject DID or holder key at every verifier), signature-based (the same issuer signature value reused), and metadata-based (timing, status indexes). Selective disclosure in SD-JWT, mdoc and ecdsa-sd-2023 hides attributes but still shows the same signature to every verifier; only zero-knowledge schemes such as bbs-2023 or AnonCreds give unlinkable disclosure.

• Ask for less: request derived or minimal claims (an over-18 flag rather than a birth date). See the Age Assurance Guide.
• Use batches: issuers can provide several single-use credentials with different keys and status indexes, as the specification's preference for single-use credentials suggests.
• Do not store presentations beyond what an audit needs; store the verification result, issuer, type and time.

Wider techniques are covered in the Privacy-Enhancing Technologies Guide.

Enterprise use cases and decision guidance

• Workforce onboarding: Microsoft documents a remote onboarding pattern in which a new hire obtains a verified ID from an identity verification partner, presents it to an onboarding portal, the claims are matched to the pre-provisioned HR record on several attributes (name, address, date of birth, nationality, national identifier) and a Temporary Access Pass is issued to register phishing-resistant credentials. Links should be unique, short-lived and tied to the HR record, with ambiguous matches sent to manual review.
• KYC reuse: a bank or regulated provider accepts a government wallet credential or a credential issued by another regulated firm instead of repeating document capture. The proofing rules still apply; see the Identity Proofing and KYC Guide.
• Employee and contractor credentials: employment, clearance or training credentials presented to partners, replacing emailed letters.
• Supplier and B2B: organisational credentials such as vLEI for signing authority and onboarding.

When to adopt: when a claim crosses organisational boundaries, needs to be checked offline or repeatedly, or when minimising stored personal data matters. When not to: inside a single identity provider, federation (SAML or OIDC) is simpler and revocation is immediate. Smaller organisations should act as verifiers through an identity verification or CIAM platform that already supports OpenID4VP; large organisations and regulated firms should plan issuer capability, an internal trust registry and wallet acceptance timelines.

Where identity fits: agents and non-human identities

The subject of a credential can be a device or a software agent, and the same machinery (an issuer-signed claim bound to a key the holder proves it controls) is being proposed for AI agents to carry delegation, ownership and capability claims. These profiles are still emerging; track them in the Agent Identity Standards Tracker. Until they settle, treat any agent credential as a long-lived NHI secret: bind it to a hardware or workload key, keep validity short and log every presentation.

How to implement as a verifier

1. Define the decision first: which claims you need, at what assurance, and what you will do with them. Map each to acceptable credential types and issuers.
2. Build the trust registry: issuers, key sources (DID method, issuer metadata, X.509 trust list), accepted formats and status mechanisms, with an owner and review date.
3. Implement verification in order: parse and check format and type; verify the issuer signature against the registry; verify holder binding with your nonce and audience; check validFrom and validUntil; check status; then apply validation rules.
4. Pilot alongside the existing process: run credential checks in parallel with document or federation checks, compare outcomes, and keep the old path as rollback.
5. Test negative cases: revoked, expired, wrong audience, replayed nonce, unknown issuer, tampered disclosure. Each must fail.
6. Go live by population: start with low-risk users, then make credentials the default path once failure and fallback rates are stable.

Detection and measurement

Log every verification with issuer, credential type, format, holder binding result, status result and decision, but not the disclosed attributes. Alert on presentations from issuers not in the registry, repeated nonce failures, status list fetch failures and spikes in revoked-credential presentations.

Framework mapping

Common failure patterns

• Verifying signatures but not trust: accepting any well-formed credential whose key resolves, so an attacker issues their own.
• Skipping holder binding: treating a presented credential as a bearer token, which makes it replayable once copied.
• Weak issuer key protection: one signing key forges every credential. The Microsoft Storm-0558 key breach showed how a single stolen signing key lets an attacker mint tokens that verifiers accept, and the Coupang breach how an unrevoked key outlives the person who held it.
• Insecure pre-authorized offers: issuing on a QR code or link alone, without a transaction code, so whoever sees the offer collects the credential.
• Status lists that track: one list per credential or sequential indexes, defeating herd privacy.
• Over-requesting: asking for full identity data when a predicate would do.

Practitioner checklist

• Write down, for each use case, the claims needed, the accepted credential types and the assurance level.
• Maintain a signed, owned trust registry of issuers, key sources and formats.
• Verify holder binding with a fresh nonce and audience on every presentation.
• Check status (Bitstring Status List or Token Status List) and define fail-closed cases.
• Support at least SD-JWT VC and mdoc if you will accept EU wallet credentials.
• Protect issuer keys in HSMs, with rotation and a tested compromise plan.
• Use tx_code for pre-authorized issuance and require wallet or key attestation for high-assurance credentials.
• Request the minimum attributes and do not retain presentations.
• Log verification decisions and track the metrics above monthly.

Standards and references

• W3C: Verifiable Credentials Data Model v2.0
• W3C: Bitstring Status List v1.0
• W3C: Decentralized Identifiers (DIDs) v1.1
• IETF: SD-JWT-based Verifiable Digital Credentials (SD-JWT VC)
• IETF: Token Status List
• OpenID Foundation: OpenID for Verifiable Presentations 1.0
• OpenID Foundation: OpenID for Verifiable Credential Issuance 1.0
• European Commission: European Digital Identity Regulation

Related NHI Mgmt Group resources: Digital Identity Wallets Guide · Identity Proofing and KYC Guide · Customer IAM (CIAM) Guide · Identity Verification Buyer's Guide · Agent Identity Standards Tracker