[DRAFT] Verifiable Credentials Working Group Charter
The mission of the Verifiable Credentials Working Group is to support the verifiable credentials ecosystem by maintaining existing specifications and adding new functionality that supports desired ecosystem use cases.
This proposed charter is available on GitHub. Feel free to raise issues.
| Charter Status | See the group status page and detailed change history. |
|---|---|
| Start date | 2026 April 1 |
| End date | 2028 April 1 |
| Chairs |
Phil Archer (GS1) Brent Zundel (Tradeverifyd) |
| Team Contacts | Ivan Herman (0.20 FTE) |
| Meeting Schedule |
Teleconferences: 1-hour calls will be held weekly, plus additional special-topic calls as needed.
Face-to-face: We will meet during the W3C's annual Technical Plenary week; additional face-to-face meetings may be scheduled by consent of the participants, usually no more than 3 per year. |
Motivation and Background
In the past few years the Working Group has developed a family of specifications in the area of Verifiable Credentials. They provide a mechanism to express "credentials" (driver's licenses, education degrees, vital records, etc.) on the Web in a digital format that is cryptographically secure, privacy respecting, and machine-verifiable. These technologies have already been deployed in production to many tens of millions of people and are being increasingly adopted by various institutions, governmental and otherwise, in different countries around the globe.
Readers that are new to this work should read the Verifiable Credentials Overview W3C Note, published by the Working Group. The Note explains some of the terminology used in this charter, e.g., Verifiable Credentials and Presentations, Data Integrity, and cryptosuites. It also provides a technical overview of how the various specifications relate to one another.
The group is adding work that has received several years of incubation and broad support from the community while maintaining previously published specifications. Once new Recommendations are published, this Working Group will maintain the complete family of specifications and related notes.
Scope
For new Recommendations listed below, the Working Group will complete them and then will continue to maintain those specifications. For all published Recommendations, the Working Group will maintain those specifications, ensuring that no Class 4 changes are introduced except as needed to address any serious security issues that arise.
Out of Scope
The following features are out of scope, and will not be addressed by this Working Group:
- The mandate of any specific style of supporting infrastructure, such as a Distributed Ledger (DLT), for a Verifiable Credentials ecosystem
- The specification of new cryptographic primitives
Deliverables
Updated document status is available on the group publication status page.
Draft state indicates the state of the deliverable at the time of the charter approval. Expected completion indicates when the deliverable is projected to become a Recommendation, or otherwise reach a stable state.
Normative Specifications
The Working Group will deliver the following W3C normative specifications:
- Verifiable Credential Render Method v1.0
-
This specification describes mechanisms that can be used to represent a Verifiable Credential through a visual, auditory, or haptic medium. It covers rendering a Verifiable Credential to a physical document, digital image, radio frequency, screen reader, or braille output.
Draft state: Working Draft
Expected completion: 2026-07-01
Adopted Draft: Verifiable Credential Render Method v1.0
Exclusion Draft: Verifiable Credential Rendering Methods v0.9 (Working Draft) Exclusion period began 2025-10-30; Exclusion period ends 2026-03-29. Finalize the final exclusion draft reference on 2026-01-28.
Exclusion Draft Charter: 2024 VCWG Charter
- Verifiable Credential Confidence Method v1.0
-
This specification defines a mechanism that can be used with the Verifiable Credentials Data Model v2.0 to increase a verifier's confidence about a particular subject identified in a verifiable credential.
Draft state: Working Draft
Expected completion: 2026-07-01
Adopted Draft: Verifiable Credential Confidence Method v1.0
Exclusion Draft: Confidence Method v1.0 (Working Draft) Exclusion period began 2025-10-30; Exclusion period ends 2026-03-29. Finalize the final exclusion draft reference on 2026-01-28.
Exclusion Draft Charter: 2024 VCWG Charter
- Verifiable Credential API for Lifecycle Management v1.0
-
This specification provides a set of HTTP Application Programming Interfaces (HTTP APIs) and protocols for issuing, verifying, presenting, and managing Verifiable Credentials.
Draft state: Community Group Draft
Expected completion: 2028-04-01
Adopted Draft: VCALM v0.9
- Verifiable Credential Barcodes v1.0
-
This specification describes a mechanism to protect optical barcodes, such as those found on driver's licenses (PDF417) and travel documents (MRZ), using Verifiable Credentials. The resulting Verifiable Credential representations are compact enough such that they fit in under 150 bytes and can thus be integrated with traditional two-dimensional barcodes that are printed on physical cards using standard printing processes.
Draft state: Community Group Draft
Expected completion: 2028-04-01
Adopted Draft: Verifiable Credential Barcodes v0.7
- Data Integrity BBS Cryptosuites v1.0
-
This specification describes a Data Integrity Cryptosuite for use when generating digital signatures using the BBS signature scheme. The Signature Suite utilizes BBS signatures to provide selective disclosure and unlinkable derived proofs.
Draft state: Candidate Recommendation
Expected completion: 2027-04-01
Adopted Draft: Data Integrity BBS Cryptosuites v1.0
Exclusion Draft: BBS Cryptosuite v2023 (CR Snapshot) Exclusion period began 2024-04-04; Exclusion period ended 2024-06-03.
Exclusion Draft Charter: 2022 VCWG Charter
- Verifiable Credentials JSON Schema Specification v1.0
-
This specification provides a mechanism to make use of a Credential Schema in Verifiable Credential, leveraging the existing Data Schemas concept.
Draft state: Candidate Recommendation
Expected completion: 2027-04-01
Adopted Draft: Verifiable Credentials JSON Schema Specification
Exclusion Draft: Verifiable Credentials JSON Schema Specification (CR Snapshot) Exclusion period began 2023-11-21; Exclusion period ended 2024-01-20.
Exclusion Draft Charter: 2022 VCWG Charter
Maintenance Specifications
The Working Group will maintain the following W3C normative specifications without making any Class 4 changes except for serious security issues that arise.
- Verifiable Credentials Data Model (VCDM) 2.1
-
This specification defines the Verifiable Credentials Data Model 2.1 along with serializations of that data model. It will replace the current Verifiable Credentials Data Model 2.0 Recommendation.
Draft state: Recommendation
Expected completion: 2027-04-01
Adopted Draft: Verifiable Credentials Data Model v2.0
Exclusion Draft: Verifiable Credentials Data Model 2.0 (CR Snapshot) Exclusion period began 2024-02-01; Exclusion period ended 2024-04-01.
Exclusion Draft Charter: 2022 VCWG Charter
- Verifiable Credential Data Integrity 1.1
-
This specification is a general framework to associate proofs of integrity for Verifiable Credentials and concrete serializations for each of the defined syntaxes. The Working Group would welcome the usage of these techniques for data in general, but its scope will be to solve Verifiable Credentials use cases. The specific set of concrete serializations and cryptosuites appear as separate specification, all part of the same family of specifications.
Draft state: Recommendation
Expected completion: 2027-04-01
Adopted Draft: Verifiable Credential Data Integrity 1.0
Exclusion Draft: Verifiable Credential Data Integrity 1.0 (CR Snapshot) Exclusion period began 2023-11-21; Exclusion period ended 2024-01-20.
Exclusion Draft Charter: 2022 VCWG Charter
- Data Integrity ECDSA Cryptosuites v1.1
-
This specification describes a Data Integrity Cryptosuite for use when generating a digital signature using the Elliptic Curve Digital Signature Algorithm (ECDSA).
Draft state: Recommendation
Expected completion: 2027-04-01
Adopted Draft: Data Integrity ECDSA Cryptosuites v1.0
Exclusion Draft: Data Integrity ECDSA Cryptosuites v1.0 (CR Snapshot) Exclusion period began 2023-11-21; Exclusion period ended 2024-01-20.
Exclusion Draft Charter: 2022 VCWG Charter
- Data Integrity EdDSA Cryptosuites v1.1
-
This specification describes a Data Integrity cryptographic suite for use when creating or verifying a digital signature using the twisted Edwards Curve Digital Signature Algorithm (EdDSA) and Curve25519 (ed25519).
Draft state: Recommendation
Expected completion: 2025-04-01
Adopted Draft: Data Integrity EdDSA Cryptosuites v1.0
Exclusion Draft: Data Integrity EdDSA Cryptosuites v1.0 (CR Snapshot) Exclusion period began 2023-11-21; Exclusion period ended 2024-01-20.
Exclusion Draft Charter: 2022 VCWG Charter
- Securing Verifiable Credentials using JOSE and COSE v1.1
-
This specification defines how to secure credentials and presentations conforming to the Verifiable Credential data model with JSON Object Signing and Encryption (JOSE), Selective Disclosure for JWTs, and CBOR Object Signing and Encryption (COSE).
Draft state: Recommendation
Expected completion: 2027-04-01
Adopted Draft: Securing Verifiable Credentials using JOSE and COSE Recommendation
Exclusion Draft: Securing Verifiable Credentials using JSON Web Tokens (CR Snapshot) Exclusion period began 2024-04-25; Exclusion period ended 2024-06-24.
Exclusion Draft Charter: 2022 VCWG Charter
- Bitstring Status List v1.1
-
This specification describes a privacy-preserving, space-efficient, and high-performance mechanism for publishing status information such as suspension or revocation of Verifiable Credentials through use of bitstrings.
Draft state: Recommendation
Expected completion: 2027-04-01
Adopted Draft: Bitstring Status List v1.0
Exclusion Draft: Verifiable Credentials Status List v1.0 (CR Snapshot) Exclusion period began 2024-05-21; Exclusion period ended 2024-07-20.
Exclusion Draft Charter: 2022 VCWG Charter
- Controlled Identifiers v1.1
-
A controlled identifier document contains cryptographic material and lists service endpoints for the purposes of verifying cryptographic proofs from, and interacting with, the controller of an identifier.
Draft state: Recommendation
Expected completion: 2027-04-01
Adopted Draft: Controlled Identifiers v1.0
Exclusion Draft: Controller Documents v1.0 (First Public Working Draft) Exclusion period began 2024-05-23; Exclusion period ended 2024-07-22.
Exclusion Draft Charter: 2022 VCWG Charter
Tentative Deliverables
Depending on the incubation progress, interest from multiple implementers, and the consensus of the Group participants, the Working Group may adopt the following documents as Rec-track specifications:
- Verifiable Credentials Over Wireless v1.0
-
This specification establishes a number of wireless protocols that can be used to request and present verifiable credentials over electromagnetic communication devices such ones supporting Near Field Communication (NFC) and Bluetooth Low Energy (BLE).
Draft state: Community Group Draft
- Verifiable Credentials Refresh v1.0
-
Verifiable Credentials can expire. It is useful to provide instructions on refreshing the credential for the times when expiration is imminent or has already occurred. The refresh can be performed manually or, with the prior consent of the credential holder, automatically. This specification defines manual and automatic refresh mechanisms that Verifiable Credential issuers can use to enhance the experience when using their credentials.
Draft state: Community Group Draft
- Quantum-Safe Cryptosuites v1.0
-
This specification describes several Data Integrity Cryptosuites for use when generating a digital signature using Post-Quantum digital signature algorithms.
Draft state: Community Group Draft
- Verifiable Issuers and Verifiers v1.0
-
This specification defines a data model for an entity to express other entities that it trusts to issue or verify specific types of verifiable credentials.
Draft state: Community Group Draft
Other Deliverables
Other non-normative deliverables may be created, such as:
- Up-to-date test suites for all normative deliverables
- A Threat Model for Verifiable Credentials
- A implementation interoperability dashboard
- An implementation and/or developer guide
The Working Group may also update Notes published under previous charters.
Timeline
- April 2026: Working group starts operating under this charter.
- July 2026: Working group publishes Render Method and Confidence Method as Recommendations.
- July 2027: Working group publishes all non-tentative deliverables as Candidate Recommendations.
- April 2028: Publication of all Recommendation Track documents
Success Criteria
In order to advance beyond Candidate Recommendation, each normative specification is expected to have at least two independent interoperable implementations of every feature defined in the specification, where interoperability can be verified by passing open test suites. A feature is a distinct, normatively required, concretely implementable piece of functionality, such as a data model property or algorithm, that provides value by allowing a system to achieve a specific use case.
There should be testing plans for each specification, starting from the earliest drafts.
To promote interoperability, all changes made to specifications in Candidate Recommendation or to features that have deployed implementations should have tests. Testing efforts should be conducted via the the VCWG's test infrastructure.
Each specification should contain separate sections detailing all known security and privacy implications for implementers, Web authors, and end users.
For specifications of technologies that directly impact user experience, such as content technologies, as well as protocols and APIs which impact content: Each specification should contain a section on accessibility that describes the benefits and impacts, including ways specification features can be used to address them, and recommendations for maximizing accessibility in implementations.
This group is expected to be guided by the following documents:
All new features should have expressions of interest from at least two potential implementors before being incorporated in the specification.
Coordination
For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, privacy, and security with the relevant Working and Interest Groups, and with the TAG. Invitation for review must be issued during each major standards-track document transition, including FPWD. The Working Group is encouraged to engage collaboratively with the horizontal review groups throughout development of each specification. The Working Group is advised to seek a review at least 3 months before first entering CR and is encouraged to proactively notify the horizontal review groups when major changes occur in a specification following a review.
Additional technical coordination with the following Groups will be made, per the W3C Process Document:
W3C Groups
- Decentralized Identifier Working Group
- To synchronize on cryptography-related vocabularies and definitions.
- Web of Things Working Group
- To synchronize on the needs and requirements of the WoT community, in particular on the subject of WoT Thing Descriptions, regarding digital signatures.
- Credentials Community Group
- Coordination on other specifications incubated by the Credentials Community Group that might utilize the output of this Working Group.
- Accessible Platform Architecture (APA) Working Group
- Coordinate on accessibility use cases for verifiable credentials, and work jointly on a successor publication to inaccessible CAPTCHAs.
- Federated Identity Working Group
- Contribute to the development, by that group, of a Threat Model of Digital Credentials-related technologies.
External Organizations
- Internet Engineering Task Force
- The Working Group will seek security review from the IETF, coordinated through the Liaison.
- Internet Engineering Task Force Crypto Forum Research Group
- To perform broad horizontal reviews on the output of the Working Group and to ensure that new pairing-based and post-quantum cryptographic algorithms and parameters can be integrated into the Data Integrity ecosystem.
- National Institute of Standards and Technology, U.S. Department of Commerce
- To coordinate in ensuring that new pairing-based and post-quantum cryptographic algorithms and parameters can be integrated into the Data Integrity ecosystem.
- The American Civil Liberties Union
- To coordinate on ensuring that the deliverables of the Working Group are a net positive for civil liberties.
- Decentralized Identity Foundation Interoperability Working Group
- To coordinate on broad horizontal review and integration of the specifications developed by the Working Group into the Decentralized Identity Foundation's ecosystem.
- European Telecommunications Standards Institute - Electronic Signatures and Infrastructure Technical Committee
- To coordinate in ensuring that eIDAS-compliant systems can be built on top of the specifications developed by the Working Group.
- 1EDTECH (formerly IMS Global)
- Ensure that the badges being modeled and expressed by the Open Badges community are compatible with the Verifiable Credentials WG.
- ISO/IEC JTC 1/SC 17/WG 10
- Ensure that the mobile driving licenses being modeled and expressed by the ISO SC17 WG10 community are compatible with the work of the Verifiable Credentials WG.
- ISO/IEC JTC 1/SC 17/WG 4
- Ensure that the 23220-2 data model expressed by the ISO SC17 WG4 community is compatible with the work of the Verifiable Credentials WG.
Participation
To be successful, this Working Group is expected to have 6 or more active participants for its duration, including representatives from the key implementors of this specification, and active Editors and Test Leads for each specification. The Chairs, specification Editors, and Test Leads are expected to contribute half of a working day per week towards the Working Group. There is no minimum requirement for other Participants.
The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication. The group also welcomes non-Members to make technical contributions for ongoing work, provided they agree to the terms of the W3C Patent Policy.
The Chairs should periodically look through the non-Members who have contributed to the Working Group of the W3C Credentials Community Group and consider whether each one should be invited to participate as an Invited Expert. If a non-Member contributor would like to participate in meetings, they are encouraged to apply to be an Invited Expert.
Participants in the group are required (by the W3C Process) to follow the W3C Code of Conduct.
Communication
Technical discussions for this Working Group are conducted in public: the meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed in public repositories and may permit direct public contribution requests. The meetings themselves are not open to public participation, however.
Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the Verifiable Credentials Working Group home page.
Most Verifiable Credentials Working Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis.
This group primarily conducts its technical work on teleconferences and GitHub issues. The public is invited to review, discuss and contribute to this work.
The group may use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a participant requests such a discussion.
Decision Policy
This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 5.2.1, Consensus). Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required.
However, if a decision is necessary for timely progress and consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote and record a decision along with any objections.
To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional for a period of one calendar week. A call for consensus (CfC) can be issued for any resolution (for example, via email, GitHub issue or web-based survey), with a response period of one calendar week, depending on the chair's evaluation of the group consensus on an issue. If no objections are raised by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group.
All decisions made by the group should be considered resolved unless and until new information becomes available or unless reopened at the discretion of the Chairs.
This charter is written in accordance with the W3C Process Document (Section 5.2.3, Deciding by Vote) and includes no voting procedures beyond what the Process Document requires.
Patent Policy
This Working Group operates under the W3C Patent Policy (Version of 15 May 2025). To promote the widest adoption of Web standards, W3C seeks to issue Web specifications that can be implemented, according to this policy, on a Royalty-Free basis. For more information about disclosure obligations for this group, please see the licensing information.
Licensing
This Working Group will use the W3C Software and Document license for all its deliverables.
About this Charter
This charter has been created according to section 3.4 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.
Charter History
The following table lists details of all changes from the initial charter, per the W3C Process Document (section 4.3, Advisory Committee Review of a Charter):
| Charter Period | Start Date | End Date | Changes |
|---|---|---|---|
| Initial Charter | 14 April 2017 | 31 March 2019 | |
| Update | 2018-08-01 (plh): Updated Chairs and Team Contacts | ||
| Update | 2018-09-12 (coralie): Updated Chairs | ||
| Charter Extension | 1 April 2019 | 30 September 2019 | 2019-03-29 (kaz): Charter period extended till 30 September 2019 |
| Proposed | 15 November 2019 | 30 December 2021 |
(plh): AC vote for maintenance mode charter |
| Initial charter for maintenance mode WG | 20 January 2020 | 30 December 2021 |
2020-01-10 (ivan): The Group is in maintenance mode (AC Vote ended) |
| Update |
2020-06-15 (ivan): Removed Matt Stone as a co-chair. |
||
| Update |
2020-07-24 (xueyuan): Daniel Burnett re-appointed as group Chair. |
||
| Rechartered | 15 December 2020 | 30 December 2021 | New Patent Policy |
| Charter Extension | 30 December 2021 | 30 April 2022 | 2021-12-20: Charter extended till 30 April 2022 |
| New charter work started | 20 December 2021 | 05 May 2022 | 2021-12-20 (Ivan): Proposed work on an update of the VC Data model, and a new deliverable on VC Data Integrity. See the Advanced Notice, and the changes on the proposed charter in the advanced notice period. |
| New charter proposed | 06 May 2022 | 03 June 2022 | 2022-05-05 (Ivan): AC Vote for the new charter |
| Work starts with new charter | 13 June 2022 | 15 June 2024 | 2022-06-13 (Ivan): AC Vote ends, WG is not in maintenance mode any more; Kristina Yasuda replaces Wayne Chang as co-chair. |
| Staff contact assignment updated | 28 Apr 2023 | 15 June 2024 | 2023-04-28 (Ivan): staff contact assignment was increased to 0.20 (from 0.15). |
| "BBS Cryptosuite" becomes officially a normative specification deliverable | 18 May 2023 | The document has fulfilled the criteria for conditional normative specification to be added to the official deliverables of the Working Group. | |
| Update | 31 October 2023 | 15 June 2024 | 2023-10-31 (Xueyuan): Brent Zundel is re-appointed and Kristina Yasuda steps down as co-chair of the group. |
| Update | 1 April 2024 | 15 June 2024 | 2024-04-01 (Ivan): Brent Zundel is re-appointed as chair of the group. |
| Working on new charter | 2024-03-27 | 2024-03-27 (Ivan): Work started on extension of the previous charter. | |
| Charter Extension | 2024-04-21 | 2025-01-15 | 2024-05-21 (Ivan): Charter extended until 2025-01-15. |
| New charter proposed | 21 August 2024 | 2024-09-18 | 2024-08-21 (Ivan): AC Vote for the new charter |
| Work starts with new charter | 2024-10-07 | 2026-10-11 | |
| Update | 2025-10-09 | 2025-10-09 (Ivan): Appointed Phil Archer as co-chair; updated Brent's affiliation | |
| Working on the new charter | 2025-11-24 | 2025-11-24 (Ivan): Work started as a replacement of the previous charter. |