Verifiable Credentials Overview v1.0 W3C Group Note 30 July 2026 More details about this document This version: https://www.w3.org/TR/2026/NOTE-vc-overview-1.0-20260730/ Latest published version: https://www.w3.org/TR/vc-overview-1.0/ Latest editor's draft: https://w3c.github.io/vc-overview/ History: https://www.w3.org/standards/history/vc-overview-1.0/ Commit history Editor: Ivan Herman ( W3C ) Authors: Greg Bernstein ( Invited Expert ) Daniel C. Burnett ( ConsenSys ) David Chadwick ( Crossword Cybersecurity PLC ) Gabe Cohen ( Block ) Michael B. Jones ( Invited Expert ) Dave Longley ( Digital Bazaar ) Manu Sporny ( Digital Bazaar ) Orie Steele ( Transmute ) Ted Thibodeau Jr ( OpenLink Software ) Brent Zundel ( mesur.io ) Feedback: GitHub w3c/vc-overview ( pull requests , new issue , open issues ) [email protected] with subject line [vc-overview-1.0] … message topic … ( archives ) Copyright © 2026 World Wide Web Consortium . W3C ® liability , trademark and permissive document license rules apply. Abstract 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. 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 standards and drafts index . 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. The W3C Patent Policy does not carry any licensing requirements or commitments on this document. This document is governed by the 18 August 2025 W3C Process Document . Table of Contents Abstract Status of This Document 1. Introduction 1.1 High Level View of the Specifications 2. Ecosystem Overview 3. Verifiable Credentials Data Model 3.1 Basic Concepts 3.1.1 Claims, Properties 3.1.2 Verifiable Credentials 3.1.3 Verifiable Presentations 3.2 Serialization in JSON 3.3 Checking Structure with JSON Schemas 4. Securing Credentials 4.1 Enveloping Proofs 4.1.1 Example: the Core Example Secured with JOSE and COSE 4.2 Embedded Proofs 4.2.1 Creation of Proofs in Data Integrity 4.2.2 Data Integrity of Credentials 4.2.3 Cryptosuites 4.2.3.1 Full Disclosure Schemes 4.2.3.2 Selective Disclosure Schemes 4.2.4 Example: the Core Example Secured with EdDSA and ECDSA 5. Bitstring Status List 6. Additional Publications 6.1 Working Group Notes 6.2 Standard Vocabularies A. The complete example B. Lifecycle Details C. References C.1 Informative references 1. Introduction This document provides a non-normative, high-level overview for W3C 's Verifiable Credential specifications and serves as a roadmap for the documents that define, describe, and secure these credentials. It is not the goal of this document to be very precise, nor does this overview cover all the details. The intention is to provide users, implementers, or anyone interested in the subject, a general understanding of the concepts and how the various specifications, published by the Verifiable Credentials Working Group, fit together. 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. 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 v1.0 [ CID-1.0 ] 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 ]. Figure 1 Verifiable Credentials Working Group Recommendations Note As of May 2025, all but two of these documents have been published as W3C "Recommendations", which is the W3C terminology for Web Standards. The two exceptions are the Verifiable Credentials JSON Schema Specification and the Data Integrity BBS Cryptosuites v1.0 specifications; though technically complete, they are still "Candidate" Recommendations. The reasons are different. The former has not yet been implemented by at least two mutually independent implementations (which is the requirement to be published as standards) whereas the latter has to wait until the underlying cryptographic technique (i.e., The BBS Signature Scheme ) is finalized by the IETF. It is expected that these two documents will be published as Web Standards soon. 2. Ecosystem Overview The Verifiable Credential specifications rely on an ecosystem consisting of entities playing different "roles". The main roles are: Issuer An 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. Holder An 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. Verifier An 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. Figure 2 The roles and information flows forming the basis for the VC Data Model. 3. Verifiable Credentials Data Model 3.1 Basic Concepts 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 ]. In that case, that 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.) 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. 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. Figure 5 Basic components of a verifiable presentation. 3.2 Serialization in JSON In the [ VC-DATA-MODEL-2.0 ] specification, as in the other documents, Verifiable Credentials and Presentations are mostly expressed in JSON [ RFC7519 ], more specifically [ JSON-LD11 ]. In this serialization, properties of claims are represented as JSON names, and values as JSON literals or objects. Subjects of claims are either explicitly identified by an id property, or implicitly by appearing as an object of another claim. Standard properties defined by the [ VC-DATA-MODEL-2.0 ] form a distinct set of JSON names, referred to as a (standard) vocabulary . An important characteristic of Verifiable Credentials in JSON-LD is that it favors a decentralized and permissionless approach to extend to a new application area through application-specific set of properties, i.e., vocabularies, distributed on the Web. Anyone can "publish" such a vocabulary, following some rules described in the extensibility section of the specification. The following JSON-LD code is an example for a simple Credential. It states that the person named "Pat", identified by https://www.example.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 (identified by https://www.w3.org/ns/credentials/v2 ), 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" } } } Figure 6 shows the same Credential, but represented as a graph of claims, as described in 3.1.1 Claims, Properties . Figure 6 Credential in Example 1 represented as a collection of claims. Note The Credential in Example 1 is used throughout this document to show how to apply additional features defined by the various specifications. The Credential in Example 1 , issued by Example University, is stored by a holder (who may be a person, a digital wallet, or any other entity). On request, the holder may "present" a Credential to a verifier, encapsulated in a Verifiable Presentation. This is how the result may look like in the JSON-LD serialization: Example 2 : Presenting the Credential { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "type": "VerifiablePresentation", "id": "urn:uuid:313801ba-24b7-11ee-be02-ff560265cf9b", "holder": "did:example:12345678", "verifiableCredential": { "@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", "validUntil": "2020-12-31T00:00:00Z", "credentialSubject": { "id": "https://www.example.org/persons/pat", "name": "Pat", "alumniOf": { "id": "did:example:c276e12ec21ebfeb1f712ebc6f1", "name": "Example University" } } } } Note that the holder could have presented several Credentials within the same presentation or create a new Credential by either combining it with others, or removing some claims as irrelevant for the specific context. 3.3 Checking Structure with JSON Schemas A significant part of the integrity of a Verifiable Credential comes from the ability to structure its contents so that all three parties — issuer, holder, verifier — may have a consistent mechanism of trust in interpreting the data that they are provided with. One way of doing that is to use [ JSON-SCHEMA ] to check the structural validity of the Credential. The Verifiable Credentials JSON Schema Specification [ VC-JSON-SCHEMA ] specification adds standard properties to express the association of a Credential with a JSON Schema. Consider the following example: Example 3 : A Simple Credential with a JSON Schema { "@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" } }, "credentialSchema": { "id": "https://university.example/Credential-schema.json", "type": "JsonSchema" } } When dereferenced, the URL https://university.example/Credential-schema.json should return a JSON Schema, for example: Example 4 : JSON Schema for the Simple Credential { "$id": "https://university.example/schemas/credential.json", "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "ExampleAlumniCredential", "description": "Alumni Credential using JsonSchema", "type": "object", "properties": { "credentialSubject": { "type": "object", "properties": { "alumniOf": { "type": "string", "format": "url" } }, "required": [ "alumniOf" ] } } } Using this JSON Schema, a verifier can check whether the Credential is structurally valid or not. For security reasons one may want to go a step further: check/verify the JSON Schema itself to see if, for example, it has been tampered with. This can be done by referring to the JSON Schema indirectly through a separate Verifiable Credential . The reference to such a Verifiable Credential looks very much like Example 3 except for the value of the type : Example 5 : A Simple Credential with a JSON Schema 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" } }, "credentialSchema": { "id": "https://university.example/Credential-schema-credential", "type": "JsonSchemaCredential" } } In this case, when dereferenced, the URL https://university.example/Credential-schema-credential should return a Verifiable Credential, whose credentialSubject property refers to the required JSON Schema (i.e., https://university.example/Credential-schema.json ). See the example in the Verifiable Credentials JSON Schema Specification specification for an example and for further details. 4. Securing Credentials 4.1 Enveloping Proofs 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 [ rfc9901 ]. 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 use of CBOR means that the final representation of the Verifiable Credential (or Presentation) can have a significantly reduced footprint which can be, for example, shown in a QR Code. The [ rfc9901 ] is a variant of JOSE, which allows for the selective disclosure of individual claims. Claims can be selectively hidden or revealed to the verifier, but all claims are cryptographically protected against modification. This approach is obviously more complicated than the JOSE case but, from the Credentials point of view, the structure is again similar. The original Credential is the payload for SD-JWT; and it is the holder's responsibility to use the SD-JWT when presenting the Credential to a verifier using selective disclosure. 4.1.1 Example: the Core Example Secured with JOSE and COSE Example 6 shows the Credential example shown in Example 1 , enriched with a reference to a JSON Schema in Example 3 . It is secured by two different enveloping proofs, namely JOSE and COSE. Example 6 : A Simple Credential in JWT (unencoded) Credential jose cose { "@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" } }, "credentialSchema": { "id": "https://university.example/Credential123-schema-credential", "type": "JsonSchemaCredential" } } Protected Headers { "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro", "alg": "ES256" } application/vc { "@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" } }, "credentialSchema": { "id": "https://university.example/Credential123-schema-credential", "type": "JsonSchemaCredential" } } application/vc+jwt eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ . eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwczovL3VuaXZlcnNpdHkuZXhhbXBsZS9DcmVkZW50aWFsMTIzIiwidHlwZSI6WyJWZXJpZmlhYmxlQ3JlZGVudGlhbCIsIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl0sImlzc3VlciI6ImRpZDpleGFtcGxlOjJnNTVxOTEyZWMzNDc2ZWJhMmw5ODEyZWNiZmUiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDAwOjAwOjAwWiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5vcmcvcGVyc29ucy9wYXQiLCJuYW1lIjoiUGF0IiwiYWx1bW5pT2YiOnsiaWQiOiJkaWQ6ZXhhbXBsZTpjMjc2ZTEyZWMyMWViZmViMWY3MTJlYmM2ZjEiLCJuYW1lIjoiRXhhbXBsZSBVbml2ZXJzaXR5In19LCJjcmVkZW50aWFsU2NoZW1hIjp7ImlkIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvQ3JlZGVudGlhbDEyMy1zY2hlbWEtY3JlZGVudGlhbCIsInR5cGUiOiJKc29uU2NoZW1hQ3JlZGVudGlhbCJ9fQ . MculdjIGng9TprIYASk1CN17qKg9okIHGDz5cr0TkdWQqloKOm5Ygn18h3sd2-fN-kQ2XX-PzeM9MkkiKeOIWg application/vc { "@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" } }, "credentialSchema": { "id": "https://university.example/Credential123-schema-credential", "type": "JsonSchemaCredential" } } application/cbor-diagnostic / cose-sign1 / 18([ / protected / << { / alg / 1 : -35 / ES384 / } >>, / unprotected / { }, / payload / h'7b224063...6c227d7d', / signature / h'b6c80657...f8eacf78' ]) application/vc+cose d28444a1013822a05902417b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a2268747470733a2f2f756e69766572736974792e6578616d706c652f43726564656e7469616c313233222c2274797065223a5b2256657269666961626c6543726564656e7469616c222c224578616d706c65416c756d6e6943726564656e7469616c225d2c22697373756572223a226469643a6578616d706c653a3267353571393132656333343736656261326c393831326563626665222c2276616c696446726f6d223a22323031302d30312d30315430303a30303a30305a222c2263726564656e7469616c5375626a656374223a7b226964223a2268747470733a2f2f7777772e6578616d706c652e6f72672f706572736f6e732f706174222c226e616d65223a22506174222c22616c756d6e694f66223a7b226964223a226469643a6578616d706c653a633237366531326563323165626665623166373132656263366631222c226e616d65223a224578616d706c6520556e6976657273697479227d7d2c2263726564656e7469616c536368656d61223a7b226964223a2268747470733a2f2f756e69766572736974792e6578616d706c652f43726564656e7469616c3132332d736368656d612d63726564656e7469616c222c2274797065223a224a736f6e536368656d6143726564656e7469616c227d7d5840b6c80657cbf659997741142ff8fc07fdccb294b3f3d09a71a3e619e81cdd369726f27c6431753fcf47ac44cc6622d292e4469306c99cec1f5e5754a3f8eacf78 4.2 Embedded Proofs 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. Figure 7 View of the proof generation steps. Transformation is a process described by a transformation algorithm that takes input data and prepares it for the hashing process. In the case of data serialized in JSON this transformation includes the removal of all the artifacts that do not influence the semantics of the data, such as spaces, new lines, the order of JSON names, etc. (a step often referred to as canonicalization ). In some cases the transformation may be more involved. Hashing is a process described by a hashing algorithm that calculates an identifier for the transformed data using a cryptographic hash function . Typically, the size of the resulting hash is smaller than the data, which makes it more suitable for complex cryptographic functions like digital signatures. Proof Generation is a process described by a proof method that calculates a value that protects the integrity of the input data from modification or otherwise proves a certain desired threshold of trust. A typical example is the application of a cryptographic signature using asymmetric keys, generating the signature of the data. Verification of a proof involves repeating the same transformation and hashing steps on the verifier's side and, depending on the proof method, validating the newly calculated hash value with the proof associated with the data. In the case of a digital signature, this means verifying, using the cryptographic algorithms associated with the asymmetric keys, that the proof value indeed signs the newly calculated hash. 4.2.2 Data Integrity of Credentials The Verifiable Credential Data Integrity 1.0 [ VC-DATA-INTEGRITY ] specification starts with the general structure and defines a set of standard properties describing the details of the proof generation process. The specific details (i.e., the transformation, hash, and/or proof method algorithms) are defined by separate cryptosuites . The Working Group has defined a number of such cryptosuites as separate specifications, see 4.2.3 Cryptosuites below. The core property, in the general structure, is called proof . This property embeds a claim in the Credential, referring to a separate collection of claims (referred to as a Proof Graph ) detailing all the claims about the proof itself: Example 7 : Skeleton of a proof added to a 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" } }, "credentialSchema": { "id": "https://university.example/Credential123-schema-credential", "type": "JsonSchemaCredential" }, "proof": { "type": "DataIntegrityProof", … // All the details about the proof … "proofValue": "zQeVb…Wx" } } Note the proofValue property, whose object is the result of the proof generation process. Note The proof value is for illustrative purposes only, and does not reflect the result of real cryptographic calculations. The definition of proof introduces a number of additional properties. Some of these are metadata properties on the proof itself, like created , expires , or domain . Others provide the necessary details on the proof generation process itself, like cryptosuite , nonce (if needed), or verificationMethod that usually refers to cryptographic keys. The exact format of the public keys, when used for Credentials, is defined in the [ CID-1.0 ] specification, and is based on either the JWK [ RFC7517 ] format or a Multibase encoding of the keys, called Multikey . Details of the key values are defined by other communities (IETF, cryptography groups, etc.) and are dependent on the specific cryptographic functions they operate with. It is possible to embed several proofs for the same Credential. These may be a set of independent proofs (based, for example, on different cryptosuites, to accommodate to the specificities of different verifiers), but may also be a "chain" of proofs that must be evaluated in a given order. A proof may also specify its "purpose" via the proofPurpose property: different proofs may be provided for authentication, for assertion, or for key agreement protocols. These details are also defined in the [ CID-1.0 ] specification. The verifier is supposed to choose the right proof depending on the purpose of its own operations, which is yet another possible reason why the holder or the issuer may provide several proofs for the same Credential. 4.2.3 Cryptosuites The Working Group has published three cryptosuite documents: 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 ]. As their name suggests, the documents rely on existing cryptographic signature schemes: the Edwards-Curve Digital Signature Algorithm (EdDSA) specification [ RFC8032 ], the Elliptic Curve Digital Signature Algorithm (ECDSA) specification [ FIPS-186-5 ], and the BBS Signature Scheme [ CFRG-BBS-SIGNATURE ], respectively. Figure 8 provides an overall view of the six cryptosuites defined by the three recommendations. They all implement the general pipeline of proof generation as described in section 4.2.1 . As shown on the figure, one axis of differentiation is the data transformation function, i.e., the canonicalization of the JSON serialization: two cryptosuites use JSON Canonicalization (JCS) [ RFC8785 ], while the other four use RDF Dataset Canonicalization (RDFC-1.0) [ RDF-CANON ]. The other axis is whether the cryptosuite provides selective disclosure, which is the case for two of the six cryptosuites. Figure 8 Overall view of cryptosuites. Note A common characteristic of all these cryptosuites is that keys must always be encoded using the Multikey encoding. For the ECDSA case the keys may also carry the choice of the hash functions to be used by the proof generation algorithm. This provides yet another differentiation axis among cryptosuites. Note Applications may define their own cryptosuites by applying different transformation and/or cryptographic signature schemes in similar patterns. For example, it would be possible to define a cryptosuite using the SM2 algorithm [ RFC9563 ] instead of, say, EdDSA. 4.2.3.1 Full Disclosure Schemes The two EdDSA cryptosuites, as well as ecdsa-rdfc-2019 and ecdsa-jcs-2019 , follow a simple version of the proof generation pipeline as described in section 4.2.1 : the Credential is canonicalized (using either JCS or RDFC-1.0) and the result is hashed (using the hash functions as defined by the signature key). The calculation of the hash values depend on the canonicalization method: in the JCS case the canonical JSON data is hashed directly, whereas in the RDFC-1.0 case the individual canonicalized claims are first sorted and then concatenated before being hashed. However, before signing the hash values, there is an extra twist: the same pipeline is also used on a set of claims called proof options , i.e., all the claims of the proof graph except proofValue . This set of claims is also canonicalized and hashed, following the same process as for the Credential itself, yielding a second hash value. It is the concatenation of these two values that is signed by EdDSA or ECDSA, respectively, producing the value for the proofValue property. By doing so, the various proof metadata, as well as the public key reference itself, are also signed and become verifiable. 4.2.3.2 Selective Disclosure Schemes The ecdsa-sd-2023 and bbs-2023 cryptosuites provide selective disclosures of individual claims. In both cases, the process separates the base proof (calculated by the issuer for the holder), and the derived proof (which is typically calculated by the holder when selectively presenting credential claims to the verifier). To calculate the base proof, the Credential is supplemented with extra information that separates the mandatory and non-mandatory claims. Using that information, the issuer's transformation step in section 4.2.1 produces a data structure containing the hash of the proof options (much like in the case of the full disclosure schemes) and of the set of mandatory claims, plus the identification of mandatory claims. Some elements of this data structure are then signed, the resulting structure is converted into CBOR, and encoded to provide as a multibase-encoded proofValue . The derived proof is generated by the holder upon a request containing JSON pointers [ RFC6901 ] identifying the claims to be disclosed. To answer the request the information in the proofValue is used to create a reveal document , i.e., a new Credential containing the mandatory claims and the requested non-mandatory claims. Finally, the holder generates a derived proof for this reveal document, which is sent to the verifier. The verifier should be able to test the proof of the reveal document without having access to the original data and its (base) proof. With ecdsa-sd-2023 , each non-mandatory claim is signed separately by the issuer using a common, ephemeral ECDSA secret key, whose public counterpart is part of the both the base and derived proof values. That can be used to check the disclosed non-mandatory claims. The bbs-2023 cryptosuite relies on the cryptographic properties of the BBS scheme itself, which support the creation of proofs for the verification of selectively disclosed data. This is based on the mathematical nature of the BBS scheme: the BBS signature of all the claims (generated by the issuer and part of the base proof) can be reused by the holder to generate a BBS Proof of the subset of the claims (which is part of the derived proof). The BBS specific verification step ensures the required trust. It is worth noting that the bbs-2023 cryptosuite also offers a number of additional, privacy preserving options; see the sections on anonymous holder binding or credential-bound pseudonyms in the Data Integrity BBS Cryptosuites v1.0 specification. 4.2.4 Example: the Core Example Secured with EdDSA and ECDSA Example 8 shows the Credential example, shown in Example 1 and enriched with a reference to a JSON Schema in Example 3 . It is secured by two different embedded proofs, using the ecdsa-rdfc-2019 and eddsa-rdfc-2022 cryptosuites. Example 8 : EdDSA and ECDSA proofs added to a Credential Credential ecdsa eddsa { "@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" } }, "credentialSchema": { "id": "https://university.example/Credential123-schema-credential", "type": "JsonSchemaCredential" } } application/vc { "@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" } }, "credentialSchema": { "id": "https://university.example/Credential123-schema-credential", "type": "JsonSchemaCredential" }, "proof": { "type": "DataIntegrityProof", "created": "2026-07-23T12:38:45Z", "verificationMethod": "did:key:zDnaeVXRxJhtMRuw3dH9LPr8XSQtT48GZvWkG77d G5WUtvKLb", "cryptosuite": "ecdsa-rdfc-2019", "proofPurpose": "assertionMethod", "proofValue": "z5hsRvg1yFxs8KTKv4VvD5GbQZbFzgkXRVuUcPnBVqP9CGy99Djm1Gxk aVidAvkvMArYsfbaTHbzV2zXhoSd4srt8" } } application/vc { "@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" } }, "credentialSchema": { "id": "https://university.example/Credential123-schema-credential", "type": "JsonSchemaCredential" }, "proof": { "type": "DataIntegrityProof", "created": "2026-07-23T12:38:45Z", "verificationMethod": "did:key:z6MkpzmpvQ5VQtMVCZDpnBQ5sSW5TKGCDjQBeGcQ KWojftJu", "cryptosuite": "eddsa-rdfc-2022", "proofPurpose": "assertionMethod", "proofValue": "z5AszAFi2qVSgMhyf5NR4Za9euhZnvWzpPBdzt1rgzuWWB8V2E5VTuUd TFoH34Fa6Gxo5C71AFkmH2zHWZkPP3na6" } } When dereferenced, the URL value of the verificationMethod property should return a public key in Multikey format. For example: Example 9 : An ECDSA public key { "@context": [ "https://www.w3.org/ns/did/v1", "https://w3id.org/security/multikey/v1" ], "id": "did:example:2g55q912ec3476eba2l9812ecbfe#ecdsa-public-key", "type": "Multikey", "controller": "did:example:2g55q912ec3476eba2l9812ecbfe", "publicKeyMultibase": "z42twTcNeSYcnqg1FLuSFs2bsGH3ZqbRHFmvS9XMsYhjxvHN" } Note that the value of the verificationMethod property may have been the public key itself, instead of a reference to a separate resource containing the key. 5. Bitstring Status List It is often useful for an issuer of Verifiable Credentials to link to a location where a verifier can check whether 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. However, doing so can place an impossible burden on both the server and client if the status information is as much as a few hundred bytes in size per credential across a population of hundreds of millions of holders. The Bitstring Status List v1.0 [ VC-BITSTRING-STATUS-LIST ] specification defines a highly compressible, highly space-efficient bitstring-based status list mechanism. Conceptually, a bitstring status list is a sequence of bits. When a single bit specifies a status, such as "revoked" or "suspended", then that status is expected to be true when the bit is set and false when unset. One of the benefits of using a bitstring is that it is a highly compressible data format since, in the average case, large numbers of credentials will remain unrevoked. If compressed using run-length compression techniques such as GZIP [ RFC1952 ] the result is a significantly smaller set of data: the default status list size is 131,072 entries, equivalent to 16 KB of single bit values and, when only a handful of verifiable credentials are revoked, GZIP compresses the bitstring down to a few hundred bytes. Figure 9 A visual depiction of the concepts outlined in this section. The specification introduces the credentialStatus property, as well as some additional sub-properties, that should be used to add this additional information to a Verifiable Credential. Example 10 shows the example from Example 8 , combined with the information on the credential status: the purpose of that status information, the reference to the bitstring, and the index into this bitstring for the enclosing credential: Example 10 : Verifiable Credential with a Reference to a Status List { "@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" } }, "credentialSchema": { "id": "https://university.example/Credential123-schema-credential", "type": "JsonSchemaCredential" }, "credentialStatus": { "id": "https://university.example/statuslist#123456", "type": "BitstringStatusListEntry", "statusPurpose": "revocation", "statusListIndex": "123456", "statusListCredential": "https://university.example/CredentialStatusList" } } The statusListCredential property, when dereferenced, should return a separate Credential for the status list. The status list itself is the subject of that Credential (which, of course, can also be signed). An example is: Example 11 : A Credential for a Bitstring Status List { "@context": [ "https://www.w3.org/ns/credentials/v2" ], "id": "https://university.example/CredentialStatusList", "type": ["VerifiableCredential", "BitstringStatusListCredential"], "issuer": "did:example:2g55q912ec3476eba2l9812ecbfe"", "validFrom": "2005-01-01T00:00:00", "credentialSubject": { "id": "https://university.example/statuslist#list", "type": "BitstringStatusList", "statusPurpose": "revocation", "encodedList": "uH4sIAAAAAAAAA-3BMQEAAADCoPVPbQwfoAAAAAAAAAAAAAAAAAAAAIC3AYbSVKsAQAAA" } } The core property in this case is encodedList , which is a base64url encoded version of the GZIP compressed bitstring status list. 6. Additional Publications 6.1 Working Group Notes The VC Working Group has also published, and maintains, a few additional documents in the form of Working Group Notes. Although these are not formal standards, they represent consensus among the Working Group Participants. These documents are: Verifiable Credentials Use Cases The use cases outlined in this document were, and are, instrumental in making progress toward standardization and interoperation of both low– and high–stake claims, with the goals of storing, transmitting, and receiving digitally verifiable proof of attributes such as qualifications and achievements. The use cases focus on concrete scenarios that the technology defined by the group aims to address (including for future revisions). Verifiable Credentials Implementation Guidelines 1.0 This document provides implementation guidance for Verifiable Credentials. Verifiable Credential Extensions This document serves as an unofficial list of 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. 6.2 Standard Vocabularies As explained in the introductory sections, the specifications define a number of standard vocabularies , i.e., standard sets of properties used as JSON names. These are used by Verifiable Credentials to ensure interoperability. Although the formal specifications of these terms are provided by the respective specifications, the vocabularies are also published as separate documents. This is done for an easier reference and overview, and these documents are also important if Credentials are used by applications based on RDF [ RDF11-CONCEPTS ]. These vocabulary documents are: Verifiable Credentials Vocabulary v2.0 Definition of property names defined, primarily, by the VC Data Model specification, with some terms defined by the VC JSON Schema specification. Security Vocabulary Property name definitions in the VC Data Integrity and the Controlled Identifiers specifications. Bitstring Status List Vocabulary Property name definitions in the Bitstring Status List specification. A. The complete example Example 12 shows the Credential example used throughout this document, enriched with a reference to a JSON Schema and to the status information. It is secured via different securing mechanisms defined for Verifiable Credentials. Example 12 : Verifiable Credential with a Reference to a Credential Schema and to a Status List Credential ecdsa eddsa bbs jose cose sd-jwt { "@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" } }, "credentialSchema": { "id": "https://university.example/Credential123-schema-credential", "type": "JsonSchemaCredential" }, "credentialStatus": { "id": "https://university.example/statuslist#123456", "type": "BitstringStatusListEntry", "statusPurpose": "revocation", "statusListIndex": "123456", "statusListCredential": "https://university.example/CredentialStatusList" } } application/vc { "@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" } }, "credentialSchema": { "id": "https://university.example/Credential123-schema-credential", "type": "JsonSchemaCredential" }, "credentialStatus": { "id": "https://university.example/statuslist#123456", "type": "BitstringStatusListEntry", "statusPurpose": "revocation", "statusListIndex": "123456", "statusListCredential": "https://university.example/CredentialStatusLis t" }, "proof": { "type": "DataIntegrityProof", "created": "2026-07-23T12:38:45Z", "verificationMethod": "did:key:zDnaeVXRxJhtMRuw3dH9LPr8XSQtT48GZvWkG77d G5WUtvKLb", "cryptosuite": "ecdsa-rdfc-2019", "proofPurpose": "assertionMethod", "proofValue": "z44muDGHKbg1oBD2xqE84jqknRkMGES6W7rb56zcnbj3zTVzHnRRSZSw wsFpPoK839VKfe5uaiYyziAGnWPm4QaDW" } } application/vc { "@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" } }, "credentialSchema": { "id": "https://university.example/Credential123-schema-credential", "type": "JsonSchemaCredential" }, "credentialStatus": { "id": "https://university.example/statuslist#123456", "type": "BitstringStatusListEntry", "statusPurpose": "revocation", "statusListIndex": "123456", "statusListCredential": "https://university.example/CredentialStatusLis t" }, "proof": { "type": "DataIntegrityProof", "created": "2026-07-23T12:38:45Z", "verificationMethod": "did:key:z6MkpzmpvQ5VQtMVCZDpnBQ5sSW5TKGCDjQBeGcQ KWojftJu", "cryptosuite": "eddsa-rdfc-2022", "proofPurpose": "assertionMethod", "proofValue": "zjX5JrGMVjghMcBtMAvA1pbDtTH2LSqewS7uXKNT6AEgaPxX2edeJHKc QGLwGvP4CeBBH6rpQoyfaSW4K2k5excs" } } application/vc { "@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" } }, "credentialSchema": { "id": "https://university.example/Credential123-schema-credential", "type": "JsonSchemaCredential" }, "credentialStatus": { "id": "https://university.example/statuslist#123456", "type": "BitstringStatusListEntry", "statusPurpose": "revocation", "statusListIndex": "123456", "statusListCredential": "https://university.example/CredentialStatusLis t" }, "proof": { "type": "DataIntegrityProof", "verificationMethod": "did:key:zUC7241RGtwEtF9nzcvXKSdHqsZGrhTnE2vCXkCb F1ZEqnx3Liro2sB6zUH1iUY6idajSUVxTjerLeXnhY343Xpem7mkbEQbkpRnp1mYkatu5eFJ7CU mhHR8tiEzP2y1tQaLcAj", "cryptosuite": "bbs-2023", "proofPurpose": "assertionMethod", "proofValue": "u2V0ChVhQpiu93Xfg_6sCFh8505wLzqd-aw7FZmE-NwHKOhBcUGXh68X 9hXnpx1YkJEvhbeYBc6YvaAO_KKMoi_J70Sjejfbi8_sE0I1gokrfyXn-tF9YQFSpFmjDiF3iFX n_RcM0StzK7gGIFCM4YYgyX-xAnW3pq55pIrtFHSJQO7wOSd6iet3GiHpGE_HGk6G6KLCUQT9YY INB09Z9e9x1K3jfEFcBcjaGlEphQsXQX4OIUnYhF0CXDRs-oiLmF6yGgx8kH7B2DQpg0xxN_a_E P3s0M81V0V_vc0N1MG2epa5ZHtLM29HkUyBlc2Taw4QZZzg_RB6ASFggHuJs0CzVNBNOjGyVvf2 lpNyp9oRQfJR3FElusFj54NuBZy9pc3N1ZXI" } } Protected Headers { "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro", "alg": "ES256" } application/vc { "@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" } }, "credentialSchema": { "id": "https://university.example/Credential123-schema-credential", "type": "JsonSchemaCredential" }, "credentialStatus": { "id": "https://university.example/statuslist#123456", "type": "BitstringStatusListEntry", "statusPurpose": "revocation", "statusListIndex": "123456", "statusListCredential": "https://university.example/CredentialStatusList" } } application/vc+jwt eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ . eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwczovL3VuaXZlcnNpdHkuZXhhbXBsZS9DcmVkZW50aWFsMTIzIiwidHlwZSI6WyJWZXJpZmlhYmxlQ3JlZGVudGlhbCIsIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl0sImlzc3VlciI6ImRpZDpleGFtcGxlOjJnNTVxOTEyZWMzNDc2ZWJhMmw5ODEyZWNiZmUiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDAwOjAwOjAwWiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5vcmcvcGVyc29ucy9wYXQiLCJuYW1lIjoiUGF0IiwiYWx1bW5pT2YiOnsiaWQiOiJkaWQ6ZXhhbXBsZTpjMjc2ZTEyZWMyMWViZmViMWY3MTJlYmM2ZjEiLCJuYW1lIjoiRXhhbXBsZSBVbml2ZXJzaXR5In19LCJjcmVkZW50aWFsU2NoZW1hIjp7ImlkIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvQ3JlZGVudGlhbDEyMy1zY2hlbWEtY3JlZGVudGlhbCIsInR5cGUiOiJKc29uU2NoZW1hQ3JlZGVudGlhbCJ9LCJjcmVkZW50aWFsU3RhdHVzIjp7ImlkIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvc3RhdHVzbGlzdCMxMjM0NTYiLCJ0eXBlIjoiQml0c3RyaW5nU3RhdHVzTGlzdEVudHJ5Iiwic3RhdHVzUHVycG9zZSI6InJldm9jYXRpb24iLCJzdGF0dXNMaXN0SW5kZXgiOiIxMjM0NTYiLCJzdGF0dXNMaXN0Q3JlZGVudGlhbCI6Imh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL0NyZWRlbnRpYWxTdGF0dXNMaXN0In19 . 9ZD5KBE3jXHTSKdhv_PbkD8kZGUtgbrDHQJf-fwdB6FKyop9y4w1L13a8EyKscb7qHr7116gQ50O6yJQkfn6ZQ application/vc { "@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" } }, "credentialSchema": { "id": "https://university.example/Credential123-schema-credential", "type": "JsonSchemaCredential" }, "credentialStatus": { "id": "https://university.example/statuslist#123456", "type": "BitstringStatusListEntry", "statusPurpose": "revocation", "statusListIndex": "123456", "statusListCredential": "https://university.example/CredentialStatusList" } } application/cbor-diagnostic / cose-sign1 / 18([ / protected / << { / alg / 1 : -35 / ES384 / } >>, / unprotected / { }, / payload / h'7b224063...74227d7d', / signature / h'364b6044...19b44600' ]) application/vc+cose d28444a1013822a059032d7b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a2268747470733a2f2f756e69766572736974792e6578616d706c652f43726564656e7469616c313233222c2274797065223a5b2256657269666961626c6543726564656e7469616c222c224578616d706c65416c756d6e6943726564656e7469616c225d2c22697373756572223a226469643a6578616d706c653a3267353571393132656333343736656261326c393831326563626665222c2276616c696446726f6d223a22323031302d30312d30315430303a30303a30305a222c2263726564656e7469616c5375626a656374223a7b226964223a2268747470733a2f2f7777772e6578616d706c652e6f72672f706572736f6e732f706174222c226e616d65223a22506174222c22616c756d6e694f66223a7b226964223a226469643a6578616d706c653a633237366531326563323165626665623166373132656263366631222c226e616d65223a224578616d706c6520556e6976657273697479227d7d2c2263726564656e7469616c536368656d61223a7b226964223a2268747470733a2f2f756e69766572736974792e6578616d706c652f43726564656e7469616c3132332d736368656d612d63726564656e7469616c222c2274797065223a224a736f6e536368656d6143726564656e7469616c227d2c2263726564656e7469616c537461747573223a7b226964223a2268747470733a2f2f756e69766572736974792e6578616d706c652f7374617475736c69737423313233343536222c2274797065223a22426974737472696e675374617475734c697374456e747279222c22737461747573507572706f7365223a227265766f636174696f6e222c227374617475734c697374496e646578223a22313233343536222c227374617475734c69737443726564656e7469616c223a2268747470733a2f2f756e69766572736974792e6578616d706c652f43726564656e7469616c5374617475734c697374227d7d5840364b6044d6832a1fccb2cb4dc969dcafe1d4ee4fe4741f09395f352c2bad45eb664fa297926853fd69d176a87e61597655bafcf68f5dcaabcd3636b719b44600 Encoded Decoded Issuer Disclosures eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ . eyJfc2RfYWxnIjoic2hhLTI1NiIsIkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy92MiIsImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy9leGFtcGxlcy92MiJdLCJpc3N1ZXIiOiJkaWQ6ZXhhbXBsZToyZzU1cTkxMmVjMzQ3NmViYTJsOTgxMmVjYmZlIiwidmFsaWRGcm9tIjoiMjAxMC0wMS0wMVQwMDowMDowMFoiLCJjcmVkZW50aWFsU3ViamVjdCI6eyJuYW1lIjoiUGF0IiwiYWx1bW5pT2YiOnsibmFtZSI6IkV4YW1wbGUgVW5pdmVyc2l0eSIsIl9zZCI6WyJ2cHdqWkpkT09LR2xCemdqeFp0WVNaVHd6ZmpJeHJBVHc3d01MUFVOZjlVIl19LCJfc2QiOlsiZHhSMEhPUmh4M1Z5X1czcEx3aFBHQVltTkVIUUd0aDlQeE5GbExlbUNRRSJdfSwiY3JlZGVudGlhbFNjaGVtYSI6eyJfc2QiOlsiUFQ5ZFpSbFBCb0l2bXFYSmxqUzJYazlpVEdPaG9xeldmejhZMWNMMmdSQSIsImFNenlwSzJqUTk2aHhhZXlyOXE0VW9RVC1Bel9PM1RCVHhSUTVldkJ0clkiXX0sImNyZWRlbnRpYWxTdGF0dXMiOnsic3RhdHVzUHVycG9zZSI6InJldm9jYXRpb24iLCJzdGF0dXNMaXN0SW5kZXgiOiIxMjM0NTYiLCJzdGF0dXNMaXN0Q3JlZGVudGlhbCI6Imh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL0NyZWRlbnRpYWxTdGF0dXNMaXN0IiwiX3NkIjpbIkFWLUV1RllDdFhpU243bXpnVUVpVE5QdHl1RVBfeVpRUXVSYWVISndpR2siLCJNVlJCVzl1UWZwbGVyU3BrUWxEWUt3Q1U2RjFjaFBnVm9KOERWc1BmQmtFIl19LCJfc2QiOlsiQWVTcGZBVnlqd2dpWnRZbWF0UFVDTnVtV09Za3ZPSWRrbk1sWW9BNkxPdyIsIlVaUEg0dF9lRnZUWG1CX0RidEdOZnRMajdNSzg2SF90X183UTVSTTNwclUiXX0 . I3es_Rr7UZZ6Cg4TicmaMFspnneSAT-jcxgszMdebbefgRXjcRknJM9fASZl--gDsofsUsfCEm9kP0Mqmrtp7g ~ WyJxZXNmanlLN1BpUVc0TzlHd0xoQ2xnIiwgImlkIiwgImh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL0NyZWRlbnRpYWwxMjMiXQ ~ WyJ4UUhObmt4TVNsSnpqNmpVS3N0ME5nIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl1d ~ WyJpNWVpT05ubUZPdFJfZzhrVExCUVhRIiwgImlkIiwgImh0dHBzOi8vd3d3LmV4YW1wbGUub3JnL3BlcnNvbnMvcGF0Il0 ~ WyJQaXJudmpvdzNKNGRlSzUydTUwVHFBIiwgImlkIiwgImRpZDpleGFtcGxlOmMyNzZlMTJlYzIxZWJmZWIxZjcxMmViYzZmMSJd ~ WyJMOEtlSno1WjNFdmVkQ3FQRHNnLS13IiwgImlkIiwgImh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL0NyZWRlbnRpYWwxMjMtc2NoZW1hLWNyZWRlbnRpYWwiXQ ~ WyJOQzR5OERkVGZuNHRkblZlLTlDU3hRIiwgInR5cGUiLCAiSnNvblNjaGVtYUNyZWRlbnRpYWwiXQ ~ WyJ6SGFLcXZPTUVnOU9Yd0RHbm8ydGVBIiwgImlkIiwgImh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL3N0YXR1c2xpc3QjMTIzNDU2Il0 ~ WyJMcU15OENvTEc5QlpCUnBRTF8tTFZRIiwgInR5cGUiLCAiQml0c3RyaW5nU3RhdHVzTGlzdEVudHJ5Il0 ~ { "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro", "alg": "ES256" } { "_sd_alg": "sha-256", "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "issuer": "did:example:2g55q912ec3476eba2l9812ecbfe", "validFrom": "2010-01-01T00:00:00Z", "credentialSubject": { "name": "Pat", "alumniOf": { "name": "Example University", "_sd": [ "vpwjZJdOOKGlBzgjxZtYSZTwzfjIxrATw7wMLPUNf9U" ] }, "_sd": [ "dxR0HORhx3Vy_W3pLwhPGAYmNEHQGth9PxNFlLemCQE" ] }, "credentialSchema": { "_sd": [ "PT9dZRlPBoIvmqXJljS2Xk9iTGOhoqzWfz8Y1cL2gRA", "aMzypK2jQ96hxaeyr9q4UoQT-Az_O3TBTxRQ5evBtrY" ] }, "credentialStatus": { "statusPurpose": "revocation", "statusListIndex": "123456", "statusListCredential": "https://university.example/CredentialStatusList", "_sd": [ "AV-EuFYCtXiSn7mzgUEiTNPtyuEP_yZQQuRaeHJwiGk", "MVRBW9uQfplerSpkQlDYKwCU6F1chPgVoJ8DVsPfBkE" ] }, "_sd": [ "AeSpfAVyjwgiZtYmatPUCNumWOYkvOIdknMlYoA6LOw", "UZPH4t_eFvTXmB_DbtGNftLj7MK86H_t__7Q5RM3prU" ] } Claim: id SHA-256 Hash: UZPH4t_eFvTXmB_DbtGNftLj7MK86H_t__7Q5RM3prU Disclosure(s): WyJxZXNmanlLN1BpUVc0TzlHd0xoQ2xnIiwgImlkIiwgImh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL0NyZWRlbnRpYWwxMjMiXQ Contents: [ "qesfjyK7PiQW4O9GwLhClg", "id", "https://university.example/Credential123" ] Claim: type SHA-256 Hash: AeSpfAVyjwgiZtYmatPUCNumWOYkvOIdknMlYoA6LOw Disclosure(s): WyJ4UUhObmt4TVNsSnpqNmpVS3N0ME5nIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl1d Contents: [ "xQHNnkxMSlJzj6jUKst0Ng", "type", [ "VerifiableCredential", "ExampleAlumniCredential" ] ] Claim: id SHA-256 Hash: dxR0HORhx3Vy_W3pLwhPGAYmNEHQGth9PxNFlLemCQE Disclosure(s): WyJpNWVpT05ubUZPdFJfZzhrVExCUVhRIiwgImlkIiwgImh0dHBzOi8vd3d3LmV4YW1wbGUub3JnL3BlcnNvbnMvcGF0Il0 Contents: [ "i5eiONnmFOtR_g8kTLBQXQ", "id", "https://www.example.org/persons/pat" ] Claim: id SHA-256 Hash: vpwjZJdOOKGlBzgjxZtYSZTwzfjIxrATw7wMLPUNf9U Disclosure(s): WyJQaXJudmpvdzNKNGRlSzUydTUwVHFBIiwgImlkIiwgImRpZDpleGFtcGxlOmMyNzZlMTJlYzIxZWJmZWIxZjcxMmViYzZmMSJd Contents: [ "Pirnvjow3J4deK52u50TqA", "id", "did:example:c276e12ec21ebfeb1f712ebc6f1" ] Claim: id SHA-256 Hash: aMzypK2jQ96hxaeyr9q4UoQT-Az_O3TBTxRQ5evBtrY Disclosure(s): WyJMOEtlSno1WjNFdmVkQ3FQRHNnLS13IiwgImlkIiwgImh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL0NyZWRlbnRpYWwxMjMtc2NoZW1hLWNyZWRlbnRpYWwiXQ Contents: [ "L8KeJz5Z3EvedCqPDsg--w", "id", "https://university.example/Credential123-schema-credential" ] Claim: type SHA-256 Hash: PT9dZRlPBoIvmqXJljS2Xk9iTGOhoqzWfz8Y1cL2gRA Disclosure(s): WyJOQzR5OERkVGZuNHRkblZlLTlDU3hRIiwgInR5cGUiLCAiSnNvblNjaGVtYUNyZWRlbnRpYWwiXQ Contents: [ "NC4y8DdTfn4tdnVe-9CSxQ", "type", "JsonSchemaCredential" ] Claim: id SHA-256 Hash: MVRBW9uQfplerSpkQlDYKwCU6F1chPgVoJ8DVsPfBkE Disclosure(s): WyJ6SGFLcXZPTUVnOU9Yd0RHbm8ydGVBIiwgImlkIiwgImh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL3N0YXR1c2xpc3QjMTIzNDU2Il0 Contents: [ "zHaKqvOMEg9OXwDGno2teA", "id", "https://university.example/statuslist#123456" ] Claim: type SHA-256 Hash: AV-EuFYCtXiSn7mzgUEiTNPtyuEP_yZQQuRaeHJwiGk Disclosure(s): WyJMcU15OENvTEc5QlpCUnBRTF8tTFZRIiwgInR5cGUiLCAiQml0c3RyaW5nU3RhdHVzTGlzdEVudHJ5Il0 Contents: [ "LqMy8CoLG9BZBRpQL_-LVQ", "type", "BitstringStatusListEntry" ] B. Lifecycle Details The previous sections provided an overview of the Verifiable Credential ecosystem. This section provides more details about how the ecosystem is envisaged to operate. Figure 10 Lifecycle of a single Verifiable Credential: the roles and information flows for this specification. The roles and information flows in the Verifiable Credential ecosystem are as follows: An issuer issues a Verifiable Credential to a holder. Issuance always occurs before any other actions involving a Credential. A holder might transfer one or more of its Verifiable Credentials to another holder. A holder presents one or more of its Verifiable Credentials to a verifier, optionally inside a Verifiable Presentation. A verifier verifies the authenticity of the presented Verifiable Presentation and Verifiable Credentials and checks any credential status (if present) of the Verifiable Credentials. After verification, a verifier validates the relevant claims in presented Verifiable Credentials, using their own business logic to evaluate which issuers are appropriate for which claims and which subjects are appropriate for the requested use. An issuer might revoke a Verifiable Credential. A holder might delete a Verifiable Credential. Note The order of the actions above is not fixed, and some actions might be taken more than once. Such action-recurrence might be immediate or at any later point. The most common sequence of actions is envisioned to be: An issuer issues a verifiable credential to a holder. The holder presents the verifiable credential to a verifier. The verifier verifies the verifiable credential. The verifier validates claims made in the verifiable credential against the verifier's business rules. The verifier applies valid claims. These specifications do not define any protocol for transferring Verifiable Credentials or Verifiable Presentations, but assuming other specifications do specify how they are transferred between entities, then the Verifiable Credential Data Model is directly applicable. These specifications neither define an authorization framework nor does it restrict the business decisions that a verifier might make after verifying a Verifiable Credential or Verifiable presentation. Rather, verifiers apply their own business rules before treating any claim as valid, taking into account the holder, the issuer of the Verifiable Credential, the claims of the Verifiable Credential, and the verifier's own policies. In particular, sections Terms of Use in the Data Model specification, and the Subject-Holder Relationships section in the Verifiable Credentials Implementation Guide [ VC-IMP-GUIDE ] specify how a verifier can determine: Whether the holder is a subject of a Verifiable Credential. The relationship between the subject and the holder. Whether the original holder passed a Verifiable Credential to a subsequent holder. Any restrictions using the Verifiable Credentials by the holder or verifier. C. References C.1 Informative references [CFRG-BBS-SIGNATURE] The BBS Signature Scheme . Tobias Looker; Vasilis Kalos; Andrew Whitehead; Mike Lodder. IETF. I-D. URL: https://www.ietf.org/archive/id/draft-irtf-cfrg-bbs-signatures-05.html [CID-1.0] Controlled Identifiers v1.0 . Michael Jones; Manu Sporny. W3C. 15 May 2025. W3C Recommendation. URL: https://www.w3.org/TR/cid-1.0/ [DID-CORE] Decentralized Identifiers (DIDs) v1.0 . Manu Sporny; Amy Guy; Markus Sabadello; Drummond Reed. W3C. 19 July 2022. W3C Recommendation. URL: https://www.w3.org/TR/did-core/ [FIPS-186-5] FIPS PUB 186-5: Digital Signature Standard (DSS) . U.S. Department of Commerce/National Institute of Standards and Technology. 3 February 2023. National Standard. URL: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf [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/ [JSON-SCHEMA] JSON Schema: A Media Type for Describing JSON Documents . Austin Wright; Henry Andrews; Ben Hutton; Greg Dennis. Internet Engineering Task Force (IETF). 10 June 2022. Internet-Draft. URL: https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema [RDF-CANON] RDF Dataset Canonicalization . Gregg Kellogg; Dave Longley; Dan Yamamoto. W3C. 21 May 2024. W3C Recommendation. URL: https://www.w3.org/TR/rdf-canon/ [RDF11-CONCEPTS] RDF 1.1 Concepts and Abstract Syntax . Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/ [RFC1952] GZIP file format specification version 4.3 . P. Deutsch. IETF. May 1996. Informational. URL: https://www.rfc-editor.org/info/rfc1952/ [RFC6901] JavaScript Object Notation (JSON) Pointer . P. Bryan, Ed.; K. Zyp; M. Nottingham, Ed. IETF. April 2013. Proposed Standard. URL: https://www.rfc-editor.org/info/rfc6901/ [RFC7515] JSON Web Signature (JWS) . M. Jones; J. Bradley; N. Sakimura. IETF. May 2015. Proposed Standard. URL: https://www.rfc-editor.org/info/rfc7515/ [RFC7517] JSON Web Key (JWK) . M. Jones. IETF. May 2015. Proposed Standard. URL: https://www.rfc-editor.org/info/rfc7517/ [RFC7519] JSON Web Token (JWT) . M. Jones; J. Bradley; N. Sakimura. IETF. May 2015. Proposed Standard. URL: https://www.rfc-editor.org/info/rfc7519/ [RFC8032] Edwards-Curve Digital Signature Algorithm (EdDSA) . S. Josefsson; I. Liusvaara. IETF. January 2017. Informational. URL: https://www.rfc-editor.org/info/rfc8032/ [RFC8785] JSON Canonicalization Scheme (JCS) . A. Rundgren; B. Jordan; S. Erdtman. IETF. June 2020. Informational. URL: https://www.rfc-editor.org/info/rfc8785/ [RFC8949] Concise Binary Object Representation (CBOR) . C. Bormann; P. Hoffman. IETF. December 2020. Internet Standard. URL: https://www.rfc-editor.org/info/rfc8949/ [RFC9052] CBOR Object Signing and Encryption (COSE): Structures and Process . J. Schaad. IETF. August 2022. Internet Standard. URL: https://www.rfc-editor.org/info/rfc9052/ [RFC9563] SM2 Digital Signature Algorithm for DNSSEC . C. Zhang; Y. Liu; F. Leng; Q. Zhao; Z. He. IETF. December 2024. Informational. URL: https://www.rfc-editor.org/info/rfc9563/ [rfc9901] Selective Disclosure for JSON Web Tokens . D. Fett; K. Yasuda; B. Campbell. IETF. November 2025. Proposed Standard. URL: https://www.rfc-editor.org/info/rfc9901/ [URL] URL Standard . Anne van Kesteren. WHATWG. Living Standard. URL: https://url.spec.whatwg.org/ [VC-BITSTRING-STATUS-LIST] Bitstring Status List v1.0 . Manu Sporny; Dave Longley; Mahmoud Alkhraishi; Michael Prorock. W3C. 15 May 2025. W3C Recommendation. URL: https://www.w3.org/TR/vc-bitstring-status-list/ [VC-DATA-INTEGRITY] Verifiable Credential Data Integrity 1.0 . Ivan Herman; Manu Sporny; Ted Thibodeau Jr; Dave Longley; Greg Bernstein. W3C. 15 May 2025. W3C Recommendation. URL: https://www.w3.org/TR/vc-data-integrity/ [VC-DATA-MODEL-2.0] Verifiable Credentials Data Model v2.0 . Ivan Herman; Michael Jones; Manu Sporny; Ted Thibodeau Jr; Gabe Cohen. W3C. 15 May 2025. W3C Recommendation. URL: https://www.w3.org/TR/vc-data-model-2.0/ [VC-DI-BBS] Data Integrity BBS Cryptosuites v1.0 . Greg Bernstein; Manu Sporny. W3C. 7 April 2026. CRD. URL: https://www.w3.org/TR/vc-di-bbs/ [VC-DI-ECDSA] Data Integrity ECDSA Cryptosuites v1.0 . Manu Sporny; Dave Longley; Greg Bernstein. W3C. 15 May 2025. W3C Recommendation. URL: https://www.w3.org/TR/vc-di-ecdsa/ [VC-DI-EDDSA] Data Integrity EdDSA Cryptosuites v1.0 . Manu Sporny; Ted Thibodeau Jr; Greg Bernstein. W3C. 15 May 2025. W3C Recommendation. URL: https://www.w3.org/TR/vc-di-eddsa/ [VC-IMP-GUIDE] Verifiable Credentials Implementation Guidelines 1.0 . Andrei Sambra. W3C. 24 September 2019. W3C Working Group Note. URL: https://www.w3.org/TR/vc-imp-guide/ [VC-JOSE-COSE] Securing Verifiable Credentials using JOSE and COSE . Michael Jones; Gabe Cohen; Michael Prorock. W3C. 15 May 2025. W3C Recommendation. URL: https://www.w3.org/TR/vc-jose-cose/ [VC-JSON-SCHEMA] Verifiable Credentials JSON Schema Specification . Gabe Cohen; Michael Prorock; Mahmoud Alkhraishi. W3C. 4 February 2025. CRD. URL: https://www.w3.org/TR/vc-json-schema/ ↑