...

Key Concepts

Image Removed

https://en.wikipedia.org/wiki/Verifiable_credentials

The holder of a verifiable credential operates in a triangle of trust, mediating between issuer and verifier. The issuer and holder trust each other, the holder trusts the verifier, and the verifier trusts the issuer. Any role in the triangle can be played by a person, an institution, or an IoT device.

Verifiable Credentials Standards 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.

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

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.

Image Removed

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

3.1.1 Claims, Properties

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

...

...

TOIP 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

Image Added

1. 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).
2. 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​.
3. 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.
4. 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.

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

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.

Image Added

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

3.1.1 Claims, Properties

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

...

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.

...

• 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.

Next steps include evolving the existing AnonCreds Rust implementation to be friendlier to VDRs/ledgers other than Indy, wrapping up the v1.0 specification, and gaining compliance with the W3C Verifiable Credentials Data Model Standard.

TOIP Triangle of Trust and Governance Models, Standards for Verifiable Credentials

m TOIP Trust Over IP

...

• 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.

Next steps include evolving the existing AnonCreds Rust implementation to be friendlier to VDRs/ledgers other than Indy, wrapping up the v1.0 specification, and gaining compliance with the W3C Verifiable Credentials Data Model Standard.

TOIP Triangle of Trust and Governance Models, Standards for Verifiable Credentials

m TOIP Trust Over IP

Toip-model - Interactive Model - Layers & Governance

OpenID for Verifiable Presentations - draft 23

This specification defines a mechanism on top of OAuth 2.0 [RFC6749] that enables presentation of Verifiable Credentials as Verifiable Presentations. Verifiable Credentials and Verifiable Presentations can be of any format, including, but not limited to W3C Verifiable Credentials Data Model [VC_DATA], ISO mdoc [ISO.18013-5], IETF SD-JWT VC [I-D.ietf-oauth-sd-jwt-vc], and AnonCreds [Hyperledger.Indy].

OAuth 2.0 [RFC6749] is used as a base protocol as it provides the required rails to build a simple, secure, and developer-friendly Credential presentation layer on top of it. Moreover, implementers can, in a single interface, support Credential presentation and the issuance of Access Tokens for access to APIs based on Verifiable Credentials in the Wallet. OpenID Connect [OpenID.Core] deployments can also extend their implementations using this specification with the ability to transport Verifiable Presentations.

This specification can also be combined with [SIOPv2], if implementers require OpenID Connect features, such as the issuance of Self-Issued ID Tokens [SIOPv2].

Potential Value Opportunities

...