VC Specifications Directory

The Verifiable Credential Specifications Directory

W3C Group Note

More details about this document
This version:
https://www.w3.org/TR/2024/NOTE-vc-specs-dir-20240601/
Latest published version:
https://www.w3.org/TR/vc-specs-dir/
Latest editor's draft:
https://w3c.github.io/vc-specs-dir/
History:
https://www.w3.org/standards/history/vc-specs-dir/
Commit history
Editor:
Manu Sporny (Digital Bazaar)
Author:
Manu Sporny (Digital Bazaar)
Feedback:
GitHub w3c/vc-specs-dir (pull requests, new issue, open issues)
public-vc-wg@w3.org with subject line [vc-specs-dir] … message topic … (archives)
Related Documents
Verifiable Credentials Data Model

Abstract

This document serves as an unofficial directory for all known Verifiable Credential specifications whether they are released by a global standards setting organization, a community group, an open source project, or an individual.

Status of This Document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This document is not a formal registry nor is it intended to become a Registry Track document per the W3C Process.

Comments regarding this document are welcome. Please file issues directly on GitHub, or send them to public-vc-wg@w3.org ( subscribe, archives).

This document was published by the Verifiable Credentials Working Group as a Group Note using the Note track.

This Group Note is endorsed by the Verifiable Credentials Working Group, but is not endorsed by W3C itself nor its Members.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

The W3C Patent Policy does not carry any licensing requirements or commitments on this document.

This document is governed by the 03 November 2023 W3C Process Document.

1. Introduction

This section is non-normative.

This document serves as an unofficial directory for all known Verifiable Credential specifications whether they are released by a global standards setting organization, a community group, an open source project, or an individual.

1.1 Adding a Specification Entry

The Verifiable Credentials Data Model is designed to be extended by 3rd party specifications to address a variety of real world use cases. Examples of extensions include, but are not limited to, new types of Verifiable Credentials and ways of expressing credential status, schema validation, evidence, refreshing, terms of use, and cryptographic suites for securing credentials.

In order to add a new specification to this directory, an implementer submits a modification request for this directory, as a pull request on the repository where this directory is hosted.

Here is an example:

{
  "name": "Example VC",
  "summary": "Used to demonstrate examples for Verifiable Credentials.",
  "specification": "https://example.github.io/example-spec/",
  "category": "vc",
  "maintainerEmail": "maintainer@community.example",
  "maintainerName": "Example Community Group",
  "maintainerWebsite": "https://example.github.io/",
  "vocabulary": ["https://example.github.io/vocabularies/example.yml"]
}

The modification request MUST adhere to the following policies:

  1. Any addition to the directory MUST conform to Section 1.1.1 Specification Entry Format.
  2. If there are copyright, trademark, or any intellectual property rights concerns, the addition and use MUST be authorized in writing by the intellectual property rights holder under a F/RAND license. Examples include specifications that use trademarked brand names, property names that utilize the titles of copyrighted works, and patented technology that would cause the use of the extension to require licensing a patent.
  3. Any addition MUST NOT create unreasonable legal, security, moral, or privacy issues that will result in direct harm to others. Examples of unacceptable additions include any containing racist language, technologies used to persecute minority populations, and unconsented pervasive tracking.

The Editors of this directory MUST consider all of the policies above when reviewing additions to the directory and MUST reject directory entries if they violate any of the policies in this section. Entities registering additions can challenge rejections first with the W3C Verifiable Credentials Working Group and then, if they are not satisfied with the outcome, with the W3C Staff. W3C Staff need not be consulted on changes to the directory, but do have the final authority on directory contents. This is to ensure that W3C can adequately respond to time sensitive legal, privacy, security, moral, or other pressing concerns without putting an undue operational burden on W3C Staff.

Any submission to the directory that meets all of the criteria listed above will be accepted for inclusion. The specifications listed in this directory enumerate all known specifications, without choosing between them.

1.1.1 Specification Entry Format

The specification entry format MUST conform to the JSON Schema for a specification entry. Each field is documented below:

Field Description
name A short human readable name for the specification. For example: Status List (v2021).
summary A one sentence description for the specification. For example: A credential status list with herd privacy characteristics.
specification An URL that resolves to a human readable specification. For example: https://w3c.github.io/vc-status-list-2021/.
category The Verifiable Credential extension category of the specification, which can be one of the following values: credentialStatus, credentialSchema, evidence, media-type, securing, refreshService, termsOfUse, or vc. For example: credentialStatus.
Note

The extensions might define a @type. See [JSON-LD11].

maintainerName A person or organization which responds to contact requests. For example: W3C Verifiable Credentials Working Group.
maintainerEmail An email to send contact requests. For example: public-vc-wg@w3.org.
maintainerWebsite An website to send contact requests. For example: https://www.w3.org/groups/wg/vc.
vocabulary An array of URLs that contain machine-readable vocabulary information in yml2vocab or JSON-LD format. For example: ["https://raw.githubusercontent.com/w3c/vc-status-list-2021/main/contexts/v1.jsonld"].

1.2 Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MUST and MUST NOT in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Property-based Extensions

2.1 Credential Status

SpecificationDescription
Bitstring Status List v1.0A credential status list with herd privacy characteristics.
Maintainer: W3C Verifiable Credentials Working Group (email) (website)
1EdTech Revocation List Status MethodA simple list-based mechanism for publishing and checking the revocation status of a verifiable credential
Maintainer: 1EdTech (email) (website)
Ethr Revocation 2022An Ethereum, EIP-5539 compliant and registry-based revocation mechanism for Verifiable Credentials
Maintainer: Spherity GmbH (email) (website)

2.2 Credential Schema

SpecificationDescription
Verifiable Credentials JSON SchemaEnables JSON Schemas to be applied as a validation method to any portions of Verifiable Credentials
Maintainer: W3C Verifiable Credentials Working Group (email) (website)
1EdTech JSON Schema Validator 2019Credential data schema validation method for verifiable credentials using JSON Schema
Maintainer: 1EdTech (email) (website)
Validating Verifiable Credentials with JSON SchemaThis specification defines a JSON Schema based credential schema validation scheme for use with the credential schema property of Verifiable Credentials
Maintainer: Transmute (email) (website)

2.3 Evidence

SpecificationDescription
European Learning Model Evidence ExtensionEvidence Class in the European Learning Model used to link evidence of permission to issue due to mandate or accreditation.
Maintainer: European Commission (email) (website)
OIDF eKYC and IDA EvidenceEvidence property that conforms to the OpenID Connect for Identity Assurance specification
Maintainer: David Chadwick (email) (website)
1EdTech Verifiable Credential Refresh ServiceDescriptive metadata about evidence related to an achievement assertion.
Maintainer: 1EdTech (email) (website)

2.4 Proof

See Section 4. Securing Mechanisms.

2.5 Refresh Service

SpecificationDescription
1EdTech Verifiable Credential Refresh ServiceRefresh service for refreshing an expired or modified verifiable credential.
Maintainer: 1EdTech (email) (website)
Conexxus Age Token Refresh Service (VerifiableCredentialRefresh2021)Refresh service for retrieving a new batch of single use age tokens.
Maintainer: Conexxus (email) (website)

2.6 Terms of Use

SpecificationDescription
Precondition PolicyTerms of Use for Chain Reaction Revocation
Maintainer: Taisei Igarashi (email) (website)
TRAIN Terms of UseTerms of Use for an Issuer to indicate that they are a member of one or more TRAIN/ETSI list of trusted issuers
Maintainer: David Chadwick (email) (website)

3. Type-based Extensions

SpecificationDescription
Comprehensive Learner Record v2Education credentials for sharing an individual's set of achievements and skills issued by multiple learning providers.
Maintainer: 1EdTech (email) (website)
European Digital Credentials for LearningApplication profile of the European Learning Model v2, specifying implementation of Digital Credentials as Verifiable Credentials.
Maintainer: European Commission (email) (website)
DSCSA Authorized Trading PartnersAn architecture supporting the Authorized Trading Partner (ATP) requirements of the U.S. Drug Supply Chain Security Act (DSCSA), allowing for authentication and information exchange between DSCSA-defined ATPs and related stakeholders to establish mutual verification of identity and ATP status.
Maintainer: Open Credentialing Initiative (OCI) (email) (website)
Open Badges v3Education credentials for sharing achievements and skills.
Maintainer: 1EdTech (email) (website)
Traceability VocabularyThis specification describes a Linked Data vocabulary for asserting Verifiable Credentials related to supply chain traceability. Verifiable Credentials using these terms can be used to help determine the legitimacy of organizations, and the status of the products and materials in global trade.
Maintainer: W3C Credentials Community Group (email) (website)

4. Securing Mechanisms

SpecificationDescription
BBS Cryptosuite (v2023)Securing Verifiable Credentials with Selective Disclosure using BBS Signatures.
Maintainer: W3C Verifiable Credentials Working Group (email) (website)
The Data Integrity ECDSA Cryptosuites v1.0Achieving Data Integrity using ECDSA with NIST-compliant curves.
Maintainer: W3C Verifiable Credentials Working Group (email) (website)
The Data Integrity EdDSA Cryptosuites v1.0Achieving Data Integrity using EdDSA with twisted Edwards elliptic curves.
Maintainer: W3C Verifiable Credentials Working Group (email) (website)
JAdESSpecification for JAdES digital signatures, specifying signatures methods under baselines B, T, LT, and LTA. These signature specifications have legal validity across the European Union as per the eIDAS directive. They are in use by the European Digital Credentials for Learning and the European Blockchain Services Infrastructure.
Maintainer: European Commission (email) (website)
JSON Web Signatures for Data Integrity ProofsThis document has been withdrawn due to resolutions from the working group.
Maintainer: W3C Verifiable Credentials Working Group (email) (website)
Securing Verifiable Credentials using JOSE and COSEThis specification defines how to secure credentials and presentations conforming to the Verifiable Credentials Data Model, with JSON Object Signing and Encryption (JOSE), and CBOR Object Signing and Encryption (COSE).
Maintainer: W3C Verifiable Credentials Working Group (email) (website)

5. Media Type Extensions

SpecificationDescription

A. References

A.1 Normative references

[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174

A.2 Informative references

[JSON-LD11]
JSON-LD 1.1. Gregg Kellogg; Pierre-Antoine Champin; Dave Longley. W3C. 16 July 2020. W3C Recommendation. URL: https://www.w3.org/TR/json-ld11/