Table of Contents

Reference_description_with_linked_URLs_______________________	Notes______________________________________________________________
Digital Identity Concepts

https://www.w3.org/TR/vc-overview/

Key Concepts

...

TOIP

...

W3C Verifiable Credentials Overview 2025

This document provides a solid understanding of what a VC is, how it's used and the standards in place

Credentials are a part of our daily lives; driver's licenses are used to assert that we are capable of operating a motor vehicle, university degrees can be used to assert our level of education, and government-issued passports enable us to travel between countries. The family of W3C Recommendations for Verifiable Credentials, described in this overview document, provides a mechanism to express these sorts of credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable.

1.1 High Level View of the Specifications

Figure 1 provides an overview of the main building blocks for Verifiable Credentials, including their (normative) dependencies. For more details, see the subsequent sections in this document.

The Verifiable Credentials Data Model v2.0 [VC-DATA-MODEL-2.0] specification, which defines the core concepts that all other specifications depend on, plays a central role. The model is defined in abstract terms, and applications express their specific credentials using a serialization of the data model. The current specifications mostly use a JSON serialization; the community may develop other serializations in the future.

When Verifiable Credentials are serialized in JSON, it is important to trust that the structure of a Credential may be interpreted in a consistent manner by all participants in the verifiable credential ecosystem. The Verifiable Credentials JSON Schema Specification [VC-JSON-SCHEMA] defines how [JSON-SCHEMA] can be used for that purpose.

Credentials can be secured using two different mechanisms: enveloping proofs or embedded proofs. In both cases, a Credential is cryptographically secured by a proof (for example, using digital signatures). In the enveloping case, the proof wraps around the Credential, whereas embedded proofs are included in the serialization, alongside the Credential itself.

A family of enveloping proofs is defined in the Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE] document, relying on technologies defined by the IETF. Other types of enveloping proofs may be specified by the community.

The general structure for embedded proofs is defined in a separate Verifiable Credential Data Integrity 1.0 [VC-DATA-INTEGRITY] specification. Furthermore, the Working Group also specifies some instances of this general structure in the form of the "cryptosuites": Data Integrity EdDSA Cryptosuites v1.0 [VC-DI-EDDSA], Data Integrity ECDSA Cryptosuites v1.0 [VC-DI-ECDSA], and Data Integrity BBS Cryptosuites v1.0 [VC-DI-BBS]. Other cryptosuites may be specified by the community.

The Bitstring Status List v1.0 [VC-BITSTRING-STATUS-LIST] specification defines a privacy-preserving, space-efficient, and high-performance mechanism for publishing the status of a specific Verifiable Credential, such as its suspension or revocation, through the use of bitstrings.

Finally, the Controlled Identifiers [CONTROLLER-DOCUMENT] specification defines some common terms (e.g., verification relationships and methods) that are used not only by other Verifiable Credential specifications, but also other Recommendations such as Decentralized Identifiers (DIDs) v1.0 [DID-CORE].

Image Removed

Figure 1 Verifiable Credentials Working Group Recommendations

Ecosystem Overview

The Verifiable Credential specifications rely on an ecosystem consisting of entities playing different "roles". The main roles are:

IssuerAn entity that creates a Verifiable Credential, consisting of a series of statements related to its subject. An example is a university that issues credentials for university degrees or certificates for alumni.HolderAn entity that possesses one or more Credentials, and that can transmit presentations of those Verifiable Credentials to third parties. An example may be the person who "holds" his/her own educational degrees. Another example may be a digital wallet that contains several Credentials on someone's behalf.VerifierAn entity that performs verification on a Verifiable Credential to check the validity, consistency, etc., of a Credential. An example may be an employer's digital system that checks the validity of a university degree before deciding on the employment of a person.

For a more precise definition of these roles, as well as other roles, see the relevant section in the data model specification.

Diagram showing how credentials flow from issuer to holder, and presentations flow from holder to verifier, where all three parties can use information from a logical verifiable data registry. Image Removed

Figure 2 The roles and information flows forming the basis for the VC Data Model.

A core concept is "claims": statements made about various entities, referred to as "subjects". Subjects may be a holder, an issuer, or a verifier as listed above, but may also any be another person (e.g., the person holding a university degree), an animal, an abstract concept, etc. Claims may also be on a Credential itself, such as issuance date, validity periods, etc. (Such claims are also loosely referred to as "credential metadata".)

Claims are expressed using "properties" referring to "values". Values may be literals, but may also be other entities referred to, usually, by a [URL]. It that case, the entity may become the subject of another claim; these claims, together, form a "graph" of claims that represents a Credential. (See Figure 6 for an example of such a graph represented graphically. For more complex examples, refer to the Verifiable Credentials Data Model v2.0 specification itself.)

Image Removed

Figure 3 The basic structure of a claim with (in this case) a literal value.

The Verifiable Credentials Data Model v2.0 document specifies a number of standard properties. These include, for example, credentialSubject, type, issuer, or validFrom. Developers may define their own properties to express specific types of Credentials, like a driving license, a university degree, or a marriage certificate.

3.1.2 Verifiable Credentials

A Credential is a set of one or more claims made by the same entity. Credentials might also include an identifier and metadata to describe properties of the Credential, such as a reference to the issuer, the validity date, a representative image, the revocation mechanism, and so on. A Verifiable Credential is a set of claims and metadata that also includes verification mechanisms that cryptographically prove who issued it, ensures that the data has not been tampered with, etc.

For a more detailed description of abstract Verifiable Credentials, with examples, see the relevant section in the data model specification.

Diagram showing a lozenge labeled as 'Verifiable Credential' containing three vertically stacked lozenges, labeled as 'Credential Metadata', 'Claim(s)', and 'Proof(s)'. Image Removed

Figure 4 Basic components of a Verifiable Credential.

3.1.3 Verifiable Presentations

Enhancing privacy is a key design feature of Verifiable Credentials. Therefore, it is important, for entities using this technology, to be able to express only the portions of their persona that are appropriate for a given situation. The expression of a subset of one's persona is called a Verifiable Presentation. Examples of different personas include a person's professional persona, their online gaming persona, their family persona, or an incognito persona.

A Verifiable Presentation is created by a holder, can express data stemming from multiple Verifiable Credentials, and can contain additional metadata in forms of additional claims. They are used to present claims to a verifier. It is also possible to present Verifiable Credential directly.

A Verifiable Presentation is usually short-lived, it is not meant to be stored for a longer period.

For a more detailed description of abstract Verifiable Presentations, with examples, see the relevant section in the data model specification.

Diagram showing a lozenge labeled as 'Verifiable Presentation' containing three vertically stacked lozenges, labeled as 'Presentation Metadata', 'Verifiable Credential(s)', and 'Proof(s)'. Image Removed

Figure 5 Basic components of a verifiable presentation.

3.2 Serialization in JSON

The following JSON-LD code is an example for a simple Credential. It states that the person named "Pat", identified by https://www.exampl.org/persons/pat, is an alumni of the Example University (identified by did:example:c276e12ec21ebfeb1f712ebc6f1). The Credential is valid from the 1st of January 2010, and is issued by an entity identified by did:example:2g55q912ec3476eba2l9812ecbfe. Most of the properties in the Credential are from the standard Verifiable Credentials vocabulary, but some terms (like alumniOf, AlumniCredential) are added by the application-specific vocabulary referred to by https://www.w3.org/ns/credentials/examples/v2.

Example 1: A Simple Credential

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "https://university.example/Credential123",
  "type": ["VerifiableCredential", "ExampleAlumniCredential"],
  "issuer": "did:example:2g55q912ec3476eba2l9812ecbfe",
  "validFrom": "2010-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "https://www.example.org/persons/pat",
    "name": "Pat",
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": "Example University"
    }
  }
}

The graph of claims from the example credential

Image Removed

https://www.w3.org/TR/vc-data-model-2.0/

3.3 Checking Structure with JSON Schemas

4. Securing Credentials

4.1 Enveloping Proofs - JOSE COSE ( for QR codes )

Enveloping proofs of Credentials, defined by this Working Group, are based on JSON Object Signing and Encryption (JOSE), CBOR Object Signing and Encryption (COSE) [RFC9052], or Selective Disclosure for JWTs [SD-JWT]. These are all IETF specifications, or groups of specifications (like JOSE, that refers to JWT [RFC7519], JWS [RFC7515], or JWK [RFC7517]). The Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE] recommendation defines a "bridge" between these and the Verifiable Credentials Data Model v2.0, specifying the suitable header claims, media types, etc.

In the case of JOSE, the Credential is the "payload" (to use the IETF terminology). This is preceded by a suitable header whose details are specified by the relevant section of the [VC-JOSE-COSE] specification. These are encoded, concatenated, and signed, to be transferred in a compact form by one entity to another (e.g., sent by the holder to the verifier). All the intricate details on signatures, encryption keys, etc., are defined by the IETF specifications; see Example 6 for a specific case.

The usage of COSE [RFC9052] is similar to JOSE, except that all structures are represented in CBOR [RFC8949]. From the Credentials point of view, however, the structure is similar insofar as the Credential (or the Presentation) is again the payload for COSE. The usage of CBOR means that the final representation of the Verifiable Credential (or Presentation) has a significantly reduced footprint which can be, for example, shown in a QR Code.

4.2.1 Creation of Proofs in Data Integrity

The operation of Data Integrity is conceptually simple. To create a cryptographic proof, the following steps are performed: 1) Transformation, 2) Hashing, and 3) Proof Generation.

Simple flow diagram, with steps from left to right, labeled as 'Data', 'Transform Data', 'Hash Data', 'Generate Proof', and 'Data with Proof'. Image Removed

Figure 7 View of the proof generation steps.

5. Bitstring Status List - to check for credential revocation efficiently

It is often useful for an issuer of Verifiable Credentials to link to a location where a verifier can check to see if a credential has been suspended or revoked. This additional resource is referred to as a "status list".

The simplest approach for a status list, where there is a one-to-one mapping between a Verifiable Credential and a URL where the status is published, raises privacy as well as performance issues. In order to meet privacy expectations, it is useful to bundle the status of large sets of credentials into a single list to help with group privacy.

Example of a Verifiable Credential Life Cycle from the spec

The previous sections provided an overview of the Verifiable Credential ecosystem. This section provides more details about how the ecosystem is envisaged to operate.

Image Removed

Figure 10 Lifecycle of a single Verifiable Credential: the roles and information flows for this specification.

EBSI support for VC and VP standards

https://ec.europa.eu/digital-building-blocks/wikis/pages/viewpage.action?pageId=555222155

VC and VP Lifecycle

EBSI's VC and VP lifecycle is summarized in the table below. The table also presents differences between EBSI's VC and VP lifecycle and W3C's VC and VP lifecycle.

Image Removed

...

Step

...

EBSI's VC and VP lifecycle

...

W3C's VC and VP lifecycle

...

Guidelines for EBSI

...

Credential Issuance for Issuers and Holders

Storage of Verifiable Credentials for Holders

...

Issuance of one or more Verifiable Credentials.

Storage of Verifiable Credentials in a credential repository, e.g., digital wallet.

...

Verifiable Credential issuance guidelines

Wallet Conformance Testing

...

Composition of Verifiable Credentials into Verifiable Presentation.

Exchange of Verifiable Presentation and its verification by the Verifier.

...

Data Models and Schemas

TSR API

APIs

EBSI developed several APIs for interaction with the EBSI blockchain, data registries, and smart contracts. Each API serves its specific role and is used by different actors. The following APIs are used in the EBSI VC and VP lifecycle today:

Trusted Issuer Registry (TIR)
Trusted Schema Registry (TSR)
DID Registry API

The table below summarizes the APIs used in VC and VP lifecycle.

...

Action

...

API

...

Actor

...

Documentation

...

TIR API

Onboarding and accrediting Legal Entities

AnonCreds Project - VC with selective disclosure, ZKP protections

https://www.hyperledger.org/use/anoncreds

https://github.com/hyperledger/anoncreds-rs

a>> see how AnonCreds plans to support W3C VC standards

AnonCreds, the most commonly used Verifiable Credential (VC) format in the world*, is now a Hyperledger project. Ledger agnostic and with a formal open specification, AnonCreds continues to evolve as a mature verifiable credential format with unique privacy-protecting capabilities.

Hyperledger AnonCreds—short for “Anonymous Credentials”—is a type of VC that adds important privacy-protecting ZKP (zero-knowledge proof) capabilities to the core VC assurances. A core element of the Hyperledger Indy project for more than five years, AnonCreds is a mature, complete model and interactions set, with extensive support across Hyperledger Aries frameworks.

Hyperledger AnonCreds is ledger-agnostic and client-agnostic. It is not tied to Hyperledger Indy or Aries. This makes it usable with other verifiable data registries/ledgers and verifiable credential client stacks. As a result, important privacy-protecting capabilities become available to a much broader audience, and the underlying cryptography can evolve without affecting the features above it.

Additional benefits of using Hyperledger AnonCreds include:

Avoidance of identifiers: No correlatable identifiers are required in presenting data to a verifier. Correlatable identifiers may be applied in a use case specific manner.
Verifier assurances: Credentials are bound to the holder, so verifiers know that credentials presented together were all issued to the holder providing the presentation.
Minimal data sharing: Data to be shared by a holder to a verifier is minimized through the use of selective disclosure and ZKP predicates

Flexible formatting: Credentials and presentations can be formatted in the W3C VC Data Model standard format.

The AnonCreds Specification, managed by the Hyperledger AnonCreds Specification Working Group and with the potential of being submitted to an appropriate Standards organization
Ledger/Verifiable Data Registry-agnostic, open source code implementations of the AnonCreds specification, suitable for use with Hyperledger Aries and non-Aries agents
Guidance for creating ledger-specific AnonCreds Methods to write and resolve AnonCreds objects for specific ledgers
Documentation on AnonCreds suitable for all audiences, from business audiences to cryptographers
A test suite to verify adherence to the AnonCreds specification and the interoperability of AnonCreds implementations.

...

Verifiable Credential Trust Triangle - Whitepaper

A verifiable credential could be a drivers license, a degree, a certificate from a building inspector, an authorization for a user role to access accounts, etc

vcred_trust_triangle Image Added

First the issuer writes a Decentralized Identifier (DID) together with its public key (and any other cryptographic material needed for the issuer’s verifiable credentials) to a blockchain (or other sufficiently trusted public utility).
Second, the issuer uses its private key to digitally sign a verifiable credential it issues to a qualified holder, who stores it in her own digital wallet. Note that for privacy preservation, this entire issuance process takes place off-chain.
Third, a verifier requests a digital proof of one or more credentials from the holder. If the holder consents, the holder’s wallet generates and returns the proofs to the verifier. Since the proofs contain the issuer’s DID, the verifier uses it to read the issuer’s public key and other cryptographic data from the blockchain.
In the final step, the verifier uses the issuer’s public key to verify that the proofs are valid and that the digital credential has not been tampered with.

TOIP Interactive Model showing how Verifiable Credentials Work

Image Added

Verifiable Credentials Standards detail from W3C, TOIP

W3C Verifiable Credentials Overview 2025

This document provides a solid understanding of what a VC is, how it's used and the standards in place

Credentials are a part of our daily lives; driver's licenses are used to assert that we are capable of operating a motor vehicle, university degrees can be used to assert our level of education, and government-issued passports enable us to travel between countries. The family of W3C Recommendations for Verifiable Credentials, described in this overview document, provides a mechanism to express these sorts of credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable.

1.1 High Level View of the Specifications

Figure 1 provides an overview of the main building blocks for Verifiable Credentials, including their (normative) dependencies. For more details, see the subsequent sections in this document.

The Verifiable Credentials Data Model v2.0 [VC-DATA-MODEL-2.0] specification, which defines the core concepts that all other specifications depend on, plays a central role. The model is defined in abstract terms, and applications express their specific credentials using a serialization of the data model. The current specifications mostly use a JSON serialization; the community may develop other serializations in the future.

When Verifiable Credentials are serialized in JSON, it is important to trust that the structure of a Credential may be interpreted in a consistent manner by all participants in the verifiable credential ecosystem. The Verifiable Credentials JSON Schema Specification [VC-JSON-SCHEMA] defines how [JSON-SCHEMA] can be used for that purpose.

Credentials can be secured using two different mechanisms: enveloping proofs or embedded proofs. In both cases, a Credential is cryptographically secured by a proof (for example, using digital signatures). In the enveloping case, the proof wraps around the Credential, whereas embedded proofs are included in the serialization, alongside the Credential itself.

A family of enveloping proofs is defined in the Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE] document, relying on technologies defined by the IETF. Other types of enveloping proofs may be specified by the community.

The general structure for embedded proofs is defined in a separate Verifiable Credential Data Integrity 1.0 [VC-DATA-INTEGRITY] specification. Furthermore, the Working Group also specifies some instances of this general structure in the form of the "cryptosuites": Data Integrity EdDSA Cryptosuites v1.0 [VC-DI-EDDSA], Data Integrity ECDSA Cryptosuites v1.0 [VC-DI-ECDSA], and Data Integrity BBS Cryptosuites v1.0 [VC-DI-BBS]. Other cryptosuites may be specified by the community.

The Bitstring Status List v1.0 [VC-BITSTRING-STATUS-LIST] specification defines a privacy-preserving, space-efficient, and high-performance mechanism for publishing the status of a specific Verifiable Credential, such as its suspension or revocation, through the use of bitstrings.

Finally, the Controlled Identifiers [CONTROLLER-DOCUMENT] specification defines some common terms (e.g., verification relationships and methods) that are used not only by other Verifiable Credential specifications, but also other Recommendations such as Decentralized Identifiers (DIDs) v1.0 [DID-CORE].

Image Added

Figure 1 Verifiable Credentials Working Group Recommendations

Ecosystem Overview

The Verifiable Credential specifications rely on an ecosystem consisting of entities playing different "roles". The main roles are:

IssuerAn entity that creates a Verifiable Credential, consisting of a series of statements related to its subject. An example is a university that issues credentials for university degrees or certificates for alumni.HolderAn entity that possesses one or more Credentials, and that can transmit presentations of those Verifiable Credentials to third parties. An example may be the person who "holds" his/her own educational degrees. Another example may be a digital wallet that contains several Credentials on someone's behalf.VerifierAn entity that performs verification on a Verifiable Credential to check the validity, consistency, etc., of a Credential. An example may be an employer's digital system that checks the validity of a university degree before deciding on the employment of a person.

For a more precise definition of these roles, as well as other roles, see the relevant section in the data model specification.

Diagram showing how credentials flow from issuer to holder, and presentations flow from holder to verifier, where all three parties can use information from a logical verifiable data registry. Image Added

Figure 2 The roles and information flows forming the basis for the VC Data Model.

A core concept is "claims": statements made about various entities, referred to as "subjects". Subjects may be a holder, an issuer, or a verifier as listed above, but may also any be another person (e.g., the person holding a university degree), an animal, an abstract concept, etc. Claims may also be on a Credential itself, such as issuance date, validity periods, etc. (Such claims are also loosely referred to as "credential metadata".)

Claims are expressed using "properties" referring to "values". Values may be literals, but may also be other entities referred to, usually, by a [URL]. It that case, the entity may become the subject of another claim; these claims, together, form a "graph" of claims that represents a Credential. (See Figure 6 for an example of such a graph represented graphically. For more complex examples, refer to the Verifiable Credentials Data Model v2.0 specification itself.)

Image Added

Figure 3 The basic structure of a claim with (in this case) a literal value.

The Verifiable Credentials Data Model v2.0 document specifies a number of standard properties. These include, for example, credentialSubject, type, issuer, or validFrom. Developers may define their own properties to express specific types of Credentials, like a driving license, a university degree, or a marriage certificate.