Verifiable Credentials (VCs)

Verifiable Credentials (VCs) are digitally signed statements about a person, organization, or thing, such as a diploma, an employment record, or a proof of age, which the holder keeps in a digital wallet and presents to whoever needs to check them. They address a problem most identity processes still have: an attribute can only be confirmed by asking the organization that issued it, or by trusting a copy of a document. With a VC, the verifier checks the issuer's signature cryptographically without contacting the issuer, and the holder can disclose only the claims a transaction needs. Three formats are in use, the W3C Verifiable Credentials Data Model 2.0, SD-JWT VC and ISO mdoc, and OpenID for Verifiable Credentials (OID4VC) carries issuance and presentation of all of them over familiar OAuth 2.0 and OpenID Connect flows. Together with decentralized identifiers (DIDs), VCs are the credential layer of Self-Sovereign Identity (SSI) and of government wallet programmes such as the EU Digital Identity Wallet.

What are Verifiable Credentials?

Verifiable Credentials are digital credentials that represent information about a subject in a tamper-evident form. Unlike traditional credentials, which are often centralized and prone to forgery, VCs use cryptography to protect the integrity and authenticity of the information they carry. While VCs can optionally use distributed ledgers (including blockchain) for certain use cases, they primarily rely on public key cryptography and digital signatures. This decentralized approach improves security and reduces reliance on central authorities for identity verification.

The Verifiable Credentials Ecosystem

Verifiable Credentials operate within a trust triangle of three roles:

  • Issuer: The entity that creates and issues credentials (e.g., universities, employers, government agencies). Issuers cryptographically sign credentials to ensure authenticity.

  • Holder: The individual or organization that holds the credential, usually but not always its subject (a parent may hold a child's credential). Holders store credentials in digital wallets and control when and how to share them.

  • Verifier: The entity that requests and verifies credentials (e.g., employers, service providers). Verifiers validate the cryptographic proof without needing to contact the issuer.

Each credential contains:

  • Claims: Information about the subject (e.g., name, degree, certification date)
  • Proof: A cryptographic signature from the issuer that validates authenticity and ensures the credential hasn't been tampered with
  • Metadata: Additional information such as issuance date, expiration, and credential type

How Verifiable Credentials Work

First, the issuer creates a digital credential and associates it with an identifier for the subject, often a decentralized identifier (DID), though X.509 certificates and plain keys are common in wallet ecosystems. This credential is then shared with the holder, who can present it to third parties, typically wrapped in a verifiable presentation that proves the holder controls the key the credential is bound to. The proof accompanying the credential shows that it has not been altered since the issuer signed it.

HolderIdentity walletIssuerVerifierVerifiable data registry controls issuespresentspublishes keysresolves keys
What the two hops carry is the credential itself: signed by the issuer, held by the person it describes, and presented to a verifier that never contacts the issuer to check it.
Identity walletVerifierVerifiable data registryIssuer signatureRevocation statusHolder binding validnot revokedpresentationissuer key
Verification is three separate questions, and only the first is about cryptography: whether the signature resolves to the issuer's published key, whether the credential has since been revoked, and whether the person presenting it is the subject it was issued to.

Credential Formats

Three credential data models are in use, and a verifier has to decide which of them it accepts before it picks a library or a wallet.

The W3C Verifiable Credentials Data Model (VCDM) 2.0 has been a W3C Recommendation since May 2025. It describes a credential as a JSON-LD document and leaves the proof to one of two companion Recommendations. Verifiable Credential Data Integrity embeds the proof in the document, with cryptosuites based on ECDSA or EdDSA. Securing Verifiable Credentials using JOSE and COSE (VC-JOSE-COSE) signs the whole document as a JSON Web Signature, an SD-JWT, or a COSE message. The name VC-JWT belongs to the JWT encoding of version 1.1, which mapped the credential into JWT claims. VC-JOSE-COSE signs the document itself instead, so a verifier written for 1.1 JWTs cannot check a 2.0 credential.

SD-JWT-based Verifiable Digital Credentials (SD-JWT VC) and ISO mdoc are separate data models, not encodings of the W3C one. SD-JWT VC, an IETF draft, puts plain JSON claims into an SD-JWT as defined by RFC 9901, Selective Disclosure for JSON Web Tokens, and uses no JSON-LD. The mdoc of ISO/IEC 18013-5, written for the mobile driving licence and reused for other documents, encodes its data elements in CBOR under a COSE signature. These two are what the EU Digital Identity Wallet mandates: a provider of person identification data has to issue it in both. A deployment that must accept the EU wallet therefore builds for SD-JWT VC and mdoc first, whatever it does with VCDM elsewhere. OpenID for Verifiable Presentations carries all three data models with a format identifier per credential, so the choice of protocol does not settle the choice of format.

All three let the holder disclose only the claims a transaction needs. SD-JWT VC and mdoc do this with salted hashes of each claim under the issuer's signature, and the ECDSA cryptosuite of Data Integrity has a selective disclosure variant. Selective disclosure does not make presentations unlinkable: the issuer signature and the holder key are the same in every presentation, so verifiers that compare what they received can correlate the holder. Wallet ecosystems counter this by issuing a batch of credentials and using each one once. A single credential that yields unlinkable proofs needs a signature scheme with zero-knowledge proofs such as BBS, whose Data Integrity cryptosuite is still a W3C Candidate Recommendation. Revocation checks are a second correlation channel, which Bitstring Status List, also a W3C Recommendation, narrows by hiding each credential's status among many others.

OpenID for Verifiable Credentials (OID4VC)

OpenID for Verifiable Credentials (OID4VC) is the OpenID Foundation's family of protocols for moving credentials between issuer, wallet and verifier. Its two core specifications are final: OpenID for Verifiable Presentations (OID4VP) 1.0 since July 2025, and OpenID for Verifiable Credential Issuance (OID4VCI) 1.0 since September 2025. An IAM team can therefore build issuance and verification on the OAuth 2.0 stack it already runs, with the same authorization server, client registration and token handling.

OID4VCI makes the wallet an OAuth client. The wallet obtains an access token, through an authorization code flow when the user signs in at the issuer or through a pre-authorized code when the issuer has identified the user by other means, and calls the issuer's credential endpoint with proof that it holds the key the credential will be bound to. An issuer that already operates an authorization server adds that endpoint and the metadata describing which credentials it offers.

OID4VP extends the OAuth 2.0 authorization request in the other direction. The verifier asks for credentials in the Digital Credentials Query Language (DCQL), and the wallet returns them in a VP token. The request reaches the wallet by redirect on the same device, by QR code across devices, or on the web through the W3C Digital Credentials API, which makes the browser responsible for wallet selection and user consent instead of the site.

Neither specification fixes a credential format; both define format profiles for SD-JWT VC, mdoc and VCDM. The OpenID4VC High Assurance Interoperability Profile (HAIP) 1.0, final since December 2025, narrows those options, limits the formats to SD-JWT VC and mdoc, and is what makes independently built wallets and verifiers work together. A verifier that has to accept wallets it did not choose should ask its suppliers for HAIP conformance, since conformance to the base specifications alone does not guarantee it.

Self-Issued OpenID Provider v2 (SIOPv2), in which the wallet acts as its own OpenID provider and signs ID tokens with a key the user controls, is still an Implementer's Draft. Wallet ecosystems log users in with OID4VP instead: presenting a credential gives the relying party an issuer's assurance about the user, where a self-issued ID token gives it only a key.

Use Cases and Applications

Verifiable Credentials are the technical foundation for implementing Self-Sovereign Identity (SSI) across industries. While SSI provides the architectural principles, VCs are the standardized data format that makes it practical. For real-world SSI implementations like Mobile Driver's License (mDL) and the EUDI Wallet, see SSI.

Common VC applications include:

Identity Verification:

  • VCs give individuals a secure and decentralized way to present their credentials for identity verification. This helps in online transactions in particular, where identity theft is a significant concern.

Education:

  • Digital diplomas and certificates issued as Verifiable Credentials let employers verify academic qualifications, reducing the risk of credential fraud.

Employment Records:

  • VCs simplify the verification of employment records. Job applicants can present their work history in a tamper-evident format, which speeds up hiring and lets employers check that the information is authentic.

Licenses and Certifications:

  • Professionals often hold various licenses and certifications. Verifiable Credentials let organizations manage and verify these credentials and confirm that individuals hold the necessary qualifications.

Healthcare:

  • In the healthcare industry, patient records, prescriptions, and medical certifications can be securely managed using Verifiable Credentials. This lets health-related information be shared reliably while maintaining patient privacy.

Access Management:

  • VCs can be used for access management, providing a secure and decentralized way to control access to physical and digital spaces. This includes building entry, online platforms, and other restricted areas.

Supply Chain and Product Authenticity:

  • Verifiable Credentials can be applied to supply chain management, ensuring the authenticity of products. A tamper-evident record of product information can follow the product from manufacturing to distribution.

Financial Services:

  • In the financial sector, Verifiable Credentials can shorten Know Your Customer (KYC) processes and customer onboarding by replacing document uploads with a signed attribute. This reduces the risk of identity fraud and ensures compliance with regulations. A credential issued after a full identity proofing process relocates that effort rather than removing it: the assurance a verifier obtains is the issuer's, together with the wallet's binding of the credential to its holder.

Human Resources and Employee Onboarding:

  • HR departments can use VCs to verify and securely store employee information, certifications, and training records. This simplifies the onboarding process and ensures accurate documentation throughout an employee's tenure.

Challenges and Considerations

Several challenges stand in the way of widespread adoption:

Technical Challenges:

  • Interoperability: Ensuring different wallet implementations, issuers, and verifiers can communicate across various credential formats and protocols
  • Standardization: Multiple competing standards and specifications can create fragmentation in the ecosystem
  • Key Management: Secure storage and recovery of cryptographic keys is necessary but hard for average users

Privacy and Security:

  • Privacy Concerns: Balancing the need for identity verification with data minimization and user privacy
  • Correlation Attacks: Risk of tracking users across different verifier interactions if not properly implemented
  • Revocation: Efficiently handling credential revocation while preserving privacy

Adoption Barriers:

  • User Experience: Simplifying wallet management and credential interactions for non-technical users
  • Regulatory Uncertainty: Evolving legal frameworks around digital identity and data protection (see SSI for discussion of GDPR and eIDAS 2.0)
  • Infrastructure Requirements: Organizations need to build issuance and verification capabilities
  • Trust Framework: Establishing governance models and trust registries for credential ecosystems. A verifier needs to know that an issuer is accredited before the signature on a credential means anything, and OpenID Federation is the finalized trust infrastructure increasingly used for that layer in wallet ecosystems

Ecosystem Development:

  • Limited Adoption: Need for critical mass of issuers, holders, and verifiers to create network effects
  • Vendor Lock-in: Risk of proprietary implementations limiting portability
  • Cost: Initial investment required for organizations to implement VC infrastructure

Most of these are organizational rather than cryptographic: the formats and protocols are specified, while trust frameworks, wallet usability, and the number of issuers and verifiers willing to take part decide whether a deployment works.

Relationship to Self-Sovereign Identity

Verifiable Credentials are a core component of the Self-Sovereign Identity (SSI) model. While SSI defines the architectural principles of user-controlled, decentralized identity management, VCs provide the standardized technical specification for representing and exchanging verifiable information within SSI systems. Together with Decentralized Identifiers (DIDs), VCs put SSI principles into practice, letting users keep control of their digital identities while still taking part in trusted interactions across different contexts and organizations. For how VCs fit into SSI as a whole, including real-world implementations like the EUDI Wallet and mDL, see SSI.