vc data model 2.1

Verifiable Credentials Data Model v2.1 Verifiable Credentials Data Model v2.1 W3C Working Draft 05 September 2026 More details about this document This version: https://www.w3.org/TR/2026/WD-vc-data-model-2.1-20260905/ Latest published version: https://www.w3.org/TR/vc-data-model-2.1/ Latest editor's draft: https://w3c.github.io/vc-data-model/ History: https://www.w3.org/standards/history/vc-data-model-2.1/ Commit history Editors: Manu Sporny ( Digital Bazaar ) (v1.0 - v2.1) Ted Thibodeau Jr ( OpenLink Software ) (v2.0 - v2.1) Ivan Herman ( W3C ) (v2.0 - v2.1) Former editors: Grant Noble ( ConsenSys ) (v1.0) Dave Longley ( Digital Bazaar ) (v1.0) Daniel C. Burnett ( ConsenSys ) (v1.0) Brent Zundel ( Evernym ) (v1.0) Kyle Den Hartog ( MATTR ) (v1.1) Gabe Cohen ( Block ) (v2.0) Michael B. Jones ( Invited Expert ) (v2.0) Authors: Manu Sporny ( Digital Bazaar ) (v1.0 - v2.1) Dave Longley ( Digital Bazaar ) (v1.0 - v2.1) David Chadwick ( Invited Expert ) (v1.0 - v2.0) Ivan Herman ( W3C ) (v2.0 - v2.1) Feedback: GitHub w3c/vc-data-model ( pull requests , new issue , open issues ) Related Specifications: Verifiable Credentials Overview Verifiable Credential Data Integrity Securing Verifiable Credentials using JOSE and COSE Bitstring Status List Verifiable Credential Rendering Methods Verifiable Credential Confidence Methods Recognized Entities Meetings: View next scheduled meeting Copyright © 2026 World Wide Web Consortium . W3C ® liability , trademark and permissive document license rules apply. Abstract A verifiable credential is a specific way to express a set of claims made by an issuer , such as a driver's license or an education certificate. This specification describes the extensible data model for verifiable credentials , how they can be secured from tampering, and a three-party ecosystem for the exchange of these credentials that is composed of issuers , holders , and verifiers . This document also covers a variety of security, privacy, internationalization, and accessibility considerations for ecosystems that use the technologies described in this specification. 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 . Comments regarding this specification are welcome at any time. Please file issues directly on GitHub , or send them to [email protected] if that is not possible. ( subscribe , archives ). This document was published by the Verifiable Credentials Working Group as a Working Draft using the Recommendation track . Publication as a Working Draft does not imply endorsement by W3C and its Members. This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as other than a work in progress. This document was produced by a group operating under the W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent that the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy . This document is governed by the 18 August 2025 W3C Process Document . Table of Contents Abstract Status of This Document 1. Introduction 1.1 What is a Verifiable Credential? 1.2 Ecosystem Overview 1.3 Conformance 2. Terminology 3. Core Data Model 3.1 Claims 3.2 Credentials 3.3 Presentations 4. Basic Concepts 4.1 Getting Started 4.2 Verifiable Credentials 4.3 Contexts 4.4 Identifiers 4.5 Types 4.6 Names and Descriptions 4.7 Issuer 4.8 Credential Subject 4.9 Validity Period 4.10 Status 4.11 Data Schemas 4.12 Securing Mechanisms 4.13 Verifiable Presentations 5. Advanced Concepts 5.1 Trust Model 5.2 Extensibility 5.3 Integrity of Related Resources 5.4 Refreshing 5.5 Terms of Use 5.6 Evidence 5.7 Zero-Knowledge Proofs 5.8 Representing Time 5.9 Authorization 5.10 Reserved Extension Points 5.11 Ecosystem Compatibility 5.12 Verifiable Credential Graphs 5.13 Securing Mechanism Specifications 6. Syntaxes 6.1 JSON-LD 6.2 Media Types 6.3 Type-Specific Credential Processing 7. Algorithms 7.1 Verification 7.2 Problem Details 8. Accessibility Considerations 8.1 Data First Approaches 9. Internationalization Considerations 9.1 Language and Base Direction 9.2 Providing Default Language and Direction A. Threat Model A.1 Target Threats A.2 Implementation Threats A.3 Deployment Threats A.4 External Threats A.5 Dependency Threats B. Validation B.1 Credential Type B.2 Credential Subject B.3 Issuer B.4 Holder B.5 Issuance Date B.6 Proofs (Signatures) B.7 Validity Periods B.8 Status B.9 Schema B.10 Fitness for Purpose B.11 "Artificial Intelligence" and "Machine Learning" C. Contexts, Vocabularies, Types, and Credential Schemas C.1 Base Context C.2 Vocabularies C.3 Datatypes C.3.1 The sriString Datatype C.4 Differences between Contexts, Types, and CredentialSchemas D. IANA Considerations D.1 application/vc D.2 application/vp E. Additional Diagrams for Verifiable Presentations F. Revision History G. Acknowledgements H. References H.1 Normative references H.2 Informative references 1. Introduction This section is non-normative. Credentials are integral to our daily lives: driver's licenses confirm our capability to operate motor vehicles; university degrees assert our level of education; and government-issued passports attest to our citizenship when traveling between countries. This specification provides a mechanism for expressing these sorts of credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine verifiable. These credentials provide benefits to us when used in the physical world, but their use on the Web continues to be elusive. It is currently difficult to express educational qualifications, healthcare data, financial account details, and other third-party- verified personal information in a machine readable way on the Web. The challenge of expressing digital credentials on the Web hinders our ability to receive the same benefits from them that physical credentials provide in the real world. For those unfamiliar with the concepts related to verifiable credentials , the following sections provide an overview of: The components that constitute a verifiable credential The components that constitute a verifiable presentation An ecosystem where verifiable credentials and verifiable presentations are useful The use cases and requirements that informed this specification can be found in Verifiable Credentials Use Cases [ VC-USE-CASES ]. 1.1 What is a Verifiable Credential? This section is non-normative. In the physical world, a credential might consist of: Information related to identifying the subject of the credential (for example, a photo, name, or identification number) Information related to the issuing authority (for example, a city government, national agency, or certification body) Information related to the type of credential (for example, a Dutch passport, an American driving license, or a health insurance card) Information related to specific properties asserted by the issuing authority about the subject (for example, nationality, date of birth, or the classes of vehicle they're qualified to drive) Evidence by which a subject was demonstrated to have satisfied the qualifications required for issuance of the credential (for example, a measurement, proof of citizenship, or test result) Information related to constraints on the credential (for example, validity period, or terms of use). A verifiable credential is a digital expression of information (i.e., a credential , which is a collection of one or more claims made by an issuer ) that can be made portably tamper-evident with verifiable authenticity of authorship by using one of the securing mechanisms described in Section 4.12 Securing Mechanisms . Any information that a physical credential can represent can also be represented by a digital credential , and so by a verifiable credential . Using technologies such as digital signatures can make verifiable credentials more tamper-evident and trustworthy than their physical counterparts. With the use of Verifiable Credential Barcodes v1.0 , physical credentials can even include verifiable credentials , achieving these same benefits. Holders of verifiable credentials can generate verifiable presentations and then share these verifiable presentations with verifiers to prove they possess verifiable credentials with specific characteristics. Both verifiable credentials and verifiable presentations can be transmitted rapidly, making them more convenient than their physical counterparts when establishing trust at a distance. While this specification attempts to improve the ease of expressing digital credentials , it also aims to balance this goal with several privacy-preserving goals. The persistence of digital information, and the ease with which disparate sources of digital data can be collected and correlated, comprise a privacy concern that the use of verifiable and easily machine-readable credentials threatens to make worse. Additionally, while the security measures used by physical credentials (such as holograms or watermarks) are at least familiar to many people, the cryptographic mechanisms that secure digital credentials can be difficult for non-experts to understand or evaluate. This document outlines several of these issues in Privacy Considerations , and the Verifiable Credentials Data Model Threat Model analyzes them in detail and describes responses to each of them. Examples of how to use this data model using privacy-enhancing technologies, such as zero-knowledge proofs, are also provided throughout this document. The word "verifiable" in the terms verifiable credential and verifiable presentation refers to the characteristic of a credential or presentation as being able to be verified by a verifier , as defined in this document. Verification establishes only that a verifiable credential or verifiable presentation is an authentic and current statement of its issuer or presenter; it does not imply that the claims encoded inside it are true. Before relying on those claims , a verifier separately performs validation : determining, according to its own policies, whether the issuer is trusted to make those claims and whether the claims are acceptable for the verifier's purpose. This process is described further in Appendix B. Validation . 1.2 Ecosystem Overview This section is non-normative. This section describes the roles of the core actors and the relationships between them in an ecosystem where one expects verifiable credentials to be useful. A role is an abstraction that might be implemented in many different ways. The separation of roles suggests likely interfaces and protocols for standardization. This specification introduces the following roles: holder A role an entity might perform by possessing one or more verifiable credentials and generating verifiable presentations from them. A holder is often, but not always, a subject of the verifiable credentials they are holding. For example, the holder of a passport is usually the person the passport identifies. Holders store their credentials in credential repositories . Example holders include students, employees, and customers. issuer A role an entity can perform by asserting claims about one or more subjects , creating a verifiable credential from these claims , and transmitting the verifiable credential to a holder . For example, issuers include corporations, non-profit organizations, trade associations, governments, and individuals. subject A thing about which claims are made. Example subjects include human beings, animals, and things. verifier A role an entity performs by receiving one or more verifiable credentials , optionally inside a verifiable presentation , and performing verification on them. Verification establishes the authenticity and currency of the credential or presentation . Determining whether the claims inside are true or acceptable is a separate process, called validation , that a verifier performs according to its own policies (see Appendix B. Validation ). Example verifiers include an employer checking an applicant's educational credentials, security personnel checking a government-issued identification credential, and a website checking that a visitor holds a membership credential issued by a particular organization. verifiable data registry A role a system, such as a database or distributed ledger, might perform by mediating the creation and verification of identifiers, verification material , and other relevant data, such as verifiable credential schemas and revocation registries. Some configurations might require correlatable identifiers for subjects . Some registries, such as ones for UUIDs and verification material , might just act as namespaces for identifiers. Examples of verifiable data registries include trusted databases, decentralized databases, government ID databases, and distributed ledgers. Often, more than one type of verifiable data registry is used in an ecosystem. Figure 1 The roles and information flows forming the basis for this specification. As shown in Figure 1 , any of the roles can use a verifiable data registry to verify identifiers. For example, an issuer might verify that an identifier belongs to a particular entity by retrieving the verification material associated with the identifier from the registry and then challenging the entity to prove possession of the corresponding private cryptographic key. Note : Other types of ecosystems exist Figure 1 above provides an example ecosystem to ground the rest of the concepts in this specification. Other ecosystems exist, such as protected environments or proprietary systems, where verifiable credentials also provide benefits. This ecosystem contrasts with the typical two-party or federated identity provider models. An identity provider, sometimes abbreviated as IdP , is a system for creating, maintaining, and managing identity information for holders while providing authentication services to relying party applications within a federation or distributed network. In a federated identity model, a holder's identity is tightly bound to the identity provider (but do note that a holder might have any number of identities, each with their own associated identifier and identity provider; these might be appropriate to support privacy, business vs. personal, and other concerns):

each time a relying party needs information about an identified holder , it obtains that information directly from the identity provider, which therefore participates in, and learns about, every such transaction. In contrast, this specification describes a three-party model that decouples the identity provider concept into two distinct concepts: the issuer and the holder . The issuer provides verifiable credentials to the holder in one interaction, and the holder later presents them to verifiers in separate interactions in which the issuer does not participate and of which the issuer need not even be aware. This specification avoids using "identity provider," "federated identity," or "relying party" terminology, except when comparing or mapping these concepts to other specifications. Note : Subjects are not always Holders In many cases, the holder of a verifiable credential is the subject, but in some instances it is not. For example, a parent (the holder ) might hold the verifiable credentials of a child (the subject ), or a pet owner (the holder ) might hold the verifiable credentials of their pet (the subject ). For more information about these exceptional cases, see the Subject-Holder Relationships section in the Verifiable Credentials Implementation Guidelines 1.0 . For a deeper exploration of the verifiable credentials ecosystem and a concrete lifecycle example, please refer to Verifiable Credentials Overview v1.0 [ VC-OVERVIEW ]. 1.3 Conformance As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative. The key words MAY , MUST , MUST NOT , OPTIONAL , RECOMMENDED , REQUIRED , SHOULD , and SHOULD NOT in this document are to be interpreted as described in BCP 14 [ RFC2119 ] [ RFC8174 ] when, and only when, they appear in all capitals, as shown here. A conforming document is a compacted JSON-LD document that complies with all of the relevant " MUST " statements in this specification. Specifically, the relevant normative " MUST " statements in Sections 4. Basic Concepts , 5. Advanced Concepts , and 6. Syntaxes of this document MUST be enforced. A conforming document MUST be either a verifiable credential with a media type of application/vc or a verifiable presentation with a media type of application/vp . A conforming document MUST be secured by at least one securing mechanism as described in Section 4.12 Securing Mechanisms . A conforming issuer implementation produces conforming documents , MUST include all required properties in the conforming documents it produces, and MUST secure the conforming documents it produces using a securing mechanism described in Section 4.12 Securing Mechanisms . A conforming verifier implementation consumes conforming documents , MUST perform verification on a conforming document as described in Section 4.12 Securing Mechanisms , MUST check that each required property satisfies the normative requirements for that property, and MUST produce errors when non- conforming documents are detected. This specification includes both required and optional properties. Optional properties MAY be ignored by conforming issuer implementations and conforming verifier implementations . This document also contains examples that contain characters that are invalid JSON, such as inline comments ( // ) and the use of ellipsis ( ... ) to denote information that adds little value to the example. Implementers are cautioned to remove this content if they desire to use the information as a valid document. Note : Human-readable texts in English are illustrative Examples provided throughout this document include descriptive properties, such as name and description , with values in English to simplify the concepts in each example of the specification. These examples do not necessarily reflect the data structures needed for international use, described in more detail in Section 9. Internationalization Considerations . 2. Terminology The following terms are used to describe concepts in this specification. claim An assertion made about a subject . credential A set of one or more claims made by an issuer . The claims in a credential can be about different subjects . The definition of credential used in this specification differs from, NIST's definitions of credential . decentralized identifier A portable URL-based identifier, also known as a DID , is associated with an entity . These identifiers are most often used in a verifiable credential and are associated with subjects such that a verifiable credential can be easily ported from one credential repository to another without reissuing the credential . An example of a DID is did:example:123456abcdef . See the Decentralized Identifiers (DIDs) v1.0 specification for further details. default graph The graph containing all claims that are not explicitly part of a named graph . entity Anything that can be referenced in statements as an abstract or concrete noun. Entities include but are not limited to people, organizations, physical things, documents, abstract concepts, fictional characters, and arbitrary text. Any entity might perform roles in the ecosystem, if it can do so. Note that some entities fundamentally cannot take actions, for example, the string "abc" cannot issue credentials. graph A set of claims, forming a network of information composed of subjects and their relationship to other subjects or data. Each claim is part of a graph; either explicit in the case of named graphs , or implicit for the default graph . holder A role an entity might perform by possessing one or more verifiable credentials and generating verifiable presentations from them. A holder is often, but not always, a subject of the verifiable credentials they are holding. Holders store their credentials in credential repositories . issuer A role an entity can perform by asserting claims about one or more subjects , creating a verifiable credential from these claims , and transmitting the verifiable credential to a holder . named graph A graph associated with specific properties, such as verifiableCredential . These properties result in separate graphs that contain all claims defined in the corresponding JSON objects. presentation Data derived from one or more verifiable credentials issued by one or more issuers that is shared with a specific verifier . credential repository Software, such as a file system, storage vault, or personal verifiable credential wallet, that stores and protects access to holders' verifiable credentials . selective disclosure The ability of a holder to make fine-grained decisions about what information to share. unlinkable disclosure A type of selective disclosure where presentations cannot be correlated between verifiers . subject A thing about which claims are made. validation The assurance that a claim from a specific issuer satisfies the business requirements of a verifier for a particular use. This specification defines how verifiers verify verifiable credentials and verifiable presentations . It also specifies that verifiers validate claims in verifiable credentials before relying on them. However, the means for such validation vary widely and are outside the scope of this specification. Verifiers trust certain issuers for certain claims and apply their own rules to determine which claims in which credentials are suitable for use by their systems. verifiable credential A tamper-evident credential whose authorship can be cryptographically verified. Verifiable credentials can be used to build verifiable presentations , which can also be cryptographically verifiable. verifiable data registry A role a system, such as a database or distributed ledger, might perform by mediating the creation and verification of identifiers, verification material , and other relevant data, such as verifiable credential schemas and revocation registries. Some configurations might require correlatable identifiers for subjects . Some registries, such as ones for UUIDs and verification material , might act as namespaces for identifiers. verifiable presentation A tamper-evident presentation of information encoded in such a way that authorship of the data can be trusted after a process of cryptographic verification. Certain types of verifiable presentations might contain data that is synthesized from, but does not contain, the original verifiable credentials (for example, zero-knowledge proofs). verification The evaluation of whether a verifiable credential or verifiable presentation is an authentic and current statement of the issuer or presenter, respectively. This includes checking that the credential or presentation conforms to the specification, the securing mechanism is satisfied, and, if present, the status check succeeds. Verification of a credential does not imply evaluation of the truth of claims encoded in the credential. verifier A role an entity performs by receiving one or more verifiable credentials , optionally inside a verifiable presentation for processing. Other specifications might refer to this concept as a relying party . verification material Information that is used to verify the security of cryptographically protected information. For example, a cryptographic public key is used to verify a digital signature associated with a verifiable credential . URL A Uniform Resource Locator, as defined by the URL Standard . Some URLs can be dereferenced to result in a resource, such as a document. The rules for dereferencing, or fetching, a URL are defined by the URL scheme . This specification does not use the term URI or IRI because those terms have been deemed to be confusing to Web developers. 3. Core Data Model This section is non-normative. The following sections outline core data model concepts, such as claims , credentials , presentations , verifiable credentials , and verifiable presentations , which form the foundation of this specification. Note : The difference between a credential and a verifiable credential Readers might note that some concepts described in this section, such as credentials and presentations , do not have media types defined by this specification. However, the concepts of a verifiable credential or a verifiable presentation are defined as conforming documents and have associated media types. The concrete difference between these concepts — between credential and presentation vs. verifiable credential and verifiable presentation — is simply the fact that the "verifiable" objects are secured in a cryptographic way, and the others are not. For more details, see Section 4.12 Securing Mechanisms . 3.1 Claims This section is non-normative. A claim is a statement about a subject . A subject is a thing about which claims can be made. Claims are expressed using subject - property - value relationships. Figure 2 The basic structure of a claim. The data model for claims , illustrated in Figure 2 above, is powerful and can be used to express a large variety of statements. For example, whether someone graduated from a particular university can be expressed as shown in Figure 3 below. Figure 3 A basic claim expressing that Pat is an alum of "Example University". Individual claims can be merged together to express a graph of information about a subject . The example shown in Figure 4 below extends the previous claim by adding the claims that Pat knows Sam and that Sam is employed as a professor. Figure 4 Multiple claims can be combined to express a graph of information. To this point, the concepts of a claim and a graph of information are introduced. More information is expected to be added to the graph to inform decisions on whether to trust claims . 3.2 Credentials This section is non-normative. 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 the issuer , the validity date and time period, a representative image, verification material , status information, and so on. A verifiable credential is a set of tamper-evident claims and metadata that cryptographically prove who issued it. Examples of verifiable credentials include, but are not limited to, digital employee identification cards, digital driver's licenses, and digital educational certificates. Figure 5 Basic components of a verifiable credential. Figure 5 above shows the basic components of a verifiable credential , but abstracts the details about how claims are organized into information graphs , which are then organized into verifiable credentials . Figure 6 below shows a more complete depiction of a verifiable credential using an embedded proof based on Verifiable Credential Data Integrity 1.0 . It is composed of at least two information graphs . The first of these information graphs , the verifiable credential graph (the default graph ), expresses the verifiable credential itself through credential metadata and other claims . The second information graph , referred to by the proof property, is the proof graph of the verifiable credential and is a separate named graph . The proof graph expresses the digital proof, which, in this case, is a digital signature. Readers who are interested in the need for multiple information graphs can refer to Section 5.12 Verifiable Credential Graphs . Figure 6 Information graphs associated with a basic verifiable credential, using an embedded proof based on Verifiable Credential Data Integrity 1.0 [ VC-DATA-INTEGRITY ]. Figure 7 below shows the same verifiable credential as Figure 6 , but secured using JOSE [ VC-JOSE-COSE ]. The payload contains a single information graph, which is the verifiable credential graph containing credential metadata and other claims . Figure 7 Information graphs associated with a basic verifiable credential, using an enveloping proof based on Securing Verifiable Credentials using JOSE and COSE [ VC-JOSE-COSE ]. 3.3 Presentations This section is non-normative. Enhancing privacy is a key design feature of this specification. Therefore, it is crucial for entities using this technology to express only the portions of their personas that are appropriate for given situations. The expression of a subset of one's persona is called a verifiable presentation . Examples of different personas include a person's professional persona, online gaming persona, family persona, or incognito persona. A verifiable presentation is created by a holder , can express data from multiple verifiable credentials , and can contain arbitrary additional data. They are used to present claims to a verifier . It is also possible to present verifiable credentials directly. The data in a presentation is often about the same subject but might have been issued by multiple issuers . The aggregation of this information expresses an aspect of a person, organization, or entity . Figure 8 Basic components of a verifiable presentation. Figure 8 above shows the components of a verifiable presentation but abstracts the details about how verifiable credentials are organized into information graphs , which are then organized into verifiable presentations . Figure 9 below shows a more complete depiction of a verifiable presentation using an embedded proof based on Verifiable Credential Data Integrity 1.0 . It is composed of at least four information graphs . The first of these information graphs , the verifiable presentation graph (the default graph ), expresses the verifiable presentation itself through presentation metadata. The verifiable presentation refers, via the verifiableCredential property, to a verifiable credential . This credential is a self-contained verifiable credential graph containing credential metadata and other claims . This credential refers to a verifiable credential proof graph via a proof property, expressing the proof (usually a digital signature) of the credential . This verifiable credential graph and its linked proof graph constitute the second and third information graphs , respectively, and each is a separate named graph . The presentation also refers, via the proof property, to the presentation 's proof graph , the fourth information graph (another named graph ). This presentation proof graph represents the digital signature of the verifiable presentation graph , the verifiable credential graph , and the proof graph linked from the verifiable credential graph . Figure 9 Information graphs associated with a basic verifiable presentation that uses an embedded proof based on Verifiable Credential Data Integrity 1.0 . Figure 10 below shows the same verifiable presentation as Figure 9 , but using an enveloping proof based on [ VC-JOSE-COSE ]. The payload contains only two information graphs: the verifiable presentation graph expressing the verifiable presentation through presentation metadata and the corresponding verifiable credential graph , referred to by the verifiableCredential property. The verifiable credential graph contains a single EnvelopedVerifiableCredential instance referring, via a data: URL [ RFC2397 ], to the verifiable credential secured via an enveloping proof shown in Figure 7 . Figure 10 Information graphs associated with a basic verifiable presentation that is using an enveloping proof based on Securing Verifiable Credentials using JOSE and COSE . The data: URL refers to the verifiable credential shown in Figure 7 . Note : Presentations can contain multiple verifiable credentials It is possible to have a presentation , such as a collection of university credentials, which draws on multiple credentials about different subjects that are often, but not required to be, related. This is achieved by using the verifiableCredential property to refer to multiple verifiable credentials . See Appendix E. Additional Diagrams for Verifiable Presentations for more details. Note : Presentations can be presented by issuers and verifiers As described in Section 1.2 Ecosystem Overview , an entity can take on one or more roles as they enter a particular credential exchange. While a holder is typically expected to generate presentations , an issuer or verifier might generate a presentation to identify itself to a holder . This might occur if the holder needs higher assurance from the issuer or verifier before handing over sensitive information as part of a verifiable presentation . 4. Basic Concepts This section introduces some basic concepts for the specification in preparation for Section 5. Advanced Concepts later in the document. 4.1 Getting Started This section is non-normative. This specification is designed to ease the prototyping of new types of verifiable credentials . Developers can copy the template below and paste it into common verifiable credential tooling to start issuing, holding, and verifying prototype credentials. A developer will change MyPrototypeCredential below to the type of credential they would like to create. Since verifiable credentials talk about subjects, each property-value pair in the credentialSubject object expresses a particular property of the credential subject. Once a developer has added a number of these property-value combinations, the modified object can be sent to a conforming issuer implementation , and a verifiable credential will be created for the developer. From a prototyping standpoint, that is all a developer needs to do. Example 1 : A template for creating prototype verifiable credentials { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "type": ["VerifiableCredential", "MyPrototypeCredential"], "credentialSubject": { "mySubjectProperty": "mySubjectValue" } } After stabilizing all credential properties, developers are advised to generate and publish vocabulary and context files at stable URLs to facilitate interoperability with other developers. The https://www.w3.org/ns/credentials/examples/v2 URL above would then be replaced with the URL of a use-case-specific context. This process is covered in Section 5.2 Extensibility . Alternatively, developers can reuse existing vocabulary and context files that happen to fit their use case. They can explore the Verifiable Credential Extensions for reusable resources. 4.2 Verifiable Credentials Verifiable credentials are used to express properties of one or more subjects as well as properties of the credential itself. The following properties are defined in this specification for a verifiable credential : @context Defined in Section 4.3 Contexts . id Defined in Section 4.4 Identifiers . type Defined in Section 4.5 Types . name Defined in Section 4.6 Names and Descriptions . description Defined in Section 4.6 Names and Descriptions . issuer Defined in Section 4.7 Issuer . credentialSubject Defined in Section 4.8 Credential Subject . validFrom Defined in Section 4.9 Validity Period . validUntil Defined in Section 4.9 Validity Period . status Defined in Section 4.10 Status . credentialSchema Defined in Section 4.11 Data Schemas . refreshService Defined in Section 5.4 Refreshing . termsOfUse Defined in Section 5.5 Terms of Use . evidence Defined in Section 5.6 Evidence . A verifiable credential can be extended to have additional properties through the extension mechanism defined in Section 5.2 Extensibility . 4.3 Contexts When two software systems need to exchange data, they need to use terminology that both systems understand. Consider how two people communicate effectively by using the same language, where the words they use, such as "name" and "website," mean the same thing to each individual. This is sometimes referred to as the context of a conversation . This specification uses a similar concept to achieve similar results for software systems by establishing a context in which to communicate. Software systems that process verifiable credentials and verifiable presentations identify terminology by using URLs for each term. However, those URLs can be long and not very human-friendly, while short-form, human-friendly aliases can be more helpful. This specification uses the @context property to map short-form aliases to the URLs . Verifiable credentials and verifiable presentations MUST include a @context property . Application developers MUST understand every JSON-LD context used by their application, at least to the extent that it affects the meaning of the terms used by their application. One mechanism for doing so is described in the Section on Validating Contexts in the Verifiable Credential Data Integrity 1.0 specification. Other specifications that build upon this specification MAY require that JSON-LD contexts be integrity protected by using the relatedResource feature described in Section 5.3 Integrity of Related Resources or any effectively equivalent mechanism. @context The value of the @context property MUST be an ordered set where the first item is a URL with the value https://www.w3.org/ns/credentials/v2 . Subsequent items in the ordered set MUST be composed of any combination of URLs and objects, where each is processable as a JSON-LD Context . Example 2 : Use of the @context property { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ] , "id": "http://university.example/credentials/58473", "type": ["VerifiableCredential", "ExampleAlumniCredential"], "issuer": "did:example:2g55q912ec3476eba2l9812ecbfe", "validFrom": "2010-01-01T00:00:00Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "alumniOf": { "id": "did:example:c276e12ec21ebfeb1f712ebc6f1", "name": "Example University" } } } The example above uses the base context URL ( https://www.w3.org/ns/credentials/v2 ) to establish that the data exchange is about a verifiable credential . This concept is further detailed in Section 5.2 Extensibility . The data available at https://www.w3.org/ns/credentials/v2 is a permanently cacheable static document with instructions for processing it provided in Appendix C.1 Base Context . The associated human-readable vocabulary document for the Verifiable Credentials Data Model is available at https://www.w3.org/2018/credentials/ . The second URL ( https://www.w3.org/ns/credentials/examples/v2 ) is used to demonstrate examples. Implementations are expected to not use this URL for any other purpose, such as in pilot or production systems. Note : See JSON-LD for more information about @context. The @context property is further elaborated upon in Section 3.1: The Context of the JSON-LD 1.1 specification. 4.4 Identifiers When expressing statements about a specific thing, such as a person, product, or organization, using a globally unique identifier for that thing can be useful. Globally unique identifiers enable others to express statements about the same thing. This specification defines the optional id property for such identifiers. The id property allows for expressing statements about specific things in the verifiable credential and is set by an issuer when expressing objects in a verifiable credential or a holder when expressing objects in a verifiable presentation . The id property expresses an identifier that others are expected to use when expressing statements about the specific thing identified by that identifier. Example id values include UUIDs ( urn:uuid:0c07c1ce-57cb-41af-bef2-1b932b986873 ), HTTP URLs ( https://id.example/things#123 ), and DIDs ( did:example:1234abcd ). Note : Identifiers of any kind increase correlatability Developers are reminded that identifiers might be harmful when pseudonymity is required. When considering such scenarios, developers are encouraged to read Identifier-Based Correlation in the Verifiable Credentials Data Model Threat Model carefully. There are also other types of access and correlation mechanisms documented in that threat model that create privacy concerns. Where privacy is a vital consideration, it is permissible to omit the id property . Some use cases do not need or explicitly need to omit, the id property . Similarly, special attention is to be given to the choice between publicly resolvable URLs and other forms of identifiers. Publicly resolvable URLs can facilitate ease of verification and interoperability, yet they might also inadvertently grant access to potentially sensitive information if not used judiciously. id The id property is OPTIONAL . If present, id property 's value MUST be a single URL , which MAY be dereferenceable. It is RECOMMENDED that the URL in the id be one which, if dereferenceable, results in a document containing machine-readable information about the id . Example 3 : Use of the id property Credential ecdsa ecdsa-sd bbs jose cose sd-jwt { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732" , "type": ["VerifiableCredential", "ExampleDegreeCredential"], "issuer": "https://university.example/issuers/565049", "validFrom": "2010-01-01T00:00:00Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21" , "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } } } application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/565049", "validFrom": "2010-01-01T00:00:00Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "DataIntegrityProof", "created": "2026-09-05T21:09:22Z", "verificationMethod": "did:key:zDnaeqpc578Kg3k9asdXLMhsQSjh8HMPp3ip3miiWZUUhsv9p", "cryptosuite": "ecdsa-rdfc-2019", "proofPurpose": "assertionMethod", "proofValue": "z5amhaLc2HywY7CB5z6UFqXLrHDcXjSm4T6JsLcy4uxjf39kdRkvxAY4xHSHhZobSZAf9amTcbyKdhtmfyLAtba2m" } } application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/565049", "validFrom": "2010-01-01T00:00:00Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "DataIntegrityProof", "created": "2026-09-05T21:09:22Z", "verificationMethod": "did:key:zDnaee6cRuNdNecab7A7cnbb6w5xovYRWxYirEHstya3usouK", "cryptosuite": "ecdsa-sd-2023", "proofPurpose": "assertionMethod", "proofValue": "u2V0AhVhAaa2xB7uvaVU45J2B464rmd3kx-QdQplIjUCPVS6xPla9cQ5cghCB8AkglwSBp-C-7GuqR2UgAqOQHJdGNkNdiVgjgCQD834RQUfUmZHshkJZ1Lb5L9q-WDizWanxekkIflcv6rZYIMmf3HbxMF3WhTn238aW1e1xgpZ7ZZz8KyzGznwFm17KhVhAXIl0Si7hASRY-Pit02JvKkdPshNBJ173cjc_SR2OjPFwRP2xk6m5u-M_ilIopxzvA0x8_qq4fNHr51sMJfzVulhAZf7JZOgYSxqpQS8KbTd7BH7tOQSdvp9vVzfIo42V3nPHVc5uvsBiU1tojwAv3SWkDzlhK820GM3SbeYZ136Iy1hAB-j7KmlI0jaSxkgWxwmgbq2pWI9lIjszPJGZI3n2ElHF5dsbRRpHikT_tRzQLyNnFYVq2Gl81ZMPuHsDA71G81hAYJYBuk-C2FmwbZiE-UjZ6nyFa5Mz4_vq47PK_0myc9HcIEJ9RZvYLJTFL5g820VMsfmx-uKSggR3MmotvPuALFhAZ6GEvqwHnNjeJ1wRW2NjScRuD0uVNuz-DT49swyBqpBngsQgsJC95SX_vIL4GfbXOWGaAkYOPS8CED_Tp91jT4FnL2lzc3Vlcg" } } application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/565049", "validFrom": "2010-01-01T00:00:00Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "DataIntegrityProof", "verificationMethod": "did:key:zUC7JVyoNecN4arDQjjTXVSfyv1V7bwcnMUs6y2BuSeWmzarPohM5DLXAXXxkBRrpjbzZTUdrLaAVoj87nPgXktL3q8JgBvRqqHo9Z88Jfn2tXXM8Q1aTDhNgf1HYL9WEMiULnS", "cryptosuite": "bbs-2023", "proofPurpose": "assertionMethod", "proofValue": "u2V0ChVhQh4ZbrGO7Wg8qsyvcnGBbBoDqN-XXQ7LIbkeP13o5yHIZ8tC6ELjpJrwsGFhQL2CsAdRvyoWAPlj-hGvALc6qEvIbbrt7axyOUl_cjBTbCFhYQD3-tli9rF9b1rOCOCaDSL0zj-QnIO3TIaEobJTPayaIS1r7HKFDPyyrvPGqNF8bjgNELvoomOjpbD9JEvaGI1pYYLMBLFvXdBPRt0k4kRZk93gc0jkscNQB3wJpCXu4OPkNaVJMlX03jEKZdwQ437AaRg2tSqfzd_pbHzZq9O7FyF1fsAT1tn_tHqFT5wrUWfaGtHJRQwv6rnUS3s9HBqQB_1ggs9FRoSirDoxtxfUeUCnCOCBrv8SGNsXujNCpyodzP-uBZy9pc3N1ZXI" } } 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": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/565049", "validFrom": "2010-01-01T00:00:00Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } } } application/vc+jwt eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ . eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiRXhhbXBsZURlZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDAwOjAwOjAwWiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoiZGlkOmV4YW1wbGU6ZWJmZWIxZjcxMmViYzZmMWMyNzZlMTJlYzIxIiwiZGVncmVlIjp7InR5cGUiOiJFeGFtcGxlQmFjaGVsb3JEZWdyZWUiLCJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5jZSBhbmQgQXJ0cyJ9fX0 . k8yuPc6NQWiLndySNHt-QdVNeEejlWIewg-JYY1jXxuTrMGwdV-OWu2ViwcO9FzFgFr8D6K9u73wDvZGlbsAvA application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/565049", "validFrom": "2010-01-01T00:00:00Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } } } application/vc+cose d28443a10128a05901be7b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f756e69766572736974792e6578616d706c652f63726564656e7469616c732f33373332222c2274797065223a5b2256657269666961626c6543726564656e7469616c222c224578616d706c6544656772656543726564656e7469616c225d2c22697373756572223a2268747470733a2f2f756e69766572736974792e6578616d706c652f697373756572732f353635303439222c2276616c696446726f6d223a22323031302d30312d30315430303a30303a30305a222c2263726564656e7469616c5375626a656374223a7b226964223a226469643a6578616d706c653a656266656231663731326562633666316332373665313265633231222c22646567726565223a7b2274797065223a224578616d706c6542616368656c6f72446567726565222c226e616d65223a2242616368656c6f72206f6620536369656e636520616e642041727473227d7d7d584028f98e4c04f487b0bbeeb5bae71bf67bcbae5ebe443b649c9b1fca40a6a9f3ed9b59e2f8bc53fe52bae0255f8648dbc16986af3ba6fbafc2fbf9f5c03bfa0c8e Encoded Decoded Issuer Disclosures eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ . eyJpYXQiOjE3ODg2NDI1NjIsImV4cCI6MTc4OTg1MjE2MiwiX3NkX2FsZyI6InNoYS0yNTYiLCJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDAwOjAwOjAwWiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImRlZ3JlZSI6eyJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5jZSBhbmQgQXJ0cyIsIl9zZCI6WyJOaU9RYzFBS0ZwTGpFZWk0OGxfOWlXZXN1ZGg2Z2tqTTl4V0gzSDhyWnNRIl19LCJfc2QiOlsiQ2ZMLUFIbzVDVU15MVZPb2NFd1hZaWJaTzcwMklBVHo5RWhiUXZDTHVsVSJdfSwiX3NkIjpbIlVsYjJ3QXk5OW43YWtKOWl5T0dGUUFwU0FTa2NjZ29EQkFESjRHWnZWOVkiLCJWRml6R0RBVl9LYkowYWxvTXNDYThHb01lVnk0NE1reGNIanlfZGMyTE40Il19 . wax7ZArxxF9djHjgTmWdHI2yBlKhNnlYS-bMtAf0BteIA9IwB0KSU5oHcM19xNScyHnGQ7MeoR_k_GAaom841A ~ WyJhRFdyLUF1TE53RGJFdURYU0lKelBRIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd ~ WyJ2RW12RGFvdFROU3FmQlJvaThJektBIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d ~ WyJIaHdvOXJaTWZJcHk4YzdvWDl3ZThRIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd ~ WyJSZFFzcW9VVVVWcnE4S1FfSjZSZENnIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0 ~ { "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro", "alg": "ES256" } { "iat": 1788642562, "exp": 1789852162, "_sd_alg": "sha-256", "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "issuer": "https://university.example/issuers/565049", "validFrom": "2010-01-01T00:00:00Z", "credentialSubject": { "degree": { "name": "Bachelor of Science and Arts", "_sd": [ "NiOQc1AKFpLjEei48l_9iWesudh6gkjM9xWH3H8rZsQ" ] }, "_sd": [ "CfL-AHo5CUMy1VOocEwXYibZO702IATz9EhbQvCLulU" ] }, "_sd": [ "Ulb2wAy99n7akJ9iyOGFQApSASkccgoDBADJ4GZvV9Y", "VFizGDAV_KbJ0aloMsCa8GoMeVy44MkxcHjy_dc2LN4" ] } Claim: id SHA-256 Hash: Ulb2wAy99n7akJ9iyOGFQApSASkccgoDBADJ4GZvV9Y Disclosure(s): WyJhRFdyLUF1TE53RGJFdURYU0lKelBRIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd Contents: [ "aDWr-AuLNwDbEuDXSIJzPQ", "id", "http://university.example/credentials/3732" ] Claim: type SHA-256 Hash: VFizGDAV_KbJ0aloMsCa8GoMeVy44MkxcHjy_dc2LN4 Disclosure(s): WyJ2RW12RGFvdFROU3FmQlJvaThJektBIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d Contents: [ "vEmvDaotTNSqfBRoi8IzKA", "type", [ "VerifiableCredential", "ExampleDegreeCredential" ] ] Claim: id SHA-256 Hash: CfL-AHo5CUMy1VOocEwXYibZO702IATz9EhbQvCLulU Disclosure(s): WyJIaHdvOXJaTWZJcHk4YzdvWDl3ZThRIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd Contents: [ "Hhwo9rZMfIpy8c7oX9we8Q", "id", "did:example:ebfeb1f712ebc6f1c276e12ec21" ] Claim: type SHA-256 Hash: NiOQc1AKFpLjEei48l_9iWesudh6gkjM9xWH3H8rZsQ Disclosure(s): WyJSZFFzcW9VVVVWcnE4S1FfSjZSZENnIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0 Contents: [ "RdQsqoUUUVrq8KQ_J6RdCg", "type", "ExampleBachelorDegree" ] The example above uses two types of identifiers. The first identifier is for the verifiable credential and uses an HTTP-based URL. The second identifier is for the subject of the verifiable credential (the thing the claims are about) and uses a decentralized identifier , also known as a DID . Note : Decentralized Identifiers are optional DIDs are a type of identifier which are not necessary for verifiable credentials to be useful. Specifically, verifiable credentials do not depend on DIDs and DIDs do not depend on verifiable credentials . However, many verifiable credentials will use DIDs , and software libraries implementing this specification will need to resolve DIDs . DID -based URLs are used to express identifiers associated with subjects , issuers , holders , credential status lists, cryptographic keys, and other machine-readable information associated with a verifiable credential . 4.5 Types Software systems that process the kinds of objects specified in this document use type information to determine whether or not a provided verifiable credential or verifiable presentation is appropriate for the intended use-case. This specification defines a type property for expressing object type information. This type information can be used during validation processes, as described in Appendix B. Validation . Verifiable credentials and verifiable presentations MUST contain a type property with an associated value. type The value of the type property MUST be one or more terms and absolute URL strings . If more than one value is provided, the order does not matter. Example 4 : Use of the type property Credential ecdsa ecdsa-sd bbs jose cose sd-jwt { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": ["VerifiableCredential", "ExampleDegreeCredential"] , "issuer": "https://university.example/issuers/565049", "validFrom": "2010-01-01T00:00:00Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } } } application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/565049", "validFrom": "2010-01-01T00:00:00Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "DataIntegrityProof", "created": "2026-09-05T21:09:22Z", "verificationMethod": "did:key:zDnaeqpc578Kg3k9asdXLMhsQSjh8HMPp3ip3miiWZUUhsv9p", "cryptosuite": "ecdsa-rdfc-2019", "proofPurpose": "assertionMethod", "proofValue": "z2csb49ns6Mof5KPLyzLQXnxpSRKxzHJGCY52Jq2tdTPRTDZQV8JK4ys6vTfUoYarvpe5BDzYGh79MFuVKBJ5PBhY" } } application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/565049", "validFrom": "2010-01-01T00:00:00Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "DataIntegrityProof", "created": "2026-09-05T21:09:22Z", "verificationMethod": "did:key:zDnaee6cRuNdNecab7A7cnbb6w5xovYRWxYirEHstya3usouK", "cryptosuite": "ecdsa-sd-2023", "proofPurpose": "assertionMethod", "proofValue": "u2V0AhVhASYq_Yc6pD9VdrVUjAMg_ykogtjLzQ8H3RFSHzGK6Y3JCe9hLIWpRNCWabzvnOCgfdhngU3dDX9Fh9p_YzwgBT1gjgCQCw149snFGhIf3Xa-I9BSDZzJGZb7kucbkD2SEt833laJYIGrncSHTnhFxFdbN1CPnm29IQgZgAUqi-ECWD9hqCPEChVhAQj2KCV9TF-j5bmQbTuGWDUd_8yU_nMQdJiBjFJRlTTJVrRzQe7vQzv4-0Kk9CrA67hNlwQPtzoY_s0ogQOr62FhAX1XOwq6tz50tv_iNlVwbRWA-ltPuAb5P-1q9v6qJt-s5iUnTt6nsG7xYUzFF7DLb1T-ipLlVHnLKbrS97ao9yVhAuXfqVZsX2kn75BtfbQNHBCoTYDSYycrT9MQo5zadGzOROqnVgO8Pvu-xdQYMW1WTkh9s1sQldNA_QkBbTUhaZlhAazUXicVF1Swoq6-OJNx0qtQVqonOYTidRKYGCVHMB-G_eogILbSKAq6bzzX1UjY_icFVYE1P4zxbAAJX1fBFulhABi1Af9f6AF8MM_cz0PO7VNRLwGVJIrgyEn3m0aAYQoYnfdFnPVa_eMWvllUgzqIMMxIC7RtyLKrgFC0JuKhCQ4FnL2lzc3Vlcg" } } application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/565049", "validFrom": "2010-01-01T00:00:00Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "DataIntegrityProof", "verificationMethod": "did:key:zUC7JVyoNecN4arDQjjTXVSfyv1V7bwcnMUs6y2BuSeWmzarPohM5DLXAXXxkBRrpjbzZTUdrLaAVoj87nPgXktL3q8JgBvRqqHo9Z88Jfn2tXXM8Q1aTDhNgf1HYL9WEMiULnS", "cryptosuite": "bbs-2023", "proofPurpose": "assertionMethod", "proofValue": "u2V0ChVhQh4ZbrGO7Wg8qsyvcnGBbBoDqN-XXQ7LIbkeP13o5yHIZ8tC6ELjpJrwsGFhQL2CsAdRvyoWAPlj-hGvALc6qEvIbbrt7axyOUl_cjBTbCFhYQD3-tli9rF9b1rOCOCaDSL0zj-QnIO3TIaEobJTPayaIS1r7HKFDPyyrvPGqNF8bjgNELvoomOjpbD9JEvaGI1pYYLMBLFvXdBPRt0k4kRZk93gc0jkscNQB3wJpCXu4OPkNaVJMlX03jEKZdwQ437AaRg2tSqfzd_pbHzZq9O7FyF1fsAT1tn_tHqFT5wrUWfaGtHJRQwv6rnUS3s9HBqQB_1ggogQCwPe68VtUqpT8fysP2HZaFj2P5VqWUt8Hs6EsaZSBZy9pc3N1ZXI" } } 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": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/565049", "validFrom": "2010-01-01T00:00:00Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } } } application/vc+jwt eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ . eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiRXhhbXBsZURlZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDAwOjAwOjAwWiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoiZGlkOmV4YW1wbGU6ZWJmZWIxZjcxMmViYzZmMWMyNzZlMTJlYzIxIiwiZGVncmVlIjp7InR5cGUiOiJFeGFtcGxlQmFjaGVsb3JEZWdyZWUiLCJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5jZSBhbmQgQXJ0cyJ9fX0 . U2Tej0WxzjpP_4rILDX_bEYrhyrZZ-isQlZzgqv8odUGozNrnAcYG3bP46O9srdZlYGj3wdrWN0bOYJmfbxRbw application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/565049", "validFrom": "2010-01-01T00:00:00Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } } } application/vc+cose d28443a10128a05901be7b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f756e69766572736974792e6578616d706c652f63726564656e7469616c732f33373332222c2274797065223a5b2256657269666961626c6543726564656e7469616c222c224578616d706c6544656772656543726564656e7469616c225d2c22697373756572223a2268747470733a2f2f756e69766572736974792e6578616d706c652f697373756572732f353635303439222c2276616c696446726f6d223a22323031302d30312d30315430303a30303a30305a222c2263726564656e7469616c5375626a656374223a7b226964223a226469643a6578616d706c653a656266656231663731326562633666316332373665313265633231222c22646567726565223a7b2274797065223a224578616d706c6542616368656c6f72446567726565222c226e616d65223a2242616368656c6f72206f6620536369656e636520616e642041727473227d7d7d5840db3d4f34eb63cc47ed29847bbb2f9d599fe9516c0b56a673e1bc896921d8b4d004af546905aaad81bf6c04a7c548677f8a9d12211b34eda44070edf86225feb0 Encoded Decoded Issuer Disclosures eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ . eyJpYXQiOjE3ODg2NDI1NjIsImV4cCI6MTc4OTg1MjE2MiwiX3NkX2FsZyI6InNoYS0yNTYiLCJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDAwOjAwOjAwWiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImRlZ3JlZSI6eyJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5jZSBhbmQgQXJ0cyIsIl9zZCI6WyJLNVlwN0pSREwwOURWcGFHQUNCVnhKVER2ZFZwbHRobjlqcWxHQjJ5MlNvIl19LCJfc2QiOlsiSk5mLUlXQ1htT2pqbl80Vl9MR0psbmtzaWFFWVVHLXA4U2lrTjBRLU14SSJdfSwiX3NkIjpbIlJ2d05scGJuVE9qU0JDbC03UEJJRkdhWHYtWUVLakx3c1NBNkxnUmU0MXciLCJpUnFkYjh0bHhJQW1nbW9peHFIZlJjazZoSlduTnNwOWplUXh0OWIwdGdnIl19 . 3bPlHzxt0HdyYX62SRGHogUMqjLUQhv6vGZ6oRhVsqv51Yw_hv8dmBWY_rPxssWCuBmZxZPihZGTPQMaRGgCvQ ~ WyJWdmlTanczVDNlalJKWDZqZEQtNVJRIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd ~ WyJqM0phNmdieWVfOVJrdjlXS0JuczN3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d ~ WyJJamhsSFlTS0pUWDA4eTlzQS0weXZnIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd ~ WyJ2WkVVZU9OV2pYaUd0VWdyVUtVV1dnIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0 ~ { "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro", "alg": "ES256" } { "iat": 1788642562, "exp": 1789852162, "_sd_alg": "sha-256", "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "issuer": "https://university.example/issuers/565049", "validFrom": "2010-01-01T00:00:00Z", "credentialSubject": { "degree": { "name": "Bachelor of Science and Arts", "_sd": [ "K5Yp7JRDL09DVpaGACBVxJTDvdVplthn9jqlGB2y2So" ] }, "_sd": [ "JNf-IWCXmOjjn_4V_LGJlnksiaEYUG-p8SikN0Q-MxI" ] }, "_sd": [ "RvwNlpbnTOjSBCl-7PBIFGaXv-YEKjLwsSA6LgRe41w", "iRqdb8tlxIAmgmoixqHfRck6hJWnNsp9jeQxt9b0tgg" ] } Claim: id SHA-256 Hash: iRqdb8tlxIAmgmoixqHfRck6hJWnNsp9jeQxt9b0tgg Disclosure(s): WyJWdmlTanczVDNlalJKWDZqZEQtNVJRIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd Contents: [ "VviSjw3T3ejRJX6jdD-5RQ", "id", "http://university.example/credentials/3732" ] Claim: type SHA-256 Hash: RvwNlpbnTOjSBCl-7PBIFGaXv-YEKjLwsSA6LgRe41w Disclosure(s): WyJqM0phNmdieWVfOVJrdjlXS0JuczN3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d Contents: [ "j3Ja6gbye_9Rkv9WKBns3w", "type", [ "VerifiableCredential", "ExampleDegreeCredential" ] ] Claim: id SHA-256 Hash: JNf-IWCXmOjjn_4V_LGJlnksiaEYUG-p8SikN0Q-MxI Disclosure(s): WyJJamhsSFlTS0pUWDA4eTlzQS0weXZnIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd Contents: [ "IjhlHYSKJTX08y9sA-0yvg", "id", "did:example:ebfeb1f712ebc6f1c276e12ec21" ] Claim: type SHA-256 Hash: K5Yp7JRDL09DVpaGACBVxJTDvdVplthn9jqlGB2y2So Disclosure(s): WyJ2WkVVZU9OV2pYaUd0VWdyVUtVV1dnIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0 Contents: [ "vZEUeONWjXiGtUgrUKUWWg", "type", "ExampleBachelorDegree" ] Concerning this specification, the following table lists the objects that MUST have a type specified. Object Type Verifiable credential object VerifiableCredential and, optionally, a more specific verifiable credential type . For example, "type": ["VerifiableCredential", "OpenBadgeCredential"] Verifiable presentation object VerifiablePresentation and, optionally, a more specific verifiable presentation type . For example, "type": "VerifiablePresentation" credentialStatus object A valid credential status type . For example, "type": "BitstringStatusListEntry" termsOfUse object A valid terms of use type . For example, "type": "TrustFrameworkPolicy" evidence object A valid evidence type . For example, "type": "Evidence" refreshService object A valid refreshService type . For example, "type": "VerifiableCredentialRefreshService2021" credentialSchema object A valid credentialSchema type . For example, "type": "JsonSchema" Note : The Verifiable Credentials Data Model is based on JSON-LD The type system for the Verifiable Credentials Data Model is the same as for JSON-LD 1.1 and is detailed in Section 3.5: Specifying the Type and Section 9: JSON-LD Grammar . When using a JSON-LD context (see Section 5.2 Extensibility ), this specification aliases the @type keyword to type to make the JSON-LD documents more easily understood. While application developers and document authors do not need to understand the specifics of the JSON-LD type system, implementers of this specification who want to support interoperable extensibility do. All credentials , presentations , and encapsulated objects SHOULD specify, or be associated with, additional, more narrow types (like ExampleDegreeCredential , for example) so software systems can more easily detect and process this additional information. When processing encapsulated objects defined in this specification, such as objects associated with the credentialSubject object or deeply nested therein, software systems SHOULD use the type information specified in encapsulating objects higher in the hierarchy. Specifically, an encapsulating object, such as a credential , SHOULD convey the associated object types so that verifiers can quickly determine the contents of an associated object based on the encapsulating object type . For example, a credential object with the type of ExampleDegreeCredential , signals to a verifier that the object associated with the credentialSubject property contains the identifier for the: Subject in the id property. Type of degree in the type property. Title of the degree in the name property. This enables implementers to rely on values associated with the type property for verification . Object types and their associated values are expected to be documented in at least a human-readable specification that can be found at the URL for the type. For example, the human-readable definition for the BitstringStatusList type can be found at https://www.w3.org/ns/credentials/status/#BitstringStatusList . It is also suggested that a machine-readable version be provided through HTTP content negotiation at the same URL. Note : See the Implementation Guide for creating new credential types Explaining how to create a new type of verifiable credential is beyond the scope of this specification. Readers interested in doing so are advised to read the Creating New Credential Types section in the Verifiable Credentials Implementation Guidelines 1.0 . 4.6 Names and Descriptions When displaying a credential , it can be helpful to have text provided by the issuer that furnishes the credential with a name and a short description of its purpose. The name and description properties serve these purposes. name An OPTIONAL property that expresses the name of the credential . If present, the value of the name property MUST be a string or a language value object as described in 9.1 Language and Base Direction . Ideally, the name of a credential is concise, human-readable, and could enable an individual to quickly differentiate one credential from any other credentials they might hold. description An OPTIONAL property that conveys specific details about a credential . If present, the value of the description property MUST be a string or a language value object as described in 9.1 Language and Base Direction . Ideally, the description of a credential is no more than a few sentences in length and conveys enough information about the credential to remind an individual of its contents without having to look through the entirety of the claims . Example 5 : Use of the name and description properties Credential ecdsa ecdsa-sd bbs jose cose sd-jwt { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": ["VerifiableCredential", "ExampleDegreeCredential"], "issuer": { "id": "https://university.example/issuers/565049", "name": "Example University", "description": "A public university focusing on teaching examples." }, "validFrom": "2015-05-10T12:30:00Z", "name": "Example University Degree", "description": "2015 Bachelor of Science and Arts Degree", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } } } application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": { "id": "https://university.example/issuers/565049", "name": "Example University", "description": "A public university focusing on teaching examples." }, "validFrom": "2015-05-10T12:30:00Z", "name": "Example University Degree", "description": "2015 Bachelor of Science and Arts Degree", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "DataIntegrityProof", "created": "2026-09-05T21:09:22Z", "verificationMethod": "did:key:zDnaeqpc578Kg3k9asdXLMhsQSjh8HMPp3ip3miiWZUUhsv9p", "cryptosuite": "ecdsa-rdfc-2019", "proofPurpose": "assertionMethod", "proofValue": "z3HyhJrQp4NGeTiCvA5PwA7LHmX6LEQjHvdj15hnMyUt3mDFpyQwkYTYHm16wrNejiaSnQJRtqdFRLBBn66sUtPYh" } } application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": { "id": "https://university.example/issuers/565049", "name": "Example University", "description": "A public university focusing on teaching examples." }, "validFrom": "2015-05-10T12:30:00Z", "name": "Example University Degree", "description": "2015 Bachelor of Science and Arts Degree", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "DataIntegrityProof", "created": "2026-09-05T21:09:22Z", "verificationMethod": "did:key:zDnaee6cRuNdNecab7A7cnbb6w5xovYRWxYirEHstya3usouK", "cryptosuite": "ecdsa-sd-2023", "proofPurpose": "assertionMethod", "proofValue": "u2V0AhVhA9eBZ3zjxuj0IcV6BJobNReA-F8MFuXarAEQkZu0XbBzMazxTcurv0sm6zbuZthOOYyUgufuZ9rFdjeG4WP9mpVgjgCQD0jQzO4hrZutcu3W9LvCVM9f0o1IUtWTn-4-L-3pyLIRYIItb5A4K0qAvYg4pmUOGWDuJ5HlF2Zxzf6yLVGr3gdmGh1hA_ZBp66r3OHhPze0PMFJkUMwEj_c5zb2jZc88nw7nCSBZI-pwZ2KcJLdgo2j237BxDkFtIez_-RojU1aycyYtdlhAtKygVIUGw2o1a1ihLVqshVrjXmndR1XKxj6mfchzM6gF0oq4UU4UkY2wXa2a7mu8yYzLGN3px9BorgpaZTu9llhApFGv_o2hoaiNDlhjFWJmuiU1g3R30TzmmjjKATdHnJ9tNTaVNsBMZ2KtujzDYTDDnXqOI9BQv-JWvOPm-pWEx1hAO2sJNL_bRhq6Xv1Zl7m1TyWId-bn3D2vRm3OxzwmY73v7kZgerL9-wiBB_3pF9xhlY9Ym1HWL4lFbRr4f8u-DlhAoh3GO_w-r9OuAeVhqkEH9ws-hHHEi-0PWUfr16hW-RgTteu0o2lx-Sa12h_N04D4jECG9DC1ySy3IOEf_3NDk1hA_EAkRyAAZhseD-h6DIv5s_nasDUXZqezES6FJiLeTSBLnGwoiLZRqBfmazBZBE2dobfXeFzRDhTG5jZvo-8W6VhAZaehJc5SCUwaQIGnH-yLbT6jLCDAo7iJaf3ICE_wHEmLQFLyUp2QMDVLnTlm3RFSs0WxG2DdExJNfArdmduNPoFnL2lzc3Vlcg" } } application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": { "id": "https://university.example/issuers/565049", "name": "Example University", "description": "A public university focusing on teaching examples." }, "validFrom": "2015-05-10T12:30:00Z", "name": "Example University Degree", "description": "2015 Bachelor of Science and Arts Degree", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "DataIntegrityProof", "verificationMethod": "did:key:zUC7JVyoNecN4arDQjjTXVSfyv1V7bwcnMUs6y2BuSeWmzarPohM5DLXAXXxkBRrpjbzZTUdrLaAVoj87nPgXktL3q8JgBvRqqHo9Z88Jfn2tXXM8Q1aTDhNgf1HYL9WEMiULnS", "cryptosuite": "bbs-2023", "proofPurpose": "assertionMethod", "proofValue": "u2V0ChVhQl2la-H4xA8qLgaVEsd550eGlNlHCKRQk9lkZHwGmuW1dZAov1NcuyRYt4atnKd_VRnffX6PPV1dT0trhLjLCh72S2ov3NQ5pZ0H5WWCO5uBYQD3-tli9rF9b1rOCOCaDSL0zj-QnIO3TIaEobJTPayaIXFDE8ZX70eeJX1DawHuw0sW9CBV3sa68IaRGcnZiiQpYYLMBLFvXdBPRt0k4kRZk93gc0jkscNQB3wJpCXu4OPkNaVJMlX03jEKZdwQ437AaRg2tSqfzd_pbHzZq9O7FyF1fsAT1tn_tHqFT5wrUWfaGtHJRQwv6rnUS3s9HBqQB_1ggA41wkpaGKw674WeJTsXTml3Zk_rjWZm8dPW2Qgv2tRmBZy9pc3N1ZXI" } } 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": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": { "id": "https://university.example/issuers/565049", "name": "Example University", "description": "A public university focusing on teaching examples." }, "validFrom": "2015-05-10T12:30:00Z", "name": "Example University Degree", "description": "2015 Bachelor of Science and Arts Degree", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } } } application/vc+jwt eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ . eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiRXhhbXBsZURlZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjp7ImlkIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJuYW1lIjoiRXhhbXBsZSBVbml2ZXJzaXR5IiwiZGVzY3JpcHRpb24iOiJBIHB1YmxpYyB1bml2ZXJzaXR5IGZvY3VzaW5nIG9uIHRlYWNoaW5nIGV4YW1wbGVzLiJ9LCJ2YWxpZEZyb20iOiIyMDE1LTA1LTEwVDEyOjMwOjAwWiIsIm5hbWUiOiJFeGFtcGxlIFVuaXZlcnNpdHkgRGVncmVlIiwiZGVzY3JpcHRpb24iOiIyMDE1IEJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMgRGVncmVlIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiaWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEiLCJkZWdyZWUiOnsidHlwZSI6IkV4YW1wbGVCYWNoZWxvckRlZ3JlZSIsIm5hbWUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIn19fQ . 2QwYCiUZG1PQ-6zwelj1YVEv705JSLxtFlCFCfEuKylfm69lCKgx2xDFkkr37gPgTeWl1NsZw1dMSLnBFAn5Jw application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": { "id": "https://university.example/issuers/565049", "name": "Example University", "description": "A public university focusing on teaching examples." }, "validFrom": "2015-05-10T12:30:00Z", "name": "Example University Degree", "description": "2015 Bachelor of Science and Arts Degree", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } } } application/vc+cose d28443a10128a05902807b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f756e69766572736974792e6578616d706c652f63726564656e7469616c732f33373332222c2274797065223a5b2256657269666961626c6543726564656e7469616c222c224578616d706c6544656772656543726564656e7469616c225d2c22697373756572223a7b226964223a2268747470733a2f2f756e69766572736974792e6578616d706c652f697373756572732f353635303439222c226e616d65223a224578616d706c6520556e6976657273697479222c226465736372697074696f6e223a2241207075626c696320756e697665727369747920666f637573696e67206f6e207465616368696e67206578616d706c65732e227d2c2276616c696446726f6d223a22323031352d30352d31305431323a33303a30305a222c226e616d65223a224578616d706c6520556e697665727369747920446567726565222c226465736372697074696f6e223a22323031352042616368656c6f72206f6620536369656e636520616e64204172747320446567726565222c2263726564656e7469616c5375626a656374223a7b226964223a226469643a6578616d706c653a656266656231663731326562633666316332373665313265633231222c22646567726565223a7b2274797065223a224578616d706c6542616368656c6f72446567726565222c226e616d65223a2242616368656c6f72206f6620536369656e636520616e642041727473227d7d7d5840b50eadcd376584690748a51b7b34f437467b1ca22bac3e93746328849b2b71e8f17c83d7d9aac166e2d46867fcf4b6799d40e4aa993d6a638f78cec4806108f8 Encoded Decoded Issuer Disclosures eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ . eyJpYXQiOjE3ODg2NDI1NjIsImV4cCI6MTc4OTg1MjE2MiwiX3NkX2FsZyI6InNoYS0yNTYiLCJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjp7Im5hbWUiOiJFeGFtcGxlIFVuaXZlcnNpdHkiLCJkZXNjcmlwdGlvbiI6IkEgcHVibGljIHVuaXZlcnNpdHkgZm9jdXNpbmcgb24gdGVhY2hpbmcgZXhhbXBsZXMuIiwiX3NkIjpbIjBEUE1PbzlHWm1Pbm9mREpEam4zR2QtRTRZVHZ0SW9YRjB3MkR1SUxaREEiXX0sInZhbGlkRnJvbSI6IjIwMTUtMDUtMTBUMTI6MzA6MDBaIiwibmFtZSI6IkV4YW1wbGUgVW5pdmVyc2l0eSBEZWdyZWUiLCJkZXNjcmlwdGlvbiI6IjIwMTUgQmFjaGVsb3Igb2YgU2NpZW5jZSBhbmQgQXJ0cyBEZWdyZWUiLCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsibmFtZSI6IkJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMiLCJfc2QiOlsiT0JqZG83STZybm4zSmNKLUl0R2lQU2tSQ3BRSU85cEYwTG1JcjFubWs0YyJdfSwiX3NkIjpbImQ2VkZNVUxJLW5kd1dLNFp4eUotREcwOWllQThTTVlzQmQwM1ZKX0UtXzQiXX0sIl9zZCI6WyIzeTZNMTlnUEQ5SUdkb3Nqa2VaY2F4cGlmYTR0VVZKS29QbEllcFFfVmlRIiwia25KVkJZU29sYTdSSllvcV90N0hvRFR1aEY5T2d3LXNzaHNKekEtUDdSTSJdfQ . Ss77eXXsK0fTrKneAZ6yO5rWPRi7zZMcdsxP--_GgDn6Dj4TeceyAQ0JZzcoX0G7s1SQ_AMj5f5v-JVIO1_-Mg ~ WyJBQ0I2SGtGSU1QSVhCcFpQY0kzbEV3IiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd ~ WyJBY3l4am05dG1XeG1xaGJQQ2I5M2Z3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d ~ WyI3Z05jX0lVWHpuQkhEOTk3ejlMenhRIiwgImlkIiwgImh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL2lzc3VlcnMvNTY1MDQ5Il0 ~ WyJ2ektlSzc0bmFCXzhRN1l2WThJTHd3IiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd ~ WyIxT1NqVjQ0WklSYnlxazVHMlo1RE5nIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0 ~ { "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro", "alg": "ES256" } { "iat": 1788642562, "exp": 1789852162, "_sd_alg": "sha-256", "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "issuer": { "name": "Example University", "description": "A public university focusing on teaching examples.", "_sd": [ "0DPMOo9GZmOnofDJDjn3Gd-E4YTvtIoXF0w2DuILZDA" ] }, "validFrom": "2015-05-10T12:30:00Z", "name": "Example University Degree", "description": "2015 Bachelor of Science and Arts Degree", "credentialSubject": { "degree": { "name": "Bachelor of Science and Arts", "_sd": [ "OBjdo7I6rnn3JcJ-ItGiPSkRCpQIO9pF0LmIr1nmk4c" ] }, "_sd": [ "d6VFMULI-ndwWK4ZxyJ-DG09ieA8SMYsBd03VJ_E-_4" ] }, "_sd": [ "3y6M19gPD9IGdosjkeZcaxpifa4tUVJKoPlIepQ_ViQ", "knJVBYSola7RJYoq_t7HoDTuhF9Ogw-sshsJzA-P7RM" ] } Claim: id SHA-256 Hash: 3y6M19gPD9IGdosjkeZcaxpifa4tUVJKoPlIepQ_ViQ Disclosure(s): WyJBQ0I2SGtGSU1QSVhCcFpQY0kzbEV3IiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd Contents: [ "ACB6HkFIMPIXBpZPcI3lEw", "id", "http://university.example/credentials/3732" ] Claim: type SHA-256 Hash: knJVBYSola7RJYoq_t7HoDTuhF9Ogw-sshsJzA-P7RM Disclosure(s): WyJBY3l4am05dG1XeG1xaGJQQ2I5M2Z3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d Contents: [ "Acyxjm9tmWxmqhbPCb93fw", "type", [ "VerifiableCredential", "ExampleDegreeCredential" ] ] Claim: id SHA-256 Hash: 0DPMOo9GZmOnofDJDjn3Gd-E4YTvtIoXF0w2DuILZDA Disclosure(s): WyI3Z05jX0lVWHpuQkhEOTk3ejlMenhRIiwgImlkIiwgImh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL2lzc3VlcnMvNTY1MDQ5Il0 Contents: [ "7gNc_IUXznBHD997z9LzxQ", "id", "https://university.example/issuers/565049" ] Claim: id SHA-256 Hash: d6VFMULI-ndwWK4ZxyJ-DG09ieA8SMYsBd03VJ_E-_4 Disclosure(s): WyJ2ektlSzc0bmFCXzhRN1l2WThJTHd3IiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd Contents: [ "vzKeK74naB_8Q7YvY8ILww", "id", "did:example:ebfeb1f712ebc6f1c276e12ec21" ] Claim: type SHA-256 Hash: OBjdo7I6rnn3JcJ-ItGiPSkRCpQIO9pF0LmIr1nmk4c Disclosure(s): WyIxT1NqVjQ0WklSYnlxazVHMlo1RE5nIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0 Contents: [ "1OSjV44ZIRbyqk5G2Z5DNg", "type", "ExampleBachelorDegree" ] Names and descriptions also support expressing content in different languages. To express a string with language and base direction information, one can use an object that contains the @value , @language , and @direction properties to express the text value, language tag, and base direction, respectively. See 9.1 Language and Base Direction for further information. Note : @direction is not required for single-language strings The @direction property in the examples below is not required for the associated single-language strings, as their default directions are the same as those set by the @direction value. We include the @direction property here for clarity of demonstration and to make copy+paste+edit deliver functional results. Implementers are encouraged to read the section on String Internationalization in the JSON-LD 1.1 specification. Example 6 : Use of the name and description properties { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": ["VerifiableCredential", "ExampleDegreeCredential"], "issuer": { "id": "https://university.example/issuers/565049", "name": [{ "@value": "Example University", "@language": "en" }, { "@value": "Université Exemple", "@language": "fr" }, { "@value": "جامعة المثال", "@language": "ar", "@direction": "rtl" }], "description": [{ "@value": "A public university focusing on teaching examples.", "@language": "en" }, { "@value": "Une université publique axée sur l'enseignement d'exemples.", "@language": "fr" }, { "@value": ".جامعة عامة تركز على أمثلة التدريس", "@language": "ar", "@direction": "rtl" }] }, "validFrom": "2015-05-10T12:30:00Z", "name": [{ "@value": "Example University Degree", "@language": "en" }, { "@value": "Exemple de Diplôme Universitaire", "@language": "fr" }, { "@value": "مثال الشهادة الجامعية", "@language": "ar", "@direction": "rtl" }], "description": [{ "@value": "2015 Bachelor of Science and Arts Degree", "@language": "en" }, { "@value": "2015 Licence de Sciences et d'Arts", "@language": "fr" }, { "@value": "2015 بكالوريوس العلوم والآداب", "@language": "ar", "@direction": "rtl" }], "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": [{ "@value": "Bachelor of Science and Arts Degree", "@language": "en" }, { "@value": "Licence de Sciences et d'Arts", "@language": "fr" }, { "@value": "بكالوريوس العلوم والآداب", "@language": "ar", "@direction": "rtl" }] } } } 4.7 Issuer This specification defines a property for expressing the issuer of a verifiable credential . A verifiable credential MUST have an issuer property . issuer The value of the issuer property MUST be either a URL or an object containing an id property whose value is a URL ; in either case, the issuer selects this URL to identify itself in a globally unambiguous way. It is RECOMMENDED that the URL be one which, if dereferenced, results in a controlled identifier document, as defined in the Controlled Identifiers v1.0 specification, about the issuer that can be used to verify the information expressed in the credential . Example 7 : Use of the issuer property Credential ecdsa ecdsa-sd bbs jose cose sd-jwt { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": ["VerifiableCredential", "ExampleDegreeCredential"], "issuer": "https://university.example/issuers/14" , "validFrom": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } } } application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/14", "validFrom": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "DataIntegrityProof", "created": "2026-09-05T21:09:22Z", "verificationMethod": "did:key:zDnaeqpc578Kg3k9asdXLMhsQSjh8HMPp3ip3miiWZUUhsv9p", "cryptosuite": "ecdsa-rdfc-2019", "proofPurpose": "assertionMethod", "proofValue": "z3UCx3YbHeZZ7jq8D9b8itNZpbdMLSQuC6i8r5zAF9DDA2S2gAq6KgGUa5F31F6FTSvxhXyimumJFV9m5ub7wtw9N" } } application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/14", "validFrom": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "DataIntegrityProof", "created": "2026-09-05T21:09:22Z", "verificationMethod": "did:key:zDnaee6cRuNdNecab7A7cnbb6w5xovYRWxYirEHstya3usouK", "cryptosuite": "ecdsa-sd-2023", "proofPurpose": "assertionMethod", "proofValue": "u2V0AhVhAa2HEMU6j7PN6xbRdWN0Zsa8vDmfTHzTe36iKWQfBKh6Y0b7m3De12WPMIWVJBGAN8PkoGo7g_E3DlG_LRtY3AVgjgCQCiQP8EMTwRK3tKiHAmoANxo9F6trm2I6oEqKfDR1SnclYIN7qqaZYhank4REfmamLJNbFw6nZFoQ27MNtj4phTIn0hVhALdKrGxMp4j3OgOAyKUIoirGHqkk5cE2T6xQNoPv-AqgV3BHMRdCGytmB__LLgSfrGikbrmIZzkncAjgBQLYVlFhAtp35vUtjU22xwN0ApmnsFLLhvMZE82iXQbDoJPdYex4gcEy3VCShiAHq0fZQQ_w57JzRvtTFSN5nB5fUnv15L1hALfh0IlQXV2UWzV1u45FasE9d3KSq1TDLgGYHz1eN6DQ56LjyP-FIGPltBoygOAF4lFfYLLbYK5eXt7c7KQGQulhA_6r3E5REhY0n4fmWebUH536aV5H57yCm0uMoFArhGjJKF9GOfBYDlq89rFdavMJw0ooCoPjsmOiyp_fYnqdyDFhAB0w3WreQqv3n57p0RWRvVeS7oPA0S_sFF90IBtGd1sqc_iGNww0UMEUi1UZYX--n9fehg0rmeDxlv1iwKuSYDoFnL2lzc3Vlcg" } } application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/14", "validFrom": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "DataIntegrityProof", "verificationMethod": "did:key:zUC7JVyoNecN4arDQjjTXVSfyv1V7bwcnMUs6y2BuSeWmzarPohM5DLXAXXxkBRrpjbzZTUdrLaAVoj87nPgXktL3q8JgBvRqqHo9Z88Jfn2tXXM8Q1aTDhNgf1HYL9WEMiULnS", "cryptosuite": "bbs-2023", "proofPurpose": "assertionMethod", "proofValue": "u2V0ChVhQuVb-Kl_Muxvn-scLX6yvPSEO1qatpJujOOaTHvosYOQTCLj72z1-GPkeps5LCt79YAPzx-tcnHGcKaxXT4UQSfmw3Yit_mohbAXWSvO3AQlYQD3-tli9rF9b1rOCOCaDSL0zj-QnIO3TIaEobJTPayaIKnv3N5iX7nvZR0OCXS-uXH4QQ9mW65QM5qlHOfE4GQVYYLMBLFvXdBPRt0k4kRZk93gc0jkscNQB3wJpCXu4OPkNaVJMlX03jEKZdwQ437AaRg2tSqfzd_pbHzZq9O7FyF1fsAT1tn_tHqFT5wrUWfaGtHJRQwv6rnUS3s9HBqQB_1gg2-BQp1R2IM3QoFUI2WfaF3HqCxy8Z_1jh-u4xLek3tSBZy9pc3N1ZXI" } } 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": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/14", "validFrom": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } } } application/vc+jwt eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ . eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiRXhhbXBsZURlZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy8xNCIsInZhbGlkRnJvbSI6IjIwMTAtMDEtMDFUMTk6MjM6MjRaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiaWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEiLCJkZWdyZWUiOnsidHlwZSI6IkV4YW1wbGVCYWNoZWxvckRlZ3JlZSIsIm5hbWUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIn19fQ . kQK0sB_RWOnzK77h19eC4OK6Hp4EZbBIHq8nFpQ07gn5oXo68lF7HE_dpM9Tol4eSDEYfDHy2QXQ06b---8Efg application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/14", "validFrom": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } } } application/vc+cose d28443a10128a05901ba7b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f756e69766572736974792e6578616d706c652f63726564656e7469616c732f33373332222c2274797065223a5b2256657269666961626c6543726564656e7469616c222c224578616d706c6544656772656543726564656e7469616c225d2c22697373756572223a2268747470733a2f2f756e69766572736974792e6578616d706c652f697373756572732f3134222c2276616c696446726f6d223a22323031302d30312d30315431393a32333a32345a222c2263726564656e7469616c5375626a656374223a7b226964223a226469643a6578616d706c653a656266656231663731326562633666316332373665313265633231222c22646567726565223a7b2274797065223a224578616d706c6542616368656c6f72446567726565222c226e616d65223a2242616368656c6f72206f6620536369656e636520616e642041727473227d7d7d58409e7ca40dba7532dc091810bb3b3aab2725d5bc8f6c255d96b970fca71327c5264eadee6482703616a6db00beac1f763d3dd38e7fb4529e67e5be970a35f8dc37 Encoded Decoded Issuer Disclosures eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ . eyJpYXQiOjE3ODg2NDI1NjIsImV4cCI6MTc4OTg1MjE2MiwiX3NkX2FsZyI6InNoYS0yNTYiLCJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy8xNCIsInZhbGlkRnJvbSI6IjIwMTAtMDEtMDFUMTk6MjM6MjRaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiZGVncmVlIjp7Im5hbWUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIiwiX3NkIjpbIkk3cGpzNF93eWMwbFdFNGFDbmxWcUlsWHdZVGNUWmZNVFRxSXZRLVhNVFUiXX0sIl9zZCI6WyJ0aTkwWFIwOF83eFN2Y0tIdDVuOS1jcUJMd2JhVXdfc0ppSDNlTV9vVDcwIl19LCJfc2QiOlsiUllhMUhQb19KcUw5a1FlOF94c2tGNjYzQldXbTNXNHlaRzhoTzN0dm1BQSIsImhrbjRQV09xZE5BcTNNU0JGd1kwVXhIYjdRLW1iQ1hnWHprZmpPZzRyWjgiXX0 . LtEzqeZk1HJgA8BDqumeIiRf_qK7EtAPL94oFL5KsKTOzQckhDx2EG9lrdmmEYccokSsZqmh5tqtPIplYAMajw ~ WyJ4ak1NbkJPMVZJQVNDZnlqSDk4VG93IiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd ~ WyIyZC1oWHdXQW5TZFFPQlA4RTN6UXpnIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d ~ WyJWSk5ZV3ZTR1RXemVhWGd4dEg0VDJnIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd ~ WyJUdE1KZUJhOS1GU3g4bXBIazdqOVJ3IiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0 ~ { "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro", "alg": "ES256" } { "iat": 1788642562, "exp": 1789852162, "_sd_alg": "sha-256", "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "issuer": "https://university.example/issuers/14", "validFrom": "2010-01-01T19:23:24Z", "credentialSubject": { "degree": { "name": "Bachelor of Science and Arts", "_sd": [ "I7pjs4_wyc0lWE4aCnlVqIlXwYTcTZfMTTqIvQ-XMTU" ] }, "_sd": [ "ti90XR08_7xSvcKHt5n9-cqBLwbaUw_sJiH3eM_oT70" ] }, "_sd": [ "RYa1HPo_JqL9kQe8_xskF663BWWm3W4yZG8hO3tvmAA", "hkn4PWOqdNAq3MSBFwY0UxHb7Q-mbCXgXzkfjOg4rZ8" ] } Claim: id SHA-256 Hash: hkn4PWOqdNAq3MSBFwY0UxHb7Q-mbCXgXzkfjOg4rZ8 Disclosure(s): WyJ4ak1NbkJPMVZJQVNDZnlqSDk4VG93IiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd Contents: [ "xjMMnBO1VIASCfyjH98Tow", "id", "http://university.example/credentials/3732" ] Claim: type SHA-256 Hash: RYa1HPo_JqL9kQe8_xskF663BWWm3W4yZG8hO3tvmAA Disclosure(s): WyIyZC1oWHdXQW5TZFFPQlA4RTN6UXpnIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d Contents: [ "2d-hXwWAnSdQOBP8E3zQzg", "type", [ "VerifiableCredential", "ExampleDegreeCredential" ] ] Claim: id SHA-256 Hash: ti90XR08_7xSvcKHt5n9-cqBLwbaUw_sJiH3eM_oT70 Disclosure(s): WyJWSk5ZV3ZTR1RXemVhWGd4dEg0VDJnIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd Contents: [ "VJNYWvSGTWzeaXgxtH4T2g", "id", "did:example:ebfeb1f712ebc6f1c276e12ec21" ] Claim: type SHA-256 Hash: I7pjs4_wyc0lWE4aCnlVqIlXwYTcTZfMTTqIvQ-XMTU Disclosure(s): WyJUdE1KZUJhOS1GU3g4bXBIazdqOVJ3IiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0 Contents: [ "TtMJeBa9-FSx8mpHk7j9Rw", "type", "ExampleBachelorDegree" ] It is also possible to express additional information about the issuer by associating an object with the issuer property: Example 8 : Expanded use of the issuer property Credential ecdsa ecdsa-sd bbs jose cose sd-jwt { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": ["VerifiableCredential", "ExampleDegreeCredential"], "issuer": { "id": "did:example:76e12ec712ebc6f1c221ebfeb1f", "name": "Example University" } , "validFrom": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } } } application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": { "id": "did:example:76e12ec712ebc6f1c221ebfeb1f", "name": "Example University" }, "validFrom": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "DataIntegrityProof", "created": "2026-09-05T21:09:22Z", "verificationMethod": "did:key:zDnaeqpc578Kg3k9asdXLMhsQSjh8HMPp3ip3miiWZUUhsv9p", "cryptosuite": "ecdsa-rdfc-2019", "proofPurpose": "assertionMethod", "proofValue": "z4xErymdqkw11RkatDqHgEvBP5FGrj5VkGXwzG2X4wherYnH1jPbtQX9MSEHvXp729pPLnYH84VC6C7HWQDtL1j6" } } application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": { "id": "did:example:76e12ec712ebc6f1c221ebfeb1f", "name": "Example University" }, "validFrom": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "DataIntegrityProof", "created": "2026-09-05T21:09:22Z", "verificationMethod": "did:key:zDnaee6cRuNdNecab7A7cnbb6w5xovYRWxYirEHstya3usouK", "cryptosuite": "ecdsa-sd-2023", "proofPurpose": "assertionMethod", "proofValue": "u2V0AhVhAvfJXBZd496XcZcCwYXJd-ijIx7U4lHyPku8ZD32Q0haH-wCu1FlOgSB-VQFtqBRxrIjDk6Xul3M3k72czY7JQ1gjgCQC0qfQ1BOcJ5Lkvm8k8hQ1rkVb8c_pPsdXRROosouMCztYIJPtpPPjBzmHsmCvq3lL1tcKi5M9wLeJZpXgg-rPxkqJhVhAec_i5BhyI2YKR839DxtJsM32qwkw7hT1zPxY1FODUKkaUY2PGkJal764UBBs_Pkud0fNagLDO5D0wC41Qw9c5lhA21mnQnoYd4gFIdRl0Pnrn2kW0BnC35qzpKXeBTefedsWE3WqXUbagY0jaQHt1kYNTk3w3YUuf3fKwasI5iXEYlhASYapu5wsl4wpWYJMM-hjltjsXTbtPq1j91395s7eQdR3aOkoBuyfd-5GHGorMAkf0M_l0Cr0RPfvlxu4MPXUb1hAzIBNBho458ey2UYVWQ51LZQoiOwBIgcmKhMFO5rr7ixI-BLeXGb-CMGhTMA7cCcdTsXyy9rlpGm0jvG5rvQfHFhAC0f31KQBMCOoWoDTcv-3Xt7cpARy5rfbKQletriZTOZ_iZZj2haG3N2m3_K0jWhdL1XzmGAe09TcXTSSXMOI04FnL2lzc3Vlcg" } } application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": { "id": "did:example:76e12ec712ebc6f1c221ebfeb1f", "name": "Example University" }, "validFrom": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "DataIntegrityProof", "verificationMethod": "did:key:zUC7JVyoNecN4arDQjjTXVSfyv1V7bwcnMUs6y2BuSeWmzarPohM5DLXAXXxkBRrpjbzZTUdrLaAVoj87nPgXktL3q8JgBvRqqHo9Z88Jfn2tXXM8Q1aTDhNgf1HYL9WEMiULnS", "cryptosuite": "bbs-2023", "proofPurpose": "assertionMethod", "proofValue": "u2V0ChVhQrC7s_jn_2bwymqWbq1r4dAfhkZoAxsoLiKk3ri6eIo2RCMH-bYE_-9mUodo_RgudSXAcmDtUlwf8kET_gnOdt5QzwKPefjcsyNbxTU283CRYQD3-tli9rF9b1rOCOCaDSL0zj-QnIO3TIaEobJTPayaIQAGpGXTZS6rwOppAPreXlDb3xQb46PJ_xcVri0glVYJYYLMBLFvXdBPRt0k4kRZk93gc0jkscNQB3wJpCXu4OPkNaVJMlX03jEKZdwQ437AaRg2tSqfzd_pbHzZq9O7FyF1fsAT1tn_tHqFT5wrUWfaGtHJRQwv6rnUS3s9HBqQB_1ggP983JVVEFktPJIXhwxdTbW-LoPF5dJVQH4jhjefR9sOBZy9pc3N1ZXI" } } 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": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": { "id": "did:example:76e12ec712ebc6f1c221ebfeb1f", "name": "Example University" }, "validFrom": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } } } application/vc+jwt eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ . eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiRXhhbXBsZURlZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjp7ImlkIjoiZGlkOmV4YW1wbGU6NzZlMTJlYzcxMmViYzZmMWMyMjFlYmZlYjFmIiwibmFtZSI6IkV4YW1wbGUgVW5pdmVyc2l0eSJ9LCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoiZGlkOmV4YW1wbGU6ZWJmZWIxZjcxMmViYzZmMWMyNzZlMTJlYzIxIiwiZGVncmVlIjp7InR5cGUiOiJFeGFtcGxlQmFjaGVsb3JEZWdyZWUiLCJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5jZSBhbmQgQXJ0cyJ9fX0 . Y79IjwV5O38E1LqWiLkKA34Fzi2Vua76HLsvqp96pdnG9FfoRuIAOCTZPneWL7fGeZoYCugjKFO9ZiryofDZRA application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": { "id": "did:example:76e12ec712ebc6f1c221ebfeb1f", "name": "Example University" }, "validFrom": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } } } application/vc+cose d28443a10128a05901df7b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f756e69766572736974792e6578616d706c652f63726564656e7469616c732f33373332222c2274797065223a5b2256657269666961626c6543726564656e7469616c222c224578616d706c6544656772656543726564656e7469616c225d2c22697373756572223a7b226964223a226469643a6578616d706c653a373665313265633731326562633666316332323165626665623166222c226e616d65223a224578616d706c6520556e6976657273697479227d2c2276616c696446726f6d223a22323031302d30312d30315431393a32333a32345a222c2263726564656e7469616c5375626a656374223a7b226964223a226469643a6578616d706c653a656266656231663731326562633666316332373665313265633231222c22646567726565223a7b2274797065223a224578616d706c6542616368656c6f72446567726565222c226e616d65223a2242616368656c6f72206f6620536369656e636520616e642041727473227d7d7d5840d9322464c01ef2aff836e303f5f538f78dc9c0f670587c2ebf24d2757239a9954c292402c749d46064eba12dbec16b6b18119ef3e4d8f7d4b935942c67ba56fe Encoded Decoded Issuer Disclosures eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ . eyJpYXQiOjE3ODg2NDI1NjIsImV4cCI6MTc4OTg1MjE2MiwiX3NkX2FsZyI6InNoYS0yNTYiLCJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjp7Im5hbWUiOiJFeGFtcGxlIFVuaXZlcnNpdHkiLCJfc2QiOlsiZ21HbG9pSk5sanZiempjNExnMUc0VnlvS3JYUERWa0hsVzBRNURGX2xJbyJdfSwidmFsaWRGcm9tIjoiMjAxMC0wMS0wMVQxOToyMzoyNFoiLCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsibmFtZSI6IkJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMiLCJfc2QiOlsiVVBBdm1WMDRoN2tyblFDd0RSeFIwclhCdXlJTlF0ZHd2NXYwNWphWVdqRSJdfSwiX3NkIjpbIlBtVkdQS0ZFU3VMNWdXbFZ5TEhLUlJZRzY3bHYzY0pPTHk2T1hNdmQwM3ciXX0sIl9zZCI6WyJNMy1ma3Q3R2dNTFFQa2p0UHUyZGVWMlVmdjlCSjRlMDVUczNGLVBHUEY4IiwiT0pCdmdCR3haX2FqY2VYUzVGcEowajJpM1ljWC1IZk1lcFJ3VWFGVlVmcyJdfQ . dIDdNeqMoat9JK1PtldV1AuNPlyD9_8xG1-szxWooDkdPPKhpCttlM3DCvB_mIhxGWJYs9UIlAReqmT57A1fHw ~ WyJSVV9lZWlsckdIeVJER1VCX0MtT0lBIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd ~ WyJjYVVtWl8tNTRSUV9tRDBpTTBzLUdRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d ~ WyJZRm9SY3UxOExZbjhlUmhfOE41V21RIiwgImlkIiwgImRpZDpleGFtcGxlOjc2ZTEyZWM3MTJlYmM2ZjFjMjIxZWJmZWIxZiJd ~ WyJmZzNnNkZEY3p5T0NlU2VkU2hWaXNnIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd ~ WyJMdWhGQ2FyVmNSRUstZ1NmbVFyWGtRIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0 ~ { "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro", "alg": "ES256" } { "iat": 1788642562, "exp": 1789852162, "_sd_alg": "sha-256", "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "issuer": { "name": "Example University", "_sd": [ "gmGloiJNljvbzjc4Lg1G4VyoKrXPDVkHlW0Q5DF_lIo" ] }, "validFrom": "2010-01-01T19:23:24Z", "credentialSubject": { "degree": { "name": "Bachelor of Science and Arts", "_sd": [ "UPAvmV04h7krnQCwDRxR0rXBuyINQtdwv5v05jaYWjE" ] }, "_sd": [ "PmVGPKFESuL5gWlVyLHKRRYG67lv3cJOLy6OXMvd03w" ] }, "_sd": [ "M3-fkt7GgMLQPkjtPu2deV2Ufv9BJ4e05Ts3F-PGPF8", "OJBvgBGxZ_ajceXS5FpJ0j2i3YcX-HfMepRwUaFVUfs" ] } Claim: id SHA-256 Hash: OJBvgBGxZ_ajceXS5FpJ0j2i3YcX-HfMepRwUaFVUfs Disclosure(s): WyJSVV9lZWlsckdIeVJER1VCX0MtT0lBIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd Contents: [ "RU_eeilrGHyRDGUB_C-OIA", "id", "http://university.example/credentials/3732" ] Claim: type SHA-256 Hash: M3-fkt7GgMLQPkjtPu2deV2Ufv9BJ4e05Ts3F-PGPF8 Disclosure(s): WyJjYVVtWl8tNTRSUV9tRDBpTTBzLUdRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d Contents: [ "caUmZ_-54RQ_mD0iM0s-GQ", "type", [ "VerifiableCredential", "ExampleDegreeCredential" ] ] Claim: id SHA-256 Hash: gmGloiJNljvbzjc4Lg1G4VyoKrXPDVkHlW0Q5DF_lIo Disclosure(s): WyJZRm9SY3UxOExZbjhlUmhfOE41V21RIiwgImlkIiwgImRpZDpleGFtcGxlOjc2ZTEyZWM3MTJlYmM2ZjFjMjIxZWJmZWIxZiJd Contents: [ "YFoRcu18LYn8eRh_8N5WmQ", "id", "did:example:76e12ec712ebc6f1c221ebfeb1f" ] Claim: id SHA-256 Hash: PmVGPKFESuL5gWlVyLHKRRYG67lv3cJOLy6OXMvd03w Disclosure(s): WyJmZzNnNkZEY3p5T0NlU2VkU2hWaXNnIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd Contents: [ "fg3g6FDczyOCeSedShVisg", "id", "did:example:ebfeb1f712ebc6f1c276e12ec21" ] Claim: type SHA-256 Hash: UPAvmV04h7krnQCwDRxR0rXBuyINQtdwv5v05jaYWjE Disclosure(s): WyJMdWhGQ2FyVmNSRUstZ1NmbVFyWGtRIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0 Contents: [ "LuhFCarVcREK-gSfmQrXkQ", "type", "ExampleBachelorDegree" ] Note : The identifier for an issuer can be any URL The value of the issuer property can also be a JWK (for example, "https://jwk.example/keys/foo.jwk" ) or a DID (for example, "did:example:abfe13f712120431c276e12ecab" ). 4.8 Credential Subject A verifiable credential contains claims about one or more subjects . This specification defines a credentialSubject property for the expression of claims about one or more subjects . A verifiable credential MUST contain a credentialSubject property . credentialSubject The value of the credentialSubject property is a set of objects where each object MUST be the subject of one or more claims , which MUST be serialized inside the credentialSubject property . Each object MAY also contain an id property to identify the subject , as described in Section 4.4 Identifiers . Example 9 : Use of the credentialSubject property Credential ecdsa ecdsa-sd bbs jose cose sd-jwt { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": ["VerifiableCredential", "ExampleDegreeCredential"], "issuer": "https://university.example/issuers/565049", "validFrom": "2010-01-01T00:00:00Z", "credentialSubject" : { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } } } application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/565049", "validFrom": "2010-01-01T00:00:00Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "DataIntegrityProof", "created": "2026-09-05T21:09:22Z", "verificationMethod": "did:key:zDnaeqpc578Kg3k9asdXLMhsQSjh8HMPp3ip3miiWZUUhsv9p", "cryptosuite": "ecdsa-rdfc-2019", "proofPurpose": "assertionMethod", "proofValue": "z32tZqevy2bWArZtNTr9uVuxHMYBRC3NXaRUR8rvvferx7WMjerYAsvxJjCtkjB7V2o9hecPr9qd5CTckPYGBXh3G" } } application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/565049", "validFrom": "2010-01-01T00:00:00Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "DataIntegrityProof", "created": "2026-09-05T21:09:22Z", "verificationMethod": "did:key:zDnaee6cRuNdNecab7A7cnbb6w5xovYRWxYirEHstya3usouK", "cryptosuite": "ecdsa-sd-2023", "proofPurpose": "assertionMethod", "proofValue": "u2V0AhVhA101-mPu7ZDbK5Tm8EsTf_p8zOtqgtBbEBi4GDeT7KSILKQzd1IiIIZpx82U6GGYE-xwan9dtkd7_L5VrgCJaHlgjgCQCScXI7nbF_qrx-mTD4wve_ns3Q7E0w5HdO4rnJ-PAYyZYIGRJawpdeBNF6zkm8Ie6T9qojlermHaffjIgILL-9UMihVhAk64ss8WQazULbGnusVBTxy5jcpYJg10XsG__443pcVqDDjvLhfntW-amMT9alMgAoKIIJmGLlFD804gtlAuOUFhABG_iIWJfdYdn9uxr7kBSpVDyGuOaTrqFGpB0cqvHq8hPkGFoEJdRZo51-K3P2QgZ_ViGGWjNAh23H6CKw6XCf1hAChaXCI7p7FST1dwm91Zy_bibXx6UxfWyKHRhx6eKTagfRZAJ-uhz94-_Eu02q0zldcGEF8Hyfv04wnL61gF7Q1hAL-OYZzNHClpuX85mKTtK04BJ5-EQ26-idA5p6Z726JCJFUzibrHfI9KU_avQiTeWrv1Ss046n6BqyvthsBpKKlhACjOoGlPmmZXA-FB3z6DrRbjF8EEGpKLpZiAu7jH7aMpOxcV5tN7W9B255HiFZndwh1iW0abSEcz_34pnhjpi6YFnL2lzc3Vlcg" } } application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/565049", "validFrom": "2010-01-01T00:00:00Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "DataIntegrityProof", "verificationMethod": "did:key:zUC7JVyoNecN4arDQjjTXVSfyv1V7bwcnMUs6y2BuSeWmzarPohM5DLXAXXxkBRrpjbzZTUdrLaAVoj87nPgXktL3q8JgBvRqqHo9Z88Jfn2tXXM8Q1aTDhNgf1HYL9WEMiULnS", "cryptosuite": "bbs-2023", "proofPurpose": "assertionMethod", "proofValue": "u2V0ChVhQh4ZbrGO7Wg8qsyvcnGBbBoDqN-XXQ7LIbkeP13o5yHIZ8tC6ELjpJrwsGFhQL2CsAdRvyoWAPlj-hGvALc6qEvIbbrt7axyOUl_cjBTbCFhYQD3-tli9rF9b1rOCOCaDSL0zj-QnIO3TIaEobJTPayaIS1r7HKFDPyyrvPGqNF8bjgNELvoomOjpbD9JEvaGI1pYYLMBLFvXdBPRt0k4kRZk93gc0jkscNQB3wJpCXu4OPkNaVJMlX03jEKZdwQ437AaRg2tSqfzd_pbHzZq9O7FyF1fsAT1tn_tHqFT5wrUWfaGtHJRQwv6rnUS3s9HBqQB_1ggJHx1-prSYte6q2_nrSH0qfNZUhq1zn1u_D5gMJLRWACBZy9pc3N1ZXI" } } 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": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/565049", "validFrom": "2010-01-01T00:00:00Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } } } application/vc+jwt eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ . eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiRXhhbXBsZURlZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDAwOjAwOjAwWiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoiZGlkOmV4YW1wbGU6ZWJmZWIxZjcxMmViYzZmMWMyNzZlMTJlYzIxIiwiZGVncmVlIjp7InR5cGUiOiJFeGFtcGxlQmFjaGVsb3JEZWdyZWUiLCJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5jZSBhbmQgQXJ0cyJ9fX0 . gI1ZJ_8cYT-BIoMPrrYP0NMR0o-TtQpj6T___g0yKloycMCM_fbvXPj_Lv6dLlZ8XtDXPMS-EkaFL4eX_imh2g application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/565049", "validFrom": "2010-01-01T00:00:00Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } } } application/vc+cose d28443a10128a05901be7b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f756e69766572736974792e6578616d706c652f63726564656e7469616c732f33373332222c2274797065223a5b2256657269666961626c6543726564656e7469616c222c224578616d706c6544656772656543726564656e7469616c225d2c22697373756572223a2268747470733a2f2f756e69766572736974792e6578616d706c652f697373756572732f353635303439222c2276616c696446726f6d223a22323031302d30312d30315430303a30303a30305a222c2263726564656e7469616c5375626a656374223a7b226964223a226469643a6578616d706c653a656266656231663731326562633666316332373665313265633231222c22646567726565223a7b2274797065223a224578616d706c6542616368656c6f72446567726565222c226e616d65223a2242616368656c6f72206f6620536369656e636520616e642041727473227d7d7d5840ca93bff565494c57c9279bc76c367b086398ee3e00f59b33327cff8d411f5e00d6047a2494eb9248ca62fbe4ce4ee281880887ad4268cac3732b0e2ec9daba11 Encoded Decoded Issuer Disclosures eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ . eyJpYXQiOjE3ODg2NDI1NjIsImV4cCI6MTc4OTg1MjE2MiwiX3NkX2FsZyI6InNoYS0yNTYiLCJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDAwOjAwOjAwWiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImRlZ3JlZSI6eyJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5jZSBhbmQgQXJ0cyIsIl9zZCI6WyJTWnZKeFJwTVRtV0pETGh4eWZ5OVQ1NDhrNlQ0akJwOG44LUNiaGI4V0w0Il19LCJfc2QiOlsidlpjU0tPS0taMWxSYVhRaUtkdnlHckJQck9uX1BXSTV3MEZDTXFiWV9VSSJdfSwiX3NkIjpbIjEzajJLUHlTSjctMXJneTNYLVYzZHRGdDRSSGstV1ZWVDBmQTdPd3gybjAiLCJNSWJ0by1MeTVUMnhlQjRKSzNVZkd5OFZiM2k2RHg2MGRzZGFWN0NqX1VRIl19 . gnzH1SGmmnZQTJq9asDcqwWNw6Eka4U2sJR2eTef6JlBGgCej2pGhQf_fcA-AG6Spuvgb_JGmslbvMPCMF3l0g ~ WyJuQkhDdzQtT2xyd3ZqZEd2QkRtakxBIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd ~ WyJpWnhvb0QwRGJFNU9OSUxVTlhVU1NnIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d ~ WyJ3ekd6dC1FOUtvS2xWQ1hPb3lSOUZ3IiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd ~ WyJQLXR3cUk3YnN5M0FaWUtheUIybXpBIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0 ~ { "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro", "alg": "ES256" } { "iat": 1788642562, "exp": 1789852162, "_sd_alg": "sha-256", "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "issuer": "https://university.example/issuers/565049", "validFrom": "2010-01-01T00:00:00Z", "credentialSubject": { "degree": { "name": "Bachelor of Science and Arts", "_sd": [ "SZvJxRpMTmWJDLhxyfy9T548k6T4jBp8n8-Cbhb8WL4" ] }, "_sd": [ "vZcSKOKKZ1lRaXQiKdvyGrBPrOn_PWI5w0FCMqbY_UI" ] }, "_sd": [ "13j2KPySJ7-1rgy3X-V3dtFt4RHk-WVVT0fA7Owx2n0", "MIbto-Ly5T2xeB4JK3UfGy8Vb3i6Dx60dsdaV7Cj_UQ" ] } Claim: id SHA-256 Hash: MIbto-Ly5T2xeB4JK3UfGy8Vb3i6Dx60dsdaV7Cj_UQ Disclosure(s): WyJuQkhDdzQtT2xyd3ZqZEd2QkRtakxBIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd Contents: [ "nBHCw4-OlrwvjdGvBDmjLA", "id", "http://university.example/credentials/3732" ] Claim: type SHA-256 Hash: 13j2KPySJ7-1rgy3X-V3dtFt4RHk-WVVT0fA7Owx2n0 Disclosure(s): WyJpWnhvb0QwRGJFNU9OSUxVTlhVU1NnIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d Contents: [ "iZxooD0DbE5ONILUNXUSSg", "type", [ "VerifiableCredential", "ExampleDegreeCredential" ] ] Claim: id SHA-256 Hash: vZcSKOKKZ1lRaXQiKdvyGrBPrOn_PWI5w0FCMqbY_UI Disclosure(s): WyJ3ekd6dC1FOUtvS2xWQ1hPb3lSOUZ3IiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd Contents: [ "wzGzt-E9KoKlVCXOoyR9Fw", "id", "did:example:ebfeb1f712ebc6f1c276e12ec21" ] Claim: type SHA-256 Hash: SZvJxRpMTmWJDLhxyfy9T548k6T4jBp8n8-Cbhb8WL4 Disclosure(s): WyJQLXR3cUk3YnN5M0FaWUtheUIybXpBIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0 Contents: [ "P-twqI7bsy3AZYKayB2mzA", "type", "ExampleBachelorDegree" ] Expressing information related to multiple subjects in a verifiable credential is possible. The example below specifies two subjects who are spouses. Note the use of array notation to associate multiple subjects with the credentialSubject property. Example 10 : Specifying multiple subjects in a verifiable credential { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": ["VerifiableCredential", "RelationshipCredential"], "issuer": "https://issuer.example/issuer/123", "validFrom": "2010-01-01T00:00:00Z", "credentialSubject": [{ "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "name": "Jayden Doe", "spouse": "did:example:c276e12ec21ebfeb1f712ebc6f1" }, { "id": "https://subject.example/subject/8675", "name": "Morgan Doe", "spouse": "https://subject.example/subject/7421" }] } 4.9 Validity Period This specification defines the validFrom property to help an issuer to express the date and time when a credential becomes valid and the validUntil property to express the date and time when a credential ceases to be valid. When comparing dates and times, the calculation is done "temporally", meaning that the string value is converted to a "temporal value" which exists as a point on a timeline. Temporal comparisons are then performed by checking to see where the date and time being compared are in relation to a particular point on the timeline. validFrom If present, the value of the validFrom property MUST be a [ XMLSCHEMA11-2 ] dateTimeStamp string value representing the date and time the credential becomes valid, which could be a date and time in the future or the past. Note that this value represents the earliest point in time at which the information associated with the credentialSubject property becomes valid. If a validUntil value also exists, the validFrom value MUST express a point in time that is temporally the same or earlier than the point in time expressed by the validUntil value. validUntil If present, the value of the validUntil property MUST be a [ XMLSCHEMA11-2 ] dateTimeStamp string value representing the date and time the credential ceases to be valid, which could be a date and time in the past or the future. Note that this value represents the latest point in time at which the information associated with the credentialSubject property is valid. If a validFrom value also exists, the validUntil value MUST express a point in time that is temporally the same or later than the point in time expressed by the validFrom value. Example 11 : Use of the validFrom and validUntil properties Credential ecdsa ecdsa-sd bbs jose cose sd-jwt { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": ["VerifiableCredential", "ExampleDegreeCredential"], "issuer": "https://university.example/issuers/14", "validFrom": "2010-01-01T19:23:24Z" , "validUntil": "2020-01-01T19:23:24Z" , "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } } } application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/14", "validFrom": "2010-01-01T19:23:24Z", "validUntil": "2020-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "DataIntegrityProof", "created": "2026-09-05T21:09:22Z", "verificationMethod": "did:key:zDnaeqpc578Kg3k9asdXLMhsQSjh8HMPp3ip3miiWZUUhsv9p", "cryptosuite": "ecdsa-rdfc-2019", "proofPurpose": "assertionMethod", "proofValue": "z2dKRP62PT5tXJWmMFwoRwaLirvpM3KQSyezxRrppMWWAyQHQgqSvFQqJrerRp9n1pm6w4bNgRV8KVq7LnMDkFmbo" } } application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/14", "validFrom": "2010-01-01T19:23:24Z", "validUntil": "2020-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "DataIntegrityProof", "created": "2026-09-05T21:09:22Z", "verificationMethod": "did:key:zDnaee6cRuNdNecab7A7cnbb6w5xovYRWxYirEHstya3usouK", "cryptosuite": "ecdsa-sd-2023", "proofPurpose": "assertionMethod", "proofValue": "u2V0AhVhASymzIzRv9itXTEGFOhWeeaRGltN3Q5ZTLerIOIT_YOZnsEiIGhc2_6lxxriLmcUx4vCEqzwLWM7qQL_bu0-y-FgjgCQCd0IBv_dHa_tVxxyByNXUEpchBk6mBfNDpC2cTGbkRphYIPfGlHazfyyvni0ogmkmzbtBeW2ypsWnfeHkpdq7scxshlhA1MRdQ7vZEkIAwHSFrXj88CYxvOhKY_H6tnhkUIqOrZVuYHwkP9N1rQjN3FxE6K5nF98nt-g0Kw0m2LKxs8v771hAVeYeJ8JZ-LsldBa_OBfviMyta3rMzxReE3jwM70P5SkcY3q7DMP6AWdvowGVWe-MhO2t3lG9t6FTV3WY2xYumlhAv_MGxQlKo55okftl6QJCs4G0MC22-7l9DhRk7PTGOXP0EvAtPrtMbQ43iJMDY88JESSiv1IUnu_IH-BUorqye1hACa_36i20pLl8nteRriKsz6JROIWELHPyh9dqACyzZdfObvh2aweK3EXwW2DEs8qe-mAk1JELhuxF6k9fD26mqFhA7W-Mwb15_hIFWh0Dy8KFuF1u-b8AZwrWoVuDOKDPGKfGHnxCKNiKRTg9q7evsaPROjJ3ZtaoEpsQ7JvnqqKNV1hAaaQEbl1S-UYFFOYuoFyMPPj_emQbfBzl-hYEJNKJNW_5Lq_H81O7GJPyA5ajvSqmhKlbjLiZIn9sAxLppCdwp4FnL2lzc3Vlcg" } } application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/14", "validFrom": "2010-01-01T19:23:24Z", "validUntil": "2020-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "DataIntegrityProof", "verificationMethod": "did:key:zUC7JVyoNecN4arDQjjTXVSfyv1V7bwcnMUs6y2BuSeWmzarPohM5DLXAXXxkBRrpjbzZTUdrLaAVoj87nPgXktL3q8JgBvRqqHo9Z88Jfn2tXXM8Q1aTDhNgf1HYL9WEMiULnS", "cryptosuite": "bbs-2023", "proofPurpose": "assertionMethod", "proofValue": "u2V0ChVhQsWlptnesgCHlq0jnOxdSQZ-vBEyCHlufPsK_10HmZUW6p2Tk39-3nPU-D5Wpx5tnCp-pXmZe1oJUTMpZkD1752Q_hJji2VTngfoF5ThcBatYQD3-tli9rF9b1rOCOCaDSL0zj-QnIO3TIaEobJTPayaIKnv3N5iX7nvZR0OCXS-uXH4QQ9mW65QM5qlHOfE4GQVYYLMBLFvXdBPRt0k4kRZk93gc0jkscNQB3wJpCXu4OPkNaVJMlX03jEKZdwQ437AaRg2tSqfzd_pbHzZq9O7FyF1fsAT1tn_tHqFT5wrUWfaGtHJRQwv6rnUS3s9HBqQB_1ggWWL7Q19VWfetyDZL8ZT3MUW20katDynN9Sq9ZLkpglGBZy9pc3N1ZXI" } } 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": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/14", "validFrom": "2010-01-01T19:23:24Z", "validUntil": "2020-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } } } application/vc+jwt eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ . eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiRXhhbXBsZURlZ3JlZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy8xNCIsInZhbGlkRnJvbSI6IjIwMTAtMDEtMDFUMTk6MjM6MjRaIiwidmFsaWRVbnRpbCI6IjIwMjAtMDEtMDFUMTk6MjM6MjRaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiaWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEiLCJkZWdyZWUiOnsidHlwZSI6IkV4YW1wbGVCYWNoZWxvckRlZ3JlZSIsIm5hbWUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIn19fQ . P0eGvUw8ZPWZ0R8rfCy8Cd8hsdx4iMz3ihIAb7phHNKSRS3QMUXpxxz7ELEBkBHqw_dwtFM23IyipurTgL4XLw application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/14", "validFrom": "2010-01-01T19:23:24Z", "validUntil": "2020-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } } } application/vc+cose d28443a10128a05901de7b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f756e69766572736974792e6578616d706c652f63726564656e7469616c732f33373332222c2274797065223a5b2256657269666961626c6543726564656e7469616c222c224578616d706c6544656772656543726564656e7469616c225d2c22697373756572223a2268747470733a2f2f756e69766572736974792e6578616d706c652f697373756572732f3134222c2276616c696446726f6d223a22323031302d30312d30315431393a32333a32345a222c2276616c6964556e74696c223a22323032302d30312d30315431393a32333a32345a222c2263726564656e7469616c5375626a656374223a7b226964223a226469643a6578616d706c653a656266656231663731326562633666316332373665313265633231222c22646567726565223a7b2274797065223a224578616d706c6542616368656c6f72446567726565222c226e616d65223a2242616368656c6f72206f6620536369656e636520616e642041727473227d7d7d5840dc2074e8b3ceafa11bcc227acfa0baadb10ea63363aae60cf0c9e3b11a434cb493e55ddbcccee42110bd865609c10d01050a1aa47ee480aa25425406faec55d4 Encoded Decoded Issuer Disclosures eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ . eyJpYXQiOjE3ODg2NDI1NjIsImV4cCI6MTc4OTg1MjE2MiwiX3NkX2FsZyI6InNoYS0yNTYiLCJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy8xNCIsInZhbGlkRnJvbSI6IjIwMTAtMDEtMDFUMTk6MjM6MjRaIiwidmFsaWRVbnRpbCI6IjIwMjAtMDEtMDFUMTk6MjM6MjRaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiZGVncmVlIjp7Im5hbWUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIiwiX3NkIjpbIlFFTFFaSld5dEY2alI1Y1hOSW1PbjRacGZOSVRnZzE0R05XRTQwbjVYQ1kiXX0sIl9zZCI6WyJKbjZaemZEelNvM3B1dzA2UVBpVGlMZklTU3N0b2RhTG5GRVhtME50YWg0Il19LCJfc2QiOlsiZEw0QlJqQmd4RjQ0ckwxSHBPNHhmYjdXWnZvVFh5UkNlYnQ1S0pMaFFjbyIsImh2al9sUi1QVW1tdkhLYThpeU5lUXp4aERyaTlZNG0xZ2pteGRCOWM2Z2MiXX0 . OCBfZ4_IyoGY5ys0vmwH0KFq3_jAbOZXITlkabbHfg5bJN2XACuEDbHNZI8apUOIyWcyrB8POHOOhl6zgmpKJA ~ WyJ6d2Nfa1RlZEpMdmtHSGdIY1FkTGJnIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd ~ WyJ6MGZXRlR4OUFzazFEX25ZZnNEZFZRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d ~ WyJPcWlCRWRJajZxem1vSld4dHBhUV9nIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd ~ WyJRUmtxVDdKZkwtOXZyMzU3RXNZbF9nIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0 ~ { "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro", "alg": "ES256" } { "iat": 1788642562, "exp": 1789852162, "_sd_alg": "sha-256", "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "issuer": "https://university.example/issuers/14", "validFrom": "2010-01-01T19:23:24Z", "validUntil": "2020-01-01T19:23:24Z", "credentialSubject": { "degree": { "name": "Bachelor of Science and Arts", "_sd": [ "QELQZJWytF6jR5cXNImOn4ZpfNITgg14GNWE40n5XCY" ] }, "_sd": [ "Jn6ZzfDzSo3puw06QPiTiLfISSstodaLnFEXm0Ntah4" ] }, "_sd": [ "dL4BRjBgxF44rL1HpO4xfb7WZvoTXyRCebt5KJLhQco", "hvj_lR-PUmmvHKa8iyNeQzxhDri9Y4m1gjmxdB9c6gc" ] } Claim: id SHA-256 Hash: hvj_lR-PUmmvHKa8iyNeQzxhDri9Y4m1gjmxdB9c6gc Disclosure(s): WyJ6d2Nfa1RlZEpMdmtHSGdIY1FkTGJnIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMzczMiJd Contents: [ "zwc_kTedJLvkGHgHcQdLbg", "id", "http://university.example/credentials/3732" ] Claim: type SHA-256 Hash: dL4BRjBgxF44rL1HpO4xfb7WZvoTXyRCebt5KJLhQco Disclosure(s): WyJ6MGZXRlR4OUFzazFEX25ZZnNEZFZRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d Contents: [ "z0fWFTx9Ask1D_nYfsDdVQ", "type", [ "VerifiableCredential", "ExampleDegreeCredential" ] ] Claim: id SHA-256 Hash: Jn6ZzfDzSo3puw06QPiTiLfISSstodaLnFEXm0Ntah4 Disclosure(s): WyJPcWlCRWRJajZxem1vSld4dHBhUV9nIiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd Contents: [ "OqiBEdIj6qzmoJWxtpaQ_g", "id", "did:example:ebfeb1f712ebc6f1c276e12ec21" ] Claim: type SHA-256 Hash: QELQZJWytF6jR5cXNImOn4ZpfNITgg14GNWE40n5XCY Disclosure(s): WyJRUmtxVDdKZkwtOXZyMzU3RXNZbF9nIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0 Contents: [ "QRkqT7JfL-9vr357EsYl_g", "type", "ExampleBachelorDegree" ] Note : Validity start period for Verifiable Credentials If validFrom and validUntil are not present, the verifiable credential validity period is considered valid indefinitely. In such cases, the verifiable credential is assumed to be valid from the time the verifiable credential was created. 4.10 Status This specification defines the credentialStatus property for discovering information related to the status of a verifiable credential , such as whether it is suspended or revoked. If present, the value associated with the credentialStatus property is a single object or a set of one or more objects. The following properties are defined for every object: id The id property is OPTIONAL . It MAY be used to provide a unique identifier for the credential status object. If present, the normative guidance in Section 4.4 Identifiers MUST be followed. type The type property is REQUIRED . It is used to express the type of status information expressed by the object. The related normative guidance in Section 4.5 Types MUST be followed. The precise content of the credential status information is determined by the specific credentialStatus type definition and varies depending on factors such as whether it is simple to implement or if it is privacy-enhancing. The value will provide enough information to determine the current status of the credential and whether machine-readable information will be retrievable from the URL. For example, the object could contain a link to an external document that notes whether the credential is suspended or revoked. Example 12 : Use of the status property { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": ["VerifiableCredential", "ExampleDegreeCredential"], "issuer": "https://university.example/issuers/14", "validFrom": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } }, "credentialStatus": { "id": "https://university.example/credentials/status/3#94567", "type": "BitstringStatusListEntry", "statusPurpose": "revocation", "statusListIndex": "94567", "statusListCredential": "https://university.example/credentials/status/3" } } A credential can have more than one status associated with it, such as whether it has been revoked or suspended. Example 13 : Use of multiple entries for the status property { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://license.example/credentials/9837", "type": ["VerifiableCredential", "ExampleDrivingLicenseCredential"], "issuer": "https://license.example/issuers/48", "validFrom": "2020-03-14T12:10:42Z", "credentialSubject": { "id": "did:example:f1c276e12ec21ebfeb1f712ebc6", "license": { "type": "ExampleDrivingLicense", "name": "License to Drive a Car" } }, "credentialStatus": [{ "id": "https://license.example/credentials/status/84#14278", "type": "BitstringStatusListEntry", "statusPurpose": "revocation", "statusListIndex": "14278", "statusListCredential": "https://license.example/credentials/status/84" }, { "id": "https://license.example/credentials/status/84#82938", "type": "BitstringStatusListEntry", "statusPurpose": "suspension", "statusListIndex": "82938", "statusListCredential": "https://license.example/credentials/status/84" }] } Implementers are cautioned that credentials with multiple status entries might contain conflicting information. Reconciling such conflicts is a part of the validation process, hence part of the verifier's business logic, and therefore out of scope for this specification. Defining the data model, formats, and protocols for status schemes is out of the scope of this specification. The Verifiable Credential Extensions document contains available status schemes for implementers who want to implement verifiable credential status checking. Credential status specifications MUST NOT enable tracking of individuals, such as an issuer being notified (either directly or indirectly) when a verifier is interested in a specific holder or subject . Unacceptable approaches include "phoning home," such that every use of a credential contacts the issuer of the credential to check the status for a specific individual, or "pseudonymity reduction," such that every use of the credential causes a request for information from the issuer that the issuer can use to deduce verifier interest in a specific individual. 4.11 Data Schemas Data schemas are useful when enforcing a specific structure on a given data collection. There are at least two types of data schemas that this specification considers: Data verification schemas, which are used to establish that the structure and contents of a credential or verifiable credential conform to a published schema. Data encoding schemas, which are used to map the contents of a verifiable credential to an alternative representation format, such as a format used in a zero-knowledge proof. It is important to understand that data schemas serve a different purpose from the @context property, which neither enforces data structure or data syntax nor enables the definition of arbitrary encodings to alternate representation formats. This specification defines the following property for expressing a data schema, which an issuer can include in the verifiable credentials that it issues: credentialSchema The value of the credentialSchema property MUST be one or more data schemas that provide verifiers with enough information to determine whether the provided data conforms to the provided schema(s). Each credentialSchema MUST specify its type (for example, JsonSchema ) and an id property that MUST be a URL identifying the schema file. The specific type definition determines the precise contents of each data schema. If multiple schemas are present, validity is determined according to the processing rules outlined by each associated type property. Note : Credential type-specific syntax checking is possible The credentialSchema property allows one to annotate type definitions or lock them to specific versions of the vocabulary. Authors of verifiable credentials can include a static version of their vocabulary using credentialSchema that is secured by some content integrity protection mechanism. The credentialSchema property also makes it possible to perform syntactic checking on the credential and to use verification mechanisms such as JSON Schema [ VC-JSON-SCHEMA ] validation. Example 14 : Using the credentialSchema property to perform JSON schema validation { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/3732", "type": ["VerifiableCredential", "ExampleDegreeCredential", "ExamplePersonCredential"], "issuer": "https://university.example/issuers/14", "validFrom": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" }, "alumniOf": { "name": "Example University" } }, "credentialSchema": [{ "id": "https://example.org/examples/degree.json", "type": "JsonSchema" }, { "id": "https://example.org/examples/alumni.json", "type": "JsonSchema" }] } In the example above, the issuer is specifying two credentialSchema objects, each of which point to a JSON Schema [ VC-JSON-SCHEMA ] file that a verifier can use to determine whether the verifiable credential is well-formed. 4.12 Securing Mechanisms This specification recognizes two classes of securing mechanisms : those that use enveloping proofs and those that use embedded proofs. An enveloping proof wraps a serialization of this data model. One such RECOMMENDED enveloping proof mechanism is defined in Securing Verifiable Credentials using JOSE and COSE [ VC-JOSE-COSE ]. An embedded proof is a mechanism where the proof is included in the serialization of the data model. One such RECOMMENDED embedded proof mechanism is defined in Verifiable Credential Data Integrity 1.0 [ VC-DATA-INTEGRITY ]. These two classes of securing mechanisms are not mutually exclusive. Additional securing mechanism specifications might also be defined according to the rules in Section 5.13 Securing Mechanism Specifications . Example 15 : A verifiable credential using an embedded proof { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://example.gov/credentials/3732", "type": ["VerifiableCredential", "ExampleDegreeCredential"], "issuer": "did:example:6fb1f712ebe12c27cc26eebfe11", "validFrom": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "https://subject.example/subject/3921", "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "DataIntegrityProof", "cryptosuite": "eddsa-rdfc-2022", "created": "2021-11-13T18:19:39Z", "verificationMethod": "https://university.example/issuers/14#key-1", "proofPurpose": "assertionMethod", "proofValue": "z58DAdFfa9SkqZMVPxAQp...jQCrfFPP2oumHKtz" } } The embedded proof above secures the original credential by decorating the original data with a digital signature via the proof property. This results in a verifiable credential that is easy to manage in modern programming environments and database systems. Example 16 : A verifiable credential that uses an enveloping proof in SD-JWT format eyJhbGciOiJFUzM4NCIsImtpZCI6IkdOV2FBTDJQVlVVMkpJVDg5bTZxMGM3U3ZjNDBTLWJ2UjFTT0 Q3REZCb1UiLCJ0eXAiOiJ2YytsZCtqc29uK3NkLWp3dCIsImN0eSI6InZjK2xkK2pzb24ifQ . eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwcz ovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6 Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLT AxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTY2hlbWEiOnsiX3NkIjpbIlNFOHp4bmduZTNNbWEwLUNm S2dlYW1rNUVqU1NfOXRaNlN5NDdBdTdxRWMiLCJjT3lySEVrSlZwdEtSdURtNkNZVTREajJvRkExd0 JQRjFHcTJnWEo1NXpzIl19LCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsibmFtZSI6IkJh Y2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMiLCJfc2QiOlsibVNfSVBMa0JHcTIxbVA3Z0VRaHhOck E0ZXNMc1ZKQ1E5QUpZNDFLLVRQSSJdfSwiX3NkIjpbIlhTSG9iU05Md01PVl9QNkhQMHNvMnZ1clNy VXZ3UURYREJHQWtyTXk3TjgiXX0sIl9zZCI6WyJQNE5qWHFXa2JOc1NfRzdvdmlLdm1NOG0yckhDTm 5XVVV2SXZBbW9jb2RZIiwieFNvSHBKUXlCNGV1dmg4SkFJdDFCd1pjNFVEOHY5S3ZOTmVLMk9OSjFC QSJdLCJfc2RfYWxnIjoic2hhLTI1NiIsImlzcyI6Imh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL2 lzc3VlcnMvNTY1MDQ5IiwiaWF0IjoxNzAzNjI1OTAxLCJleHAiOjE3MzUyNDgzMDEsImNuZiI6eyJq d2siOnsia3R5IjoiRUMiLCJjcnYiOiJQLTM4NCIsImFsZyI6IkVTMzg0IiwieCI6Inl1Zlo1SFUzcU NfOTRMbkI3Zklzd0hmT0swQlJra0Z5bzVhd1QyX21ld0tJWUpLMVNfR0QySVB3UjRYUTZpdFEiLCJ5 IjoiRmEtV2pOd2NLQ1RWWHVDU2tCY3RkdHJOYzh6bXdBTTZWOWxudmxxd1QyQnRlQ0ZHNmR6ZDJoMF VjeXluTDg0dCJ9fX0 . M7BFJB9LEV_xEylSJpP00fd_4WjrOlXshh0dUv3QgOzw2MEGIfSfi9PoCkHJH7TI0InsqkD6XZVz38 MpeDKekgBW-RoDdJmxnifYOEJhKpJ5EN9PvA007UPi9QCaiEzX ~ WyJFX3F2V09NWVQ1Z3JNTkprOHNXN3BBIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbG UvY3JlZGVudGlhbHMvMTg3MiJd ~ WyJTSEc4WnpfRDVRbFMwU0ZrZFUzNXlRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIi wgIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl1d ~ WyJqZzJLRno5bTFVaGFiUGtIaHV4cXRRIiwgImlkIiwgImh0dHBzOi8vZXhhbXBsZS5vcmcvZXhhbX BsZXMvZGVncmVlLmpzb24iXQ ~ WyItQmhzaE10UnlNNUVFbGt4WGVXVm5nIiwgInR5cGUiLCAiSnNvblNjaGVtYSJd~WyJ0SEFxMEUwN nY2ckRuUlNtSjlSUWRBIiwgImlkIiwgImRpZDpleGFtcGxlOjEyMyJd ~ WyJ1Ynd6bi1kS19tMzRSMGI0SG84QTBBIiwgInR5cGUiLCAiQmFjaGVsb3JEZWdyZWUiXQ The enveloping proof above secures the original credential by encapsulating the original data in a digital signature envelope, resulting in a verifiable credential that can be processed using tooling that understands the SD-JWT format. 4.13 Verifiable Presentations Verifiable presentations MAY be used to aggregate information from multiple verifiable credentials . Verifiable presentations SHOULD be extremely short-lived and bound to a challenge provided by a verifier . Details for accomplishing this depend on the securing mechanism, the transport protocol, and verifier policies. Unless additional requirements are defined by the particular securing mechanism or embedding protocol, a verifier cannot generally assume that the verifiable presentation correlates with the presented verifiable credentials . The default graph of a verifiable presentation is also referred to as the verifiable presentation graph . The following properties are defined for a verifiable presentation : id The id property is optional. It MAY be used to provide a unique identifier for the verifiable presentation . If present, the normative guidance in Section 4.4 Identifiers MUST be followed. type The type property MUST be present. It is used to express the type of verifiable presentation . One value of this property MUST be VerifiablePresentation , but additional types MAY be included. The related normative guidance in Section 4.5 Types MUST be followed. verifiableCredential The verifiableCredential property MAY be present. The value MUST be one or more verifiable credential and/or enveloped verifiable credential objects (the values MUST NOT be non-object values such as numbers, strings, or URLs). These objects are called verifiable credential graphs and MUST express information that is secured using a securing mechanism . See Section 5.12 Verifiable Credential Graphs for further details. holder The verifiable presentation MAY include a holder property . If present, the value MUST be either a URL or an object containing an id property . It is RECOMMENDED that the URL in the holder or its id be one which, if dereferenced, results in a document containing machine-readable information about the holder that can be used to verify the information expressed in the verifiable presentation . If the holder property is absent, information about the holder is obtained either via the securing mechanism or does not pertain to the validation of the verifiable presentation . The example below shows a verifiable presentation : Example 17 : Basic structure of a presentation { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5", "type": ["VerifiablePresentation", "ExamplePresentation"], "verifiableCredential": [{ ... }] } The contents of the verifiableCredential property shown above are verifiable credential graphs , as described by this specification. Enveloped Verifiable Credentials It is possible for a verifiable presentation to include one or more verifiable credentials that have been secured using a securing mechanism that "envelopes" the payload, such as Securing Verifiable Credentials using JOSE and COSE [ VC-JOSE-COSE ]. This can be accomplished by associating the verifiableCredential property with an object that has a type of EnvelopedVerifiableCredential . EnvelopedVerifiableCredential They are used to associate an object containing an enveloped verifiable credential with the verifiableCredential property in a verifiable presentation . The @context property of the object MUST be present and include a context, such as the base context for this specification , that defines at least the id , type , and EnvelopedVerifiableCredential terms as defined by the base context provided by this specification. The id value of the object MUST be a data: URL [ RFC2397 ] that expresses a secured verifiable credential using an enveloping security scheme, such as Securing Verifiable Credentials using JOSE and COSE [ VC-JOSE-COSE ]. The type value of the object MUST be EnvelopedVerifiableCredential . The example below shows a verifiable presentation that contains an enveloped verifiable credential : Example 18 : Basic structure of a presentation { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "type": ["VerifiablePresentation", "ExamplePresentation"], "verifiableCredential": [{ "@context": "https://www.w3.org/ns/credentials/v2", "id": "data:application/vc+sd-jwt,QzVjV...RMjU", "type": "EnvelopedVerifiableCredential" }] } Note : Processing enveloped content as RDF It is possible that an implementer might want to process the object described in this section and the enveloped presentation expressed by the id value in an RDF environment and create linkages between the objects that are relevant to RDF. The desire and mechanisms for doing so are use case dependent and will, thus, be implementation dependent. Enveloped Verifiable Presentations It is possible to express a verifiable presentation that has been secured using a mechanism that "envelops" the payload, such as Securing Verifiable Credentials using JOSE and COSE [ VC-JOSE-COSE ]. This can be accomplished by using an object that has a type of EnvelopedVerifiablePresentation . EnvelopedVerifiablePresentation Used to express an enveloped verifiable presentation . The @context property of the object MUST be present and include a context, such as the base context for this specification , that defines at least the id , type , and EnvelopedVerifiablePresentation terms as defined by the base context provided by this specification. The id value of the object MUST be a data: URL [ RFC2397 ] that expresses a secured verifiable presentation using an enveloping securing mechanism, such as Securing Verifiable Credentials using JOSE and COSE [ VC-JOSE-COSE ]. The type value of the object MUST be EnvelopedVerifiablePresentation . The example below shows an enveloped verifiable presentation : Example 19 : Basic structure of an enveloped verifiable presentation { "@context": "https://www.w3.org/ns/credentials/v2", "id": "data:application/vp+jwt,eyJraWQiO...zhwGfQ", "type": "EnvelopedVerifiablePresentation" } Presentations Using Derived Credentials Some zero-knowledge cryptography schemes might enable holders to indirectly prove they hold claims from a verifiable credential without revealing all claims in that verifiable credential . In these schemes, a verifiable credential might be used to derive presentable data, which is cryptographically asserted such that a verifier can trust the value if they trust the issuer . Some selective disclosure schemes can share a subset of claims derived from a verifiable credential . Note : Presentations using Zero-Knowledge Proofs are possible For an example of a ZKP-style verifiable presentation containing derived data instead of directly embedded verifiable credentials , see Section 5.7 Zero-Knowledge Proofs . Figure 11 A basic claim expressing that Pat is over the age of 21. Presentations Including Holder Claims A holder MAY use the verifiableCredential property in a verifiable presentation to include verifiable credentials from any issuer , including themselves. When the issuer of a verifiable credential is the holder , the claims in that verifiable credential are considered self-asserted . Such self-asserted claims can be secured by the same mechanism that secures the verifiable presentation in which they are included or by any mechanism usable for other verifiable credentials . The subject(s) of these self-asserted claims are not limited, so these claims can include statements about the holder , one of the other included verifiable credentials or even the verifiable presentation in which the self-asserted verifiable credential is included. In each case, the id property is used to identify the specific subject , in the object where the claims about it are made, just as it is done in verifiable credentials that are not self-asserted. A verifiable presentation that includes a self-asserted verifiable credential , which is secured only using the same mechanism as the verifiable presentation , MUST include a holder property . All of the normative requirements defined for verifiable credentials apply to self-asserted verifiable credentials . A verifiable credential in a verifiable presentation is considered self-asserted when the value of the issuer property of the verifiable credential is identical to the value of the holder property of the verifiable presentation . The example below shows a verifiable presentation that embeds a self-asserted verifiable credential that is secured using the same mechanism as the verifiable presentation . Example 20 : A verifiable presentation, secured with an embedded Data Integrity proof, with a self-asserted verifiable credential { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "type": ["VerifiablePresentation", "ExamplePresentation"], "holder": "did:example:12345678", "verifiableCredential": [{ "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "type": ["VerifiableCredential", "ExampleFoodPreferenceCredential"], "issuer": "did:example:12345678", "credentialSubject": { "favoriteCheese": "Gouda" }, { ... } }], "proof": [{ ... }] } The example below shows a verifiable presentation that embeds a self-asserted verifiable credential holding claims about the verifiable presentation . It is secured using the same mechanism as the verifiable presentation . Example 21 : A verifiable presentation, secured with an embedded Data Integrity proof, with a self-asserted verifiable credential about the verifiable presentation { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "type": ["VerifiablePresentation", "ExamplePresentation"], "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" ], "type": ["VerifiableCredential", "ExampleAssertCredential"], "issuer": "did:example:12345678", "credentialSubject": { "id": "urn:uuid:313801ba-24b7-11ee-be02-ff560265cf9b" , "assertion": "This VP is submitted by the subject as evidence of a legal right to drive" }, "proof": { ... } }], "proof": { ... } } 5. Advanced Concepts Building on the concepts introduced in Section 4. Basic Concepts , this section explores more complex topics about verifiable credentials . 5.1 Trust Model This section is non-normative. The verifiable credentials trust model is based on the following expectations: The verifier expects the issuer to verifiably issue the credential that it receives. This can be established by satisfying either of the following: An issuer secures a credential with a securing mechanism which establishes that the issuer generated the credential . In other words, an issuer issues a verifiable credential . A credential is transmitted in a way that clearly establishes that the issuer generated the credential , and that the credential was not tampered with in transit nor storage. This expectation could be weakened, depending on the risk assessment by the verifier . All entities expect the verifiable data registry to be tamper-evident and to be a correct record of which data is controlled by which entities . This is typically achieved by the method of its publication. This could be via a peer-to-peer protocol from a trusted publisher, a publicly accessible and well known web site (with a content hash), a blockchain, etc. When entities publish metadata about themselves, the publication can be integrity-protected by being secured using with the entity's private key. The holder and verifier expect the issuer to stand by claims it makes in credentials about the subject , and to revoke credentials quickly if and when they no longer stand by those claims . The holder might trust the issuer's claims because the holder has a pre-existing trust relationship with the issuer . For example, an employer might provide an employee with an employment verifiable credential , or a government might issue an electronic passport to a citizen. Where no pre-existing trust relationship exists, the holder might have some out-of-band means of determining whether the issuer is qualified to issue the verifiable credential being provided. Note: It is not always necessary for the holder to trust the issuer , since the issued verifiable credential might be an assertion about a subject who is not the holder , or about no-one, and the holder might be willing to relay this information to a verifier without being held accountable for its veracity. The holder expects the credential repository to store credentials securely, to not release credentials to anyone other than the holder (which may subsequently present them to a verifier ), and to not corrupt nor lose credentials while they are in its care. This trust model differentiates itself from other trust models by ensuring the following: The issuer and verifier do not need to know anything about the credential repository . The issuer does not need to know anything about the verifier . How verifiers decide which issuers to trust, and for what data or purposes, is out of scope for this recommendation. Some issuers , such as well-known organizations, might be trusted by many verifiers simply because of their reputation. Some issuers and verifiers might be members of a community in which all members trust each other due to the rules of membership. Some verifiers might trust a specific trust-service provider whose responsibility is to vet issuers and list them in a trust list such as those specified in Electronic Signatures and Infrastructures (ESI); Trusted Lists [ ETSI-TRUST-LISTS ] or the Adobe Approved Trust List . By decoupling the expectations between the issuer and the verifier , a more flexible and dynamic trust model is created, such that market competition and customer choice is increased. For more information about how this trust model interacts with various threat models studied by the Working Group, see the Verifiable Credentials Use Cases [ VC-USE-CASES ]. Note : Trust model differs from the traditional Certificate Authority system The data model detailed in this specification does not imply a transitive trust model, such as that provided by more traditional Certificate Authority trust models. In the Verifiable Credentials Data Model, a verifier either directly trusts or does not trust an issuer . While it is possible to build transitive trust models using the Verifiable Credentials Data Model, implementers are urged to learn about the security weaknesses introduced by broadly delegating trust in the manner adopted by Certificate Authority systems. 5.2 Extensibility One of the goals of the Verifiable Credentials Data Model is to enable permissionless innovation. To achieve this, the data model needs to be extensible in a number of different ways. The data model is required to: Model complex multi-entity relationships through the use of a graph -based data model. Extend the machine-readable vocabularies used to describe information in the data model, without the use of a centralized system for doing so, through the use of Linked Data [ LINKED-DATA ]. Support multiple types of cryptographic proof formats through the use of Securing Verifiable Credentials using JOSE and COSE , Verifiable Credential Data Integrity 1.0 , and a variety of cryptographic suites listed in the Verifiable Credential Extensions document. Provide all of the extensibility mechanisms outlined above in a data format that is popular with software developers and web page authors, and is enabled through the use of JSON-LD 1.1 . This approach to data modeling is often called an open world assumption , meaning that any entity can say anything about any other entity. While this approach seems to conflict with building simple and predictable software systems, balancing extensibility with program correctness is always more challenging with an open world assumption than with closed software systems. The rest of this section describes, through a series of examples, how both extensibility and program correctness are achieved. Let us assume we start with the credential shown below. Example 22 : A simple credential Credential ecdsa ecdsa-sd bbs jose cose sd-jwt { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://vc.example/credentials/4643", "type": ["VerifiableCredential"], "issuer": "https://issuer.example/issuers/14", "validFrom": "2018-02-24T05:28:04Z", "credentialSubject": { "id": "did:example:abcdef1234567", "name": "Jane Doe" } } application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://vc.example/credentials/4643", "type": [ "VerifiableCredential" ], "issuer": "https://issuer.example/issuers/14", "validFrom": "2018-02-24T05:28:04Z", "credentialSubject": { "id": "did:example:abcdef1234567", "name": "Jane Doe" }, "proof": { "type": "DataIntegrityProof", "created": "2026-09-05T21:09:22Z", "verificationMethod": "did:key:zDnaeqpc578Kg3k9asdXLMhsQSjh8HMPp3ip3miiWZUUhsv9p", "cryptosuite": "ecdsa-rdfc-2019", "proofPurpose": "assertionMethod", "proofValue": "z5mx4F9Y7WG1nmgGbK5TopTBNKcL4A8J8TgiGHeXza97wX9zdJ9xJ93CigVrphjDEQ51bfhxqPQ33EtXWYr7EecWj" } } application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://vc.example/credentials/4643", "type": [ "VerifiableCredential" ], "issuer": "https://issuer.example/issuers/14", "validFrom": "2018-02-24T05:28:04Z", "credentialSubject": { "id": "did:example:abcdef1234567", "name": "Jane Doe" }, "proof": { "type": "DataIntegrityProof", "created": "2026-09-05T21:09:22Z", "verificationMethod": "did:key:zDnaee6cRuNdNecab7A7cnbb6w5xovYRWxYirEHstya3usouK", "cryptosuite": "ecdsa-sd-2023", "proofPurpose": "assertionMethod", "proofValue": "u2V0AhVhA0epbCBiyDPEBAQQ1IHFCIE633o_K7xydvHttIvF3PtFn2mViOGJlQ0osR1jmpi9cIrCfZl3bJeDHfoIUcF6tblgjgCQCzqqR3uH2EvrfOSsJq9odItJMe0iR_DCfsIYsHb4tGD1YICsgD7onOuwT9a1NgaBBOSUgRX3VP2nVRkW_EHM6pj20g1hAxPG_57XTKS_9A2tR-54A2e9cqUO18ejFLCM_HSse-7mIqd4RLar8W2f8nzOITjmxO0qrI8y1Yev6pj9ZkJxgbFhAlgMHonBHyUZ_vTLGYpvJrS5jT8vXWVh_1o8QJAA_FtSbGW8OYzHByVx-HMHB-OXn_p04Q8kqYHJuIsTZH9luClhAETNZX6bZbLsrw0TXJcrzEos82xjTtsGnOXdvkE1D6K_VugqBmpCp_-Vz6PFX51QTNoNWJpQ3i31vglYItJUuzIFnL2lzc3Vlcg" } } application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://vc.example/credentials/4643", "type": [ "VerifiableCredential" ], "issuer": "https://issuer.example/issuers/14", "validFrom": "2018-02-24T05:28:04Z", "credentialSubject": { "id": "did:example:abcdef1234567", "name": "Jane Doe" }, "proof": { "type": "DataIntegrityProof", "verificationMethod": "did:key:zUC7JVyoNecN4arDQjjTXVSfyv1V7bwcnMUs6y2BuSeWmzarPohM5DLXAXXxkBRrpjbzZTUdrLaAVoj87nPgXktL3q8JgBvRqqHo9Z88Jfn2tXXM8Q1aTDhNgf1HYL9WEMiULnS", "cryptosuite": "bbs-2023", "proofPurpose": "assertionMethod", "proofValue": "u2V0ChVhQuPNRxOKzfW4tOd3sW1EYWCAn358k_ZgDQlVpuccDuH-mIbBq0ieUvz1iIp3FfD44LmF-bMoUiZbgCOPYoNPx6kGUXdWV3307b74FbilbhTRYQD3-tli9rF9b1rOCOCaDSL0zj-QnIO3TIaEobJTPayaIvqENcCm8D2khyMGr7-FGFdx818_ufbFmo8hKn_2FgMpYYLMBLFvXdBPRt0k4kRZk93gc0jkscNQB3wJpCXu4OPkNaVJMlX03jEKZdwQ437AaRg2tSqfzd_pbHzZq9O7FyF1fsAT1tn_tHqFT5wrUWfaGtHJRQwv6rnUS3s9HBqQB_1ggpBh8waxBO_P219SajAnhJIWtWDtOZv1biUSq0-rjucqBZy9pc3N1ZXI" } } 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": "http://vc.example/credentials/4643", "type": [ "VerifiableCredential" ], "issuer": "https://issuer.example/issuers/14", "validFrom": "2018-02-24T05:28:04Z", "credentialSubject": { "id": "did:example:abcdef1234567", "name": "Jane Doe" } } application/vc+jwt eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ . eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdmMuZXhhbXBsZS9jcmVkZW50aWFscy80NjQzIiwidHlwZSI6WyJWZXJpZmlhYmxlQ3JlZGVudGlhbCJdLCJpc3N1ZXIiOiJodHRwczovL2lzc3Vlci5leGFtcGxlL2lzc3VlcnMvMTQiLCJ2YWxpZEZyb20iOiIyMDE4LTAyLTI0VDA1OjI4OjA0WiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoiZGlkOmV4YW1wbGU6YWJjZGVmMTIzNDU2NyIsIm5hbWUiOiJKYW5lIERvZSJ9fQ . 4O_WD8pixiViES-KJp7YneIXyAAEgoMiR9uxwv5racS95IgU7hCKLxw1P8p7lxL9g-4biNfwWoLPGN-iVQUzag application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://vc.example/credentials/4643", "type": [ "VerifiableCredential" ], "issuer": "https://issuer.example/issuers/14", "validFrom": "2018-02-24T05:28:04Z", "credentialSubject": { "id": "did:example:abcdef1234567", "name": "Jane Doe" } } application/vc+cose d28443a10128a05901487b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f76632e6578616d706c652f63726564656e7469616c732f34363433222c2274797065223a5b2256657269666961626c6543726564656e7469616c225d2c22697373756572223a2268747470733a2f2f6973737565722e6578616d706c652f697373756572732f3134222c2276616c696446726f6d223a22323031382d30322d32345430353a32383a30345a222c2263726564656e7469616c5375626a656374223a7b226964223a226469643a6578616d706c653a61626364656631323334353637222c226e616d65223a224a616e6520446f65227d7d584088974b020902b94f8811455bfc2c60616884ab774a30058b7e3c482994bab04472b9925282b4dddabd88b1dacd891ce0aab36708e238a88d0b34f35d80d25d6a Encoded Decoded Issuer Disclosures eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ . eyJpYXQiOjE3ODg2NDI1NjIsImV4cCI6MTc4OTg1MjE2MiwiX3NkX2FsZyI6InNoYS0yNTYiLCJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6Ly9pc3N1ZXIuZXhhbXBsZS9pc3N1ZXJzLzE0IiwidmFsaWRGcm9tIjoiMjAxOC0wMi0yNFQwNToyODowNFoiLCJjcmVkZW50aWFsU3ViamVjdCI6eyJuYW1lIjoiSmFuZSBEb2UiLCJfc2QiOlsiLXdlZHBXUXU1eVVGRkM3Zmx3a1BwdXFqcGdXZ3dRUm4zcDNEZ3I3RmhrOCJdfSwiX3NkIjpbImZDNDlmR1RFWDZTXzhXZlA4dE5zdlRXOXlDMjgtRG45R0VzZm9Cd0pyQUUiLCJqbXlhUUY2bWpxYTJDSEhoQzlnZVdoUGNEd29meDJmSVNhN3FSZ2xPdW5RIl19 . WMsjxjzve6__Mw4N79W7Kq5S4hxaBp4x9mOrKEC7FBs_HtJVtsL63g34cxyTaaErzaVd6plYzy7spGnfVShOIQ ~ WyJXRUtWUzBPQmt2TkJaVTdnLXNkNFRRIiwgImlkIiwgImh0dHA6Ly92Yy5leGFtcGxlL2NyZWRlbnRpYWxzLzQ2NDMiXQ ~ WyJ1VnZsTzBfMjBnN0lpOVd0MDdReVBRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIl1d ~ WyJNaEhSbFlrR3JiNkw2V2dWSGM0YjJRIiwgImlkIiwgImRpZDpleGFtcGxlOmFiY2RlZjEyMzQ1NjciXQ ~ { "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro", "alg": "ES256" } { "iat": 1788642562, "exp": 1789852162, "_sd_alg": "sha-256", "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "issuer": "https://issuer.example/issuers/14", "validFrom": "2018-02-24T05:28:04Z", "credentialSubject": { "name": "Jane Doe", "_sd": [ "-wedpWQu5yUFFC7flwkPpuqjpgWgwQRn3p3Dgr7Fhk8" ] }, "_sd": [ "fC49fGTEX6S_8WfP8tNsvTW9yC28-Dn9GEsfoBwJrAE", "jmyaQF6mjqa2CHHhC9geWhPcDwofx2fISa7qRglOunQ" ] } Claim: id SHA-256 Hash: jmyaQF6mjqa2CHHhC9geWhPcDwofx2fISa7qRglOunQ Disclosure(s): WyJXRUtWUzBPQmt2TkJaVTdnLXNkNFRRIiwgImlkIiwgImh0dHA6Ly92Yy5leGFtcGxlL2NyZWRlbnRpYWxzLzQ2NDMiXQ Contents: [ "WEKVS0OBkvNBZU7g-sd4TQ", "id", "http://vc.example/credentials/4643" ] Claim: type SHA-256 Hash: fC49fGTEX6S_8WfP8tNsvTW9yC28-Dn9GEsfoBwJrAE Disclosure(s): WyJ1VnZsTzBfMjBnN0lpOVd0MDdReVBRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIl1d Contents: [ "uVvlO0_20g7Ii9Wt07QyPQ", "type", [ "VerifiableCredential" ] ] Claim: id SHA-256 Hash: -wedpWQu5yUFFC7flwkPpuqjpgWgwQRn3p3Dgr7Fhk8 Disclosure(s): WyJNaEhSbFlrR3JiNkw2V2dWSGM0YjJRIiwgImlkIiwgImRpZDpleGFtcGxlOmFiY2RlZjEyMzQ1NjciXQ Contents: [ "MhHRlYkGrb6L6WgVHc4b2Q", "id", "did:example:abcdef1234567" ] This verifiable credential states that the entity associated with did:example:abcdef1234567 has a name with a value of Jane Doe . Now let us assume a developer wants to extend the verifiable credential to store two additional pieces of information: an internal corporate reference number, and Jane's favorite food. The first thing to do is to create a JSON-LD context containing two new terms, as shown below. Example 23 : A JSON-LD context { "@context": { "referenceNumber": "https://extension.example/vocab#referenceNumber", "favoriteFood": "https://extension.example/vocab#favoriteFood" } } After this JSON-LD context is created, the developer publishes it somewhere so it is accessible to verifiers who will be processing the verifiable credential . Assuming the above JSON-LD context is published at https://extension.example/my-contexts/v1 , we can extend this example by including the context and adding the new properties and credential type to the verifiable credential . Example 24 : A verifiable credential with a custom extension { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2", "https://extension.example/my-contexts/v1" ], "id": "http://vc.example/credentials/4643", "type": ["VerifiableCredential", "CustomExt12"], "issuer": "https://issuer.example/issuers/14", "validFrom": "2018-02-24T05:28:04Z", "referenceNumber": 83294847, "credentialSubject": { "id": "did:example:abcdef1234567", "name": "Jane Doe", "favoriteFood": "Papaya" } } This example demonstrates extending the Verifiable Credentials Data Model in a permissionless and decentralized way. The mechanism shown also ensures that verifiable credentials created in this way provide a way to prevent namespace conflicts and semantic ambiguity. A dynamic extensibility model such as this does increase the implementation burden. Software written for such a system has to determine whether verifiable credentials with extensions are acceptable based on the risk profile of the application. Some applications might accept only certain extensions while highly secure environments might not accept any extensions. These decisions are up to the developers of these applications and are specifically not the domain of this specification. Extension specification authors are urged to ensure that their documents, such as JSON-LD Contexts, are highly available. Developers using these documents might use software that produces errors when these documents cannot be retrieved. Strategies for ensuring that extension JSON-LD contexts are always available include bundling these documents with implementations, content distribution networks with long caching timeframes, or using content-addressed URLs for contexts. These approaches are covered in further detail in Appendix C. Contexts, Vocabularies, Types, and Credential Schemas . Implementers are advised to pay close attention to the extension points in this specification, such as in Sections 4.10 Status , 4.11 Data Schemas , 4.12 Securing Mechanisms , 5.4 Refreshing , 5.5 Terms of Use , and 5.6 Evidence . While this specification does not define concrete implementations for those extension points, the Verifiable Credential Extensions document provides an unofficial, curated list of extensions that developers can use from these extension points. Semantic Interoperability When defining new terms in an application-specific vocabulary, vocabulary authors SHOULD follow the detailed checklist in Best Practices for Publishing Linked Data . Specifically, the following guidance is of particular importance: Whenever possible, it is RECOMMENDED to re-use terms — and their corresponding URLs — defined by well-known, public vocabularies, such as Schema.org . New terms MUST define a new URL for each term. When doing so, the general guidelines for [ LINKED-DATA ] are expected to be followed, in particular: Human-readable documentation MUST be published, describing the semantics of and the constraints on the use of each term. It is RECOMMENDED to also publish the collection of all new terms as a machine-readable vocabulary using RDF Schema 1.1 . It SHOULD be possible to dereference the URL of a term, resulting in its description and/or formal definition. Furthermore, a machine-readable description (that is, a JSON-LD Context document ) MUST be published at the URL specified in the @context property for the vocabulary. This context MUST map each term to its corresponding URL, possibly accompanied by further constraints like the type of the property value. A human-readable document describing the expected order of values for the @context property is also expected to be published by any implementer seeking interoperability. Note : Term redefinition is not allowed When processing the active context defined by the base JSON-LD Context document defined in this specification , compliant JSON-LD-based processors produce an error when a JSON-LD context redefines any term. The only way to change the definition of existing terms is to introduce a new term that clears the active context within the scope of that new term. Authors that are interested in this feature should read about the @protected keyword in the JSON-LD 1.1 specification. A conforming document SHOULD NOT use the @vocab feature in production as it can lead to JSON term clashes, resulting in semantic ambiguities with other applications. Instead, to achieve proper interoperability, a conforming document SHOULD use JSON-LD Contexts that define all terms used by their applications, as described earlier in Section 5.2 Extensibility . If a conforming document does not use JSON-LD Contexts that define all terms used, it MUST include the https://www.w3.org/ns/credentials/undefined-terms/v2 as the last value in the @context property. 5.3 Integrity of Related Resources When including a link to an external resource in a verifiable credential , it is desirable to know whether the resource has been modified since the verifiable credential was issued. This applies to cases where there is an external resource that is remotely retrieved, as well as to cases where the issuer and/or verifier might have locally cached copies of a resource. It can also be desirable to know that the contents of the JSON-LD context(s) used in the verifiable credential are the same when used by the verifier as they were when used by the issuer . To extend integrity protection to a related resource, an issuer of a verifiable credential MAY include the relatedResource property: relatedResource The value of the relatedResource property MUST be one or more objects of the following form: Property Description id The identifier for the resource is REQUIRED and conforms to the format defined in Section 4.4 Identifiers . The value MUST be unique among the list of related resource objects. mediaType An OPTIONAL valid media type as listed in the IANA Media Types registry. digestSRI One or more cryptographic digests, as defined by the hash-expression ABNF grammar defined in the Subresource Integrity specification, Section 3.5: The integrity attribute . digestMultibase One or more cryptographic digests, as defined by the digestMultibase property in the Verifiable Credential Data Integrity 1.0 specification, Section 2.6: Resource Integrity . Each object associated with relatedResource MUST contain at least a digestSRI or a digestMultibase value. If a mediaType is listed, implementations that retrieve the resource identified by the id property using HTTP Semantics SHOULD : use the media type in the Accept HTTP Header, and reject the response if it includes a Content-Type HTTP Header with a different media type. Any object in the verifiable credential that contains an id property MAY be annotated with integrity information by adding either the digestSRI or digestMultibase property, either of which MAY be accompanied by the additionally optional mediaType property. Any objects for which selective disclosure or unlinkable disclosure is desired SHOULD NOT be included as an object in the relatedResource array. A conforming verifier implementation that makes use of a resource based on the id of a relatedResource object inside a conforming document with a corresponding cryptographic digest appearing in a relatedResource object value MUST compute the digest of the retrieved resource. If the digest provided by the issuer does not match the digest computed for the retrieved resource, the conforming verifier implementation MUST produce an error. Implementers are urged to consult appropriate sources, such as the FIPS 180-4 Secure Hash Standard and the Commercial National Security Algorithm Suite 2.0 to ensure that they are choosing a current and reliable hash algorithm. At the time of this writing sha384 SHOULD be considered the minimum strength hash algorithm for use by implementers. An example of a related resource integrity object referencing JSON-LD contexts. Example 25 : Use of the digestSRI property (base64-encoded SHA2-384) "relatedResource": [{ "id": "https://www.w3.org/ns/credentials/v2", "digestSRI": " sha384-l/HrjlBCNWyAX91hr6LFV2Y3heB5Tcr6IeE4/Tje8YyzYBM8IhqjHWiWpr8+ZbYU " },{ "id": "https://www.w3.org/ns/credentials/examples/v2", "digestSRI": " sha384-zNNbQTWCSUSi0bbz7dbua+RcENv7C6FvlmYJ1Y+I727HsPOHdzwELMYO9Mz68M26 " }] Example 26 : Use of the digestMultibase property (base64-url-nopad-encoded SHA2-256) "relatedResource": [{ "id": "https://www.w3.org/ns/credentials/v2", "digestMultibase": " uEiBZlVztZpfWHgPyslVv6-UwirFoQoRvW1htfx963sknNA " },{ "id": "https://www.w3.org/ns/credentials/examples/v2", "digestMultibase": " uEiBXOT-8adbvubm13Jy2uYgLCUQ2Cr_i6vRZyeWM8iedfA " }] 5.4 Refreshing It is useful for systems to enable the manual or automatic refresh of an expired verifiable credential . For more information about validity periods for verifiable credentials , see Section B.7 Validity Periods . This specification defines a refreshService property , which enables an issuer to include a link to a refresh service. The issuer can include the refresh service as an element inside the verifiable credential if it is intended for either the verifier or the holder (or both), or inside the verifiable presentation if it is intended for the holder only. In the latter case, this enables the holder to refresh the verifiable credential before creating a verifiable presentation to share with a verifier . In the former case, including the refresh service inside the verifiable credential enables either the holder or the verifier to perform future updates of the credential . The refresh service is only expected to be used when either the credential has expired or the issuer does not publish credential status information. Issuers are advised not to put the refreshService property in a verifiable credential that does not contain public information or whose refresh service is not protected in some way. refreshService The value of the refreshService property MUST be one or more refresh services that provides enough information to the recipient's software such that the recipient can refresh the verifiable credential . Each refreshService value MUST specify its type . The precise content of each refresh service is determined by the specific refreshService type definition. Example 27 : Use of the refreshService property by an issuer { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://w3id.org/age/v1" ], "type": ["VerifiableCredential", "AgeVerificationCredential"], "issuer": "did:key:z6MksFxi8wnHkNq4zgEskSZF45SuWQ4HndWSAVYRRGe9qDks", "validFrom": "2024-04-03T00:00:00.000Z", "validUntil": "2024-12-15T00:00:00.000Z", "name": "Age Verification Credential", "credentialSubject": { "overAge": 21 }, "refreshService": { "type": "VerifiableCredentialRefreshService2021", "url": "https://registration.provider.example/flows/reissue-age-token", "refreshToken": "z2BJYfNtmWRiouWhDrbDQmC2zicUPBxsPg" } } In the example above, the issuer specifies an automatic refreshService that can be used by POSTing the verifiable credential to the refresh service url . Note that this particular verifiable credential is not intended to be shared with anyone except for the original issuer. Note : Non-authenticated credential refresh Placing a refreshService property in a verifiable credential so that it is available to verifiers can remove control and consent from the holder and allow the verifiable credential to be issued directly to the verifier , thereby bypassing the holder . 5.5 Terms of Use Terms of use can be used by an issuer or a holder to communicate the terms under which a verifiable credential or verifiable presentation was issued. The issuer places their terms of use inside the verifiable credential . The holder places their terms of use inside a verifiable presentation . This specification defines a termsOfUse property for expressing terms of use information. The value of the termsOfUse property might be used to tell the verifier any or all of the following, among other things: the procedures or policies that were used in issuing the verifiable credential , by providing, for example, a pointer to a public location (to avoid "phone home" privacy issues) where these procedures or policies can be found, or the name of the standard that defines them the rules and policies of the issuer that apply to the presentation of this verifiable credential to a verifier , by providing, for example, a pointer to a public location (to avoid "phone home" privacy issues) where these rules or policies can be found the identity of the entity under whose authority the issuer issued this particular verifiable credential termsOfUse The value of the termsOfUse property MUST specify one or more terms of use policies under which the creator issued the credential or presentation . If the recipient (a holder or verifier ) is not willing to adhere to the specified terms of use, then they do so on their own responsibility and might incur legal liability if they violate the stated terms of use. Each termsOfUse value MUST specify its type , for example, TrustFrameworkPolicy , and MAY specify its instance id . The precise contents of each term of use is determined by the specific termsOfUse type definition. Example 28 : Use of the termsOfUse property by an issuer { { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/undefined-terms/v2" ], "id": "urn:uuid:08e26d22-8dca-4558-9c14-6e7aa7275b9b", "type": [ "VerifiableCredential", "VerifiableAttestation", "VerifiableTrustModel", "VerifiableAuthorisationForTrustChain" ], "issuer": "did:ebsi:zZeKyEJfUTGwajhNyNX928z", "validFrom": "2021-11-01T00:00:00Z", "validUntil": "2024-06-22T14:11:44Z", "credentialSubject": { "id": "did:ebsi:zvHWX359A3CvfJnCYaAiAde", "reservedAttributeId": "60ae46e4fe9adffe0bc83c5e5be825aafe6b5246676398cd1ac36b8999e088a8", "permissionFor": [{ "schemaId": "https://api-test.ebsi.eu/trusted-schemas-registry/v3/schemas/zHgbyz9ajVuSProgyMhsiwpcp8g8aVLFRNARm51yyYZp6", "types": [ "VerifiableCredential", "VerifiableAttestation", "WorkCertificate" ], "jurisdiction": "https://publications.europa.eu/resource/authority/atu/EUR" }] }, "termsOfUse": { "type": "TrustFrameworkPolicy", "trustFramework": "Employment&Life", "policyId": "https://policy.example/policies/125", "legalBasis": "professional qualifications directive" } , "credentialStatus": { "id": "https://api-test.ebsi.eu/trusted-issuers-registry/v5/issuers/did:ebsi:zvHWX359A3CvfJnCYaAiAde/attributes/60ae46e4fe9adffe0bc83c5e5be825aafe6b5246676398cd1ac36b8999e088a8", "type": "EbsiAccreditationEntry" }, "credentialSchema": { "id": "https://api-test.ebsi.eu/trusted-schemas-registry/v3/schemas/zCSHSDwrkkd32eNjQsMCc1h8cnFaxyTXP5ByozyVQXZoH", "type": "JsonSchema" } } } In the example above, the issuer is asserting that the legal basis under which the verifiable credential has been issued is the "professional qualifications directive" using the "Employment&Life" trust framework, with a specific link to the policy. This feature is expected to be used by government-issued verifiable credentials to instruct digital wallets to limit their use to similar government organizations in an attempt to protect citizens from unexpected use of sensitive data. Similarly, some verifiable credentials issued by private industry are expected to limit use to within departments inside the organization, or during business hours. Implementers are urged to read more about this evolving feature in the appropriate section of the Verifiable Credentials Implementation Guidelines [ VC-IMP-GUIDE ] document. 5.6 Evidence Evidence can be included by an issuer to provide the verifier with additional supporting information in a verifiable credential . This could be used by the verifier to establish the confidence with which it relies on the claims in the verifiable credential . For example, an issuer could check physical documentation provided by the subject or perform a set of background checks before issuing the credential . In certain scenarios, this information is useful to the verifier when determining the risk associated with relying on a given credential . This specification defines the evidence property for expressing evidence information. evidence If present, the value of the evidence property MUST be either a single object or a set of one or more objects. The following properties are defined for every evidence object: id The id property is OPTIONAL . It MAY be used to provide a unique identifier for the evidence object. If present, the normative guidance in Section 4.4 Identifiers MUST be followed. type The type property is REQUIRED . It is used to express the type of evidence information expressed by the object. The related normative guidance in Section 4.5 Types MUST be followed. Note : See Implementation Guide for strategies for providing evidence For information about how attachments and references to credentials and non-credential data might be supported by the specification, see Section 5.3 Integrity of Related Resources . Example 29 : Example of evidence supporting a skill achievement credential { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json" ], "id": "http://1edtech.edu/credentials/3732", "type": [ "VerifiableCredential", "OpenBadgeCredential" ], "issuer": { "id": "https://1edtech.edu/issuers/565049", "type": "Profile" }, "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "type": "AchievementSubject", "name": "Alice Smith", "activityEndDate": "2023-12-02T00:00:00Z", "activityStartDate": "2023-12-01T00:00:00Z", "awardedDate": "2024-01-01T00:00:00Z", "achievement": [{ "id": "urn:uuid:d46e8ef1-c647-419b-be18-5e045d1c4e64", "type": ["Achievement"], "name": "Basic Barista Training", "criteria": { "narrative": "Team members are nominated for this badge by their supervisors, after passing the Basic Barista Training course." }, "description": "This achievement certifies that the bearer is proficient in basic barista skills." }] }, "evidence": [{ // url to an externally hosted evidence file/artifact "id": "https://videos.example/training/alice-espresso.mp4", "type": ["Evidence"], "name": "Talk-aloud video of double espresso preparation", "description": "This is a talk-aloud video of Alice demonstrating preparation of a double espresso drink.", // digest hash of the mp4 video file "digestMultibase": "uELq9FnJ5YLa5iAszyJ518bXcnlc5P7xp1u-5uJRDYKvc" } ] } In the evidence example above, the issuer is asserting that they have video of the subject of the credential demonstrating the achievement. Note : Evidence has a different purpose from securing mechanisms The evidence property provides information that is different from and information to the securing mechanism used. The evidence property is used to express supporting information, such as documentary evidence, related to the verifiable credential . In contrast, the securing mechanism is used to express machine-verifiable mathematical proofs related to the authenticity of the issuer and integrity of the verifiable credential . For more information about securing mechanisms, see Section 4.12 Securing Mechanisms . 5.7 Zero-Knowledge Proofs Zero-knowledge proofs are securing mechanisms which enable a holder to prove that they hold a verifiable credential containing a value without disclosing the actual value such as being able to prove that an individual is over the age of 25 without revealing their birthday. This data model supports being secured using zero-knowledge proofs. Some capabilities that are compatible with verifiable credentials which are made possible by zero-knowledge proof mechanisms include: Selective disclosure of the properties in a verifiable credential by the holder to a verifier . This allows a holder to provide a verifier with precisely the information they need and nothing more. This also enables the production of a derived verifiable credential that is formatted according to the verifier's data schema without needing to involve the issuer during presentation. This provides a great deal of flexibility for holders to use their issued verifiable credentials . Unlinkable disclosure of the properties in a verifiable credential by the holder to a verifier . Blinded signatures allow for unlinkable disclosure , which remove a common source of holder correlation during multiple presentations to one or more verifiers . This allows a holder to share a different signature value with each presentation, which in turn reduces the amount of data shared. Non-correlatable identification of the holder and/or subject . This allows a holder to prove that a credential was issued to them, or a subject to prove that a credential was issued about them, without sharing a correlatable identifier. This also reduces the amount of data necessary to be shared. This capability can also be used to combine multiple verifiable credentials from multiple issuers into a single verifiable presentation without revealing verifiable credential or subject identifiers to the verifier . Specification authors that create securing mechanisms MUST NOT design them in such a way that they leak information that would enable the verifier to correlate a holder across multiple verifiable presentations to different verifiers . Not all capabilities are supported in all zero-knowledge proof mechanisms. Specific details about the capabilities and techniques provided by a particular zero knowledge proof mechanism, along with any normative requirements for using them with verifiable credentials , would be found in a specification for securing verifiable credentials with that zero-knowledge proof mechanism. For an example of such a specification, refer to the Data Integrity BBS Cryptosuites v1.0 . We note that in most instances, for the holder to make use of zero knowledge mechanisms with verifiable credentials , the issuer is required to secure the verifiable credential in a manner that supports these capabilities. The diagram below highlights how the data model might be used to issue and present verifiable credentials in zero-knowledge. Figure 12 A visual example of the relationship between credentials and derived credentials in a ZKP presentation . An example of a verifiable credential and a verifiable presentation using the Data Integrity BBS Cryptosuites v1.0 unlinkable selective disclosure securing mechanism is shown below. Example 30 : Verifiable credential using the Data Integrity BBS Cryptosuite with a Base Proof { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://w3id.org/citizenship/v4rc1" ], "type": [ "VerifiableCredential", "PermanentResidentCardCredential" ], "issuer": { "id": "did:web:utopia.example", "image": "data:image/png;base64,iVBORw0KGg...VORK5CYII=" }, "name": "Permanent Resident Card", "description": "Government of Utopia Permanent Resident Card.", "credentialSubject": { "type": [ "PermanentResident", "Person" ], "givenName": "JANE", "familyName": "SMITH", "gender": "Female", "image": "data:image/png;base64,iVBORw0KGgo...g==", "residentSince": "2015-01-01", "commuterClassification": "C1", "birthCountry": "Arcadia", "birthDate": "1978-07-17", "permanentResidentCard": { "type": [ "PermanentResidentCard" ], "identifier": "83627465", "lprCategory": "C09", "lprNumber": "999-999-999" } }, "validFrom": "2026-09-05T00:00:00Z", "validUntil": "2027-09-05T23:59:59Z", "proof": [ { "type": "DataIntegrityProof", "created": "2026-09-05T17:21:31Z", "verificationMethod": "did:web:utopia.example#zDnae...QGW8", "cryptosuite": "ecdsa-rdfc-2019", "proofPurpose": "assertionMethod", "proofValue": "z4fJttfr...kn9P" }, { "type": "DataIntegrityProof", "verificationMethod": "did:web:utopia.example#zUC7EwMqo9vCjFmj7ArU2SivcbeccAY6hd4nw5fVD6xD4W2vm9eVy6VqVnciAZRmPLXnuxuka5JTJVmgz66CxDno6eqZmvUViCckCcKg8A4s1R4i2JjyzrdTQs5zrfY4jJCHFCp", "cryptosuite": "bbs-2023", "proofPurpose": "assertionMethod", "proofValue": "u2V0ChVhQiJsvokWSE4Cq999Bw9aluhWuToMG7qGNtAx5I2_LmNjRPCMcTLoiBc_HV8gjvgvSNnrFNK50Ubf1gIN8i8sHUWwUzqdDMevqlO8qVOWgki1YQM6iv5KVLQKPLTMEAHhSEWyz3z3hrSSQJTjO8vIFJgMWaLnxEOgYUkAwn3mL9Hhr-t6oc0OXaYjMBPYyPIQUnwdYYKipusluRJ7SzUrZmv4RxeebXFP1W0GGgnhEIBufF7eulvisZDSTSVWCkn1KMnStOgmhPPjOCIDvXVY2Xxbm61KFgc2pSZJwhV5kLxZV9igRbX8uzqgdbnLyerjY7DzJdVggryiDkfzraDE3VOas9Ls5wKk4oBfAtvO0QZikpLOL1VeBZy9pc3N1ZXI" } ] } The example above is a verifiable credential where the issuer has enabled a BBS-based unlinkable disclosure scheme to create a base proof that can then be used by the holder to create a derived proof that reveals only particular pieces of information from the original verifiable credential . Example 31 : Verifiable presentation using the Data Integrity BBS Cryptosuite with a derived credential and proof { "@context": [ "https://www.w3.org/ns/credentials/v2" ], "type": [ "VerifiablePresentation" ], "verifiableCredential": [ { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://w3id.org/citizenship/v4rc1" ], "type": [ "VerifiableCredential", "PermanentResidentCardCredential" ], "issuer": { "id": "did:web:vcplayground.org", "image": "data:image/png;base64,iVBORw0KG...YII=" }, "credentialSubject": { "type": [ "PermanentResident", "Person" ], "birthCountry": "Arcadia" }, "proof": [ { "type": "DataIntegrityProof", "verificationMethod": "did:web:utopia.example#zUC7EwMqo9vCjFmj7ArU2SivcbeccAY6hd4nw5fVD6xD4W2vm9eVy6VqVnciAZRmPLXnuxuka5JTJVmgz66CxDno6eqZmvUViCckCcKg8A4s1R4i2JjyzrdTQs5zrfY4jJCHFCp", "cryptosuite": "bbs-2023", "proofPurpose": "assertionMethod", "proofValue": "u2V0DhVkDEJOplpVKV9UBPos-YnSuy7u-_wuxUUcElOCVqJwekpfS8pDYv5mlIiADqJNm62CgfJMG1SeBV9Ri5DlmMAOaWayl51Aqc_fPn1V756d-P51JNwmlPQ9RmyYQPGfk3_8z0KF57H_seUFGZOYAtul85f9rypgN_emBvVApxUSMClqvNSgNVQ_sqVS1ICFkz9MIuTv6Ng6F8CNm0svtv1Tnkmjn6I4bgP0b46j57-lgiAP6Xb72RCnppHyfcuc6z9NB82BgIPCHzu2V3u8sWHyPS1JzVDLUiPVWUy6Oar0A4q9QLP4y92Q4JpJRx0Bl-x3cvCcBZp8ESDphMEDoMgEBqWVdWEZ_KQa2JrYuiWeHfK81WPNlJimOp4xl4CotHqx1NIinSB7jmrtcQ-0dIX_vz5wnYwhlP44rE7TgydrFE_16BYk0hkfKJw8sGCQNxqcUMHGh262ZOie2ASifU8OXd5TZOgTaUXRauwCrAPQZnQKnAQ8j8hBLgD_0Ujzt2Yk6dQueUv493jnmWJMnCbAy33MuRhHSqSxHVJBXOhhUX3s79HY0V-uLkGOZw_61HRpAi0W4spLv77ehUlwW5N35VFbs_THFXGA5AgY3Cg1vY-K5SyqpH5BlWhAcTRwoDKboqp0tOecM5qpZyuAORQ7fK2JddnEMHmvOKW7x_ugykAbQm6DeqhyGPtKxuiSulr-IHFK-KyGCXPAAKbk7X5Hkf29q7tOEGTIU4_9ga88PtiQKJTu7Ao8ABBEg9Gqt-KcfqfPgt8cqwxGtjW21sD3bSbtUiWNQO3ZDPelP9ToXbduEPpsNEYwxRbMtS5SF6YDqy16Bo8uyw41jnKvb-E5ABF-2MGjxB9zt8ZH_TJirGP_IMt0ssYrODZAlJbakLKiD5NH3g-xlvMTHxrD8VEzJakACnJIrm3X9J7MjUM_YTqth99oc2Yq2HLlgwYb1hD3T6jsIaY8zRPzA2ybKdXxZ3ahxyc_nbLDnP2fVNbUj8P9EX2Av_GvmnSYRsE5Wmcblhao6Ref1EF8YFF6JFT8SO2WiAAIBAIQABAUHhAABBxFYRXsiY2hhbGxlbmdlIjoiejFBREtDNVFBdW1Tb1Jud1NDSHRhUXBvQSIsImRvbWFpbiI6InZjcGxheWdyb3VuZC5vcmcifQ" } ] } ] } The verifiable presentation above includes a verifiable credential that contains an unlinkable subset of the information from the previous example and a derived proof that the verifier can use to verify that the information originated from the expected issuer and is bound to this particular exchange of information. 5.8 Representing Time Implementers are urged to understand that representing and processing time values is not as straight-forward as it might seem and have a variety of idiosyncrasies that are not immediately obvious nor uniformly observed in different regions of the world. For example: Calendaring systems other than the Gregorian calendar are actively used by various regions. When processing Daylight Saving/Summer Time, it is important to understand that 1) it is not observed in all regions, 2) it does not necessarily begin or end on the same day or at the same time of day, and 3) the amount or direction of the adjustment does not always match other similar regions. Leap seconds might not be taken into account in all software systems, especially for dates and times that precede the introduction of the leap second. Leap seconds can affect highly sensitive systems that depend on the exact millisecond offset from the epoch. However, note that for most applications the only moment in time that is affected is the one second period of the leap second itself. That is, the moment after the most recent leap second can always be represented as the first moment of the next day (for example, 2023-01-01T00:00:00Z ), regardless of whether the system in question understands leap seconds. These are just a few examples that illustrate that the actual time of day, as would be seen on a clock on the wall, can exist in one region but not exist in another region. For this reason, implementers are urged to use time values that are more universal, such as values anchored to the Z time zone over values that are affected by Daylight Saving/Summer Time. This specification attempts to increase the number of universally recognized combinations of dates and times, and reduce the potential for misinterpretation of time values, by using the dateTimeStamp construction first established by the [ XMLSCHEMA11-2 ] specification. In order to reduce misinterpretations between different time zones, all time values expressed in conforming documents SHOULD be specified in dateTimeStamp format, either in Universal Coordinated Time (UTC), denoted by a Z at the end of the value, or with a time zone offset relative to UTC. Time values that are incorrectly serialized without an offset MUST be interpreted as UTC. Examples of valid time zone offsets relative to UTC include Z , +01:00 , -08:00 , and +14:00 . See the regular expression at the end of this section for a formal definition of all acceptable values. Time zone definitions are occasionally changed by their governing body. When replacing or issuing new verifiable credentials , implementers are advised to ensure that changes to local time zone rules do not result in unexpected gaps in validity. For example, consider the zone America/Los_Angeles , which has a raw offset of UTC-8 and had voted to stop observing daylight savings time in the year 2024. A given verifiable credential that had a validUtil value of 2024-07-12T12:00:00-07:00 , might be re-issued to have a validFrom value of 2024-07-12T12:00:00-08:00 , which would create a gap of an hour where the verifiable credential would not be valid. Implementers that desire to check dateTimeStamp values for validity can use the regular expression provided below, which is reproduced from the [ XMLSCHEMA11-2 ] specification for convenience. To avoid doubt, the regular expression in [ XMLSCHEMA11-2 ] is the normative definition. Implementers are advised that not all dateTimeStamp values that pass the regular expression below are valid moments in time. For example, the regular expression below allows for 31 days in every month, which allows for leap years, and leap seconds, as well as days in places where they do not exist. That said, modern system libraries that generate dateTimeStamp values are often error-free in their generation of valid dateTimeStamp values. The regular expression shown below (minus the whitespace included here for readability), is often adequate when processing library-generated dates and times on modern systems. Example 32 : Regular expression to detect a valid XML Schema 1.1: Part 2 dateTimeStamp -?([1-9][0-9]{3,}|0[0-9]{3}) -(0[1-9]|1[0-2]) -(0[1-9]|[12][0-9]|3[01]) T(([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.[0-9]+)?|(24:00:00(\.0+)?)) (Z|(\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00)) 5.9 Authorization This section is non-normative. Verifiable credentials are intended as a means of reliably identifying subjects . While it is recognized that Role Based Access Controls (RBACs) and Attribute Based Access Controls (ABACs) rely on this identification as a means of authorizing subjects to access resources, this specification does not provide a complete solution for RBAC or ABAC. Authorization is not an appropriate use for this specification without an accompanying authorization framework. The Working Group did consider authorization use cases during the creation of this specification and is pursuing that work as an architectural layer built on top of this specification. 5.10 Reserved Extension Points This specification reserves a number of properties to serve as possible extension points. While some implementers signaled interest in these properties, their inclusion in this specification was considered to be premature. It is important to note that none of these properties are defined by this specification. Consequently, implementers are cautioned that use of these properties is considered experimental. Implementers MAY use these properties, but SHOULD expect them and/or their meanings to change during the process of normatively specifying them. Implementers SHOULD NOT use these properties without a publicly disclosed specification describing their implementation. In order to avoid collisions regarding how the following properties are used, implementations MUST specify a type property in the value associated with the reserved property. For more information related to adding type information, see Section 4.5 Types . Reserved Property Description confidenceMethod A property used for specifying one or more methods that a verifier might use to increase their confidence that the value of a property in or of a verifiable credential or verifiable presentation is accurate. The associated vocabulary URL MUST be https://www.w3.org/2018/credentials#confidenceMethod . Implementers that are interested in learning more about confidence method, including examples of usage, can refer to the Verifiable Credential Confidence Methods v1.0 specification. renderMethod A property used for specifying one or more methods to render a credential into a visual, auditory, haptic, or other format. The associated vocabulary URL MUST be https://www.w3.org/2018/credentials#renderMethod . Implementers that are interested in learning more about render method, including examples of usage, can refer to the Verifiable Credential Rendering Methods v1.0 specification. An unofficial list of specifications that are associated with the extension points defined in this specification, as well as the reserved extension points defined in this section, can be found in the Verifiable Credential Extensions . Items in the directory that refer to reserved extension points SHOULD be treated as experimental. 5.11 Ecosystem Compatibility There are a number of digital credential formats that do not natively use the data model provided in this document, but are aligned with a number of concepts in this specification. At the time of publication, examples of these digital credential formats include JSON Web Tokens (JWTs), CBOR Web Tokens (CWTs), JSON Advanced Electronic Signature (JAdES), ISO-18013-5:2021 (mDLs), AnonCreds , Gordian Envelopes , and Authentic Chained Data Containers (ACDCs). If conceptually aligned digital credential formats can be transformed into a conforming document according to the rules provided in this section, they are considered "compatible with the W3C Verifiable Credentials ecosystem" . Specification authors are advised to adhere to the following rules when documenting transformations that enable compatibility with the Verifiable Credentials ecosystem. The transformation specification — MUST identify whether the transformation to this data model is one-way-only or round-trippable. MUST preserve the @context values when performing round-trippable transformation. MUST result in a conforming document when transforming to the data model described by this specification. MUST specify a registered media type for the input document. SHOULD provide a test suite that demonstrates that the specified transformation algorithm to the data model in this specification results in a conforming document . SHOULD ensure that all semantics used in the transformed conforming document follow best practices for Linked Data. See Section 4.1 Getting Started , Section 5.2 Extensibility , and Linked Data Best Practices [ LD-BP ] for additional guidance. Note : What constitutes a verifiable credential? Readers are advised that a digital credential is only considered compatible with the W3C Verifiable Credentials ecosystem if it is a conforming document and it uses at least one securing mechanism, as described by their respective requirements in this specification. While some communities might call some digital credential formats that are not conforming documents "verifiable credentials", doing so does NOT make that digital credential compliant to this specification. For example, despite the use of the letters "VC" in the SD-JWT-VC [ SD-JWT-VC ] specification, that specification explicitly states that it is incompatible with W3C Verifiable Credentials. 5.12 Verifiable Credential Graphs When expressing verifiable credentials (for example in a presentation ), it is important to ensure that data in one verifiable credential is not mistaken to be the same data in another verifiable credential . For example, if one has two verifiable credentials , each containing an object of the following form: {"type": "Person", "name": "Jane Doe"} , it is not possible to tell if one object is describing the same person as the other object. In other words, merging data between two verifiable credentials without confirming that they are discussing the same entities and/or properties, can lead to a corrupted data set. To ensure that data from different verifiable credentials are not accidentally co-mingled, the concept of a verifiable credential graph is used to encapsulate each verifiable credential . For simple verifiable credentials , that is, when the JSON-LD document contains a single credential with, possibly, associated proofs, this graph is the default graph . For presentations , each value associated with the verifiableCredential property of the presentation is a separate named graph of type VerifiableCredentialGraph which contains a single verifiable credential or an enveloped verifiable credential . Using these graphs has a concrete effect when performing JSON-LD processing, which properly separates graph node identifiers in one graph from those in another graph. Implementers that limit their inputs to application-specific JSON-LD documents will also need to keep this in mind if they merge data from one verifiable credential with data from another, such as when the credentialSubject.id is the same in both verifiable credentials , but the object might contain objects of the "Jane Doe" form described in the previous paragraph. It is important to not merge objects that seem to have similar properties but do not contain an id property that uses a global identifier, such as a URL. 5.13 Securing Mechanism Specifications As described in Section 4.12 Securing Mechanisms , there are multiple strategies that an implementer can use when securing a conforming document . In order to maximize utility and interoperability, specification authors that desire to author new ways of securing conforming documents are provided with the guidance in this section. Securing mechanism specifications MUST document normative algorithms that provide content integrity protection for conforming documents . The algorithms MAY be general in nature and MAY be used to secure data other than conforming documents . Securing mechanism specifications MUST provide a verification algorithm that returns the information in the conforming document that has been secured, in isolation, without including any securing mechanism information, such as proof or JOSE/COSE header parameters and signatures. Verification algorithms MAY return additional information that might be helpful (for example, during validation or for debugging purposes), such as details of the securing mechanism. A verification algorithm MUST provide an interface that receives a media type ( string inputMediaType ) and input data ( byte sequence or map inputData ). Securing mechanism specifications MAY provide algorithms and interfaces in addition to the ones specified in this document. The verification algorithm returns a verification result with at least the following items : boolean verified A verification status whose value is true if the verification succeeded and false if it did not. map verifiedDocument A document that only contains information that was successfully secured. string mediaType A media type as defined in [ RFC6838 ]. Securing mechanism specifications SHOULD provide integrity protection for any information referenced by a URL that is critical to validation. Mechanisms that can achieve this protection are discussed in Section 5.3 Integrity of Related Resources and Section C.1 Base Context . A securing mechanism specification that creates a new type of embedded proof MUST specify a property that relates the verifiable credential or verifiable presentation to a proof graph . The requirements on the securing mechanism are as follow: The securing mechanism MUST define all terms used by the proof graph . For example, the mechanism could define vocabulary specifications and @context files in the same manner as they are used by this specification. The securing mechanism MUST secure all graphs in the verifiable credential or the verifiable presentation , except for any proof graphs securing the verifiable credential or the verifiable presentation itself. Note The last requirement means that the securing mechanism secures the default graph and, for verifiable presentations , each verifiable credential of the presentation, together with their respective proof graphs . See also Figure 9 or Figure 14 . The proof property as defined in [ VC-DATA-INTEGRITY ] MAY be used by the embedded securing mechanism. Securing mechanism specifications SHOULD register the securing mechanism in the Securing Mechanisms section of the Verifiable Credential Extensions document. Note : Choice of securing mechanism is use-case dependent There are multiple acceptable securing mechanisms, and this specification does not mandate any particular securing mechanism for use with verifiable credentials or verifiable presentations . The Working Group that produced this specification did standardize two securing mechanism options, which are: Verifiable Credential Data Integrity 1.0 [ VC-DATA-INTEGRITY ] and Securing Verifiable Credentials using JOSE and COSE [ VC-JOSE-COSE ]. Other securing mechanisms that are known to the community can be found in the Securing Mechanisms section of the Verifiable Credential Extensions document. 6. Syntaxes The data model as described in Sections 3. Core Data Model , 4. Basic Concepts , and 5. Advanced Concepts is the canonical structural representation of a verifiable credential or verifiable presentation . All syntaxes are representations of that data model in a specific format. This section specifies how the data model is serialized in JSON-LD for application/vc and application/vp , the base media types for verifiable credentials and verifiable presentations , respectively. Although syntactic mappings are only provided for JSON-LD, applications and services can use any other data representation syntax (such as XML, YAML, or CBOR) that is capable of being mapped back to application/vc or application/vp . As the verification and validation requirements are defined in terms of the data model, all serialization syntaxes have to be deterministically translated to the data model for processing, validation , or comparison. The expected arity of the property values in this specification, and the resulting datatype which holds those values, can vary depending on the property. If present, the following properties are represented as a single value: id (Section 4.4 Identifiers ), issuer (Section 4.7 Issuer ), and validFrom / validUntil (Section 4.9 Validity Period ). All other properties, if present, are represented as either a single value or an array of values. 6.1 JSON-LD This specification uses JSON-LD 1.1 to serialize the data model described in this specification. JSON-LD is useful because it enables the expression of the graph-based data model on which verifiable credentials are based, machine-readable semantics , and is also useful when extending the data model (see Sections 3. Core Data Model and 5.2 Extensibility ). JSON-LD is a JSON-based format used to serialize Linked Data . Linked Data is modeled using Resource Description Framework (RDF) [ RDF11-CONCEPTS ]. RDF is a technology for modeling graphs of statements. Each statement is a single subject→property→value (also known as entity→attribute→value ) relationship, which is referred to as a claim in this specification. JSON-LD is a technology that enables the expression of RDF using idiomatic JSON, enabling developers familiar with JSON to write applications that consume RDF as JSON. See Relationship of JSON-LD to RDF for more details. Notable JSON-LD Features In general, the data model and syntax described in this document enables developers to largely treat verifiable credentials as JSON documents, allowing them to copy and paste examples, with minor modification, into their software systems. The design goal of this approach is to provide a low barrier to entry while still ensuring global interoperability between a heterogeneous set of software systems. This section describes some of the JSON-LD features that are used to make this possible, which will likely go unnoticed by most developers, but whose details might be of interest to implementers. The most noteworthy features in JSON-LD 1.1 used by this specification include: The @id and @type keywords are aliased to id and type respectively, enabling developers to use this specification as idiomatic JSON. Data types, such as integers, dates, units of measure, and URLs, are automatically typed to provide stronger type guarantees for use cases that require them. The verifiableCredential property is defined as a JSON-LD 1.1 graph container . This requires the creation of named graphs , used to isolate sets of data asserted by different entities. This ensures, for example, proper cryptographic separation between the data graph provided by each issuer and the one provided by the holder presenting the verifiable credential to ensure the provenance of the information for each graph is preserved. The @protected properties feature of JSON-LD 1.1 is used to ensure that terms defined by this specification cannot be overridden. This means that as long as the same @context declaration is made at the top of a verifiable credential or verifiable presentation , interoperability is guaranteed for all terms understood by users of the data model whether or not they use a JSON-LD 1.1 processor. Restrictions on JSON-LD In order to increase interoperability, this specification restricts the use of JSON-LD representations of the data model. JSON-LD compacted document form MUST be used for all representations of the data model using the application/vc or application/vp media type. As elaborated upon in Section 6.3 Type-Specific Credential Processing , some software applications might not perform generalized JSON-LD processing. Authors of conforming documents are advised that interoperability might be reduced if JSON-LD keywords in the @context value are used to globally affect values in a verifiable credential or verifiable presentation , such as by setting either or both of the @base or @vocab keywords. For example, setting these values might trigger a failure in a mis-implemented JSON Schema test of the @context value in an implementation that is performing type-specific credential processing and not expecting the @base and/or @vocab value to be expressed in the @context value. In order to increase interoperability, conforming document authors are urged to not use JSON-LD features that are not easily detected when performing type-specific credential processing . These features include: In-line declaration of JSON-LD keywords in the @context value that globally modify document term and value processing, such as setting @base or @vocab Use of JSON-LD contexts that override declarations in previous contexts, such as resetting @vocab In-line declaration of JSON-LD contexts in the @context property Use of full URLs for JSON-LD terms and types (for example, https://www.w3.org/2018/credentials#VerifiableCredential or https://vocab.example/myvocab#SomeNewType ) instead of the short forms of any such values (for example, VerifiableCredential or SomeNewType ) that are explicitly defined in JSON-LD @context mappings (for example, in https://www.w3.org/ns/credentials/v2 ) While this specification cautions against the use of @vocab , there are legitimate uses of the feature, such as to ease experimentation, development, and localized deployment. If an application developer wants to use @vocab in production, which is advised against to reduce term collisions and leverage the benefits of semantic interoperability, they are urged to understand that any use of @vocab will disable reporting of "undefined term" errors, and later use(s) will override any previous @vocab declaration(s). Different values of @vocab can change the semantics of the information contained in the document, so it is important to understand whether and how these changes will affect the application being developed. Lists and Arrays Lists, arrays, and even lists-of-lists are possible when using JSON-LD 1.1 . We encourage those who want RDF semantics in use cases requiring lists and arrays to follow the guidance on lists in JSON-LD 1.1 . In general, a JSON array is ordered, while a JSON-LD array is not ordered unless that array uses the @list keyword. Note : Array order might not matter While it is possible to use this data model by performing type-specific credential processing , those who do so and make use of arrays need to be aware that unless the above guidance is followed, the order of items in an array are not guaranteed in JSON-LD. This might lead to unexpected behavior. If JSON structure or ordering is important to your application, we recommend you mark such elements as @json via an @context that is specific to your use case. An example of such a declaration is shown below. Example 33 : A @context file that defines a matrix as an embedded JSON data structure { "@context" : { "matrix" : { "@id" : "https://website.example/vocabulary#matrix" , "@type" : "@json" } } } When the context shown above is used in the example below, by including the https://website.example/matrix/v1 context in the @context property, the value in credentialSubject.matrix retains its JSON semantics; the exact order of all elements in the two dimensional matrix is preserved. Example 34 : A verifiable credential with an embedded JSON data structure { "@context" : [ "https://www.w3.org/ns/credentials/v2" , "https://www.w3.org/ns/credentials/examples/v2" , "https://website.example/matrix/v1" ] , "id" : "http://university.example/credentials/1872" , "type" : [ "VerifiableCredential" , "ExampleMatrixCredential" ] , "issuer" : "https://university.example/issuers/565049" , "validFrom" : "2010-01-01T19:23:24Z" , "credentialSubject" : { "id" : "did:example:ebfeb1f712ebc6f1c276e12ec21" , "matrix" : [ [ 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 10 , 11 , 12 ] , [ 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 0 , 0 , 0 , 0 ] , [ 0 , 0 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 0 , 0 , 0 ] ] } } 6.2 Media Types Media types, as defined in [ RFC6838 ], identify the syntax used to express a verifiable credential as well as other useful processing guidelines. Syntaxes used to express the data model in this specification SHOULD be identified by a media type, and conventions outlined in this section SHOULD be followed when defining or using media types with verifiable credentials . There are two media types associated with the core data model, which are listed in the Section D. IANA Considerations : application/vc and application/vp . The application/vc and application/vp media types do not imply any particular securing mechanism, but are intended to be used in conjunction with securing mechanisms. A securing mechanism needs to be applied to protect the integrity of these media types. Do not assume security of content regardless of the media type used to communicate it. Media Type Precision This section is non-normative. At times, developers or systems might use lower precision media types to convey verifiable credentials or verifiable presentations . Some of the reasons for use of lower precision media types include: A web server defaults to text/plain or application/octet-stream when a file extension is not available and it cannot determine the media type. A developer adds a file extension that leads to a media type that is less specific than the content of the file. For example, .json could result in a media type of application/json and .jsonld might result in a media type of application/ld+json . A protocol requires a less precise media type for a particular transaction; for example, application/json instead of application/vp , Implementers are urged to not raise errors when it is possible to determine the intended media type from a payload, provided that the media type used is acceptable in the given protocol. For example, if an application only accepts payloads that conform to the rules associated with the application/vc media type, but the payload is tagged with application/json or application/ld+json instead, the application might perform the following steps to determine whether the payload also conforms to the higher precision media type: Parse the payload as a JSON document. Ensure that the first element of the @context property matches https://www.w3.org/ns/credentials/v2 . Assume an application/vp media type if the JSON document contains a top-level type property containing a VerifiablePresentation element. Additional subsequent checks are still expected to be performed (according to this specification) to ensure the payload expresses a conformant verifiable presentation . Assume an application/vc media type if the JSON document contains a top-level type property containing a VerifiableCredential element. Additional subsequent checks are still expected to be performed (according to this specification) to ensure the payload expresses a conformant verifiable credential . Whenever possible, implementers are advised to use the most precise (the highest precision) media type for all payloads defined by this specification. Implementers are also advised to recognize that a payload tagged with a lower precision media type does not mean that the payload does not meet the rules necessary to tag it with a higher precision type. Similarly, a payload tagged with a higher precision media type does not mean that the payload will meet the requirements associated with the media type. Receivers of payloads, regardless of their associated media type, are expected to perform appropriate checks to ensure that payloads conform with the requirements for their use in a given system. HTTP clients and servers use media types associated with verifiable credentials and verifiable presentations in accept headers and when indicating content types. Implementers are warned that HTTP servers might ignore the accept header and return another content type, or return an error code such as 415 Unsupported Media Type . 6.3 Type-Specific Credential Processing This section is non-normative. As JSON can be used to express different kinds of information, a consumer of a particular JSON document can only properly interpret the author's intent if they possess information that contextualizes and disambiguates it from other possible expressions. Information to assist with this interpretation can either be wholly external to the JSON document or linked from within it. Compacted JSON-LD documents include a @context property that internally expresses or links to contextual information to express claims . These features enable generalized processors to be written to convert JSON-LD documents from one context to another, but this is not needed when consumers receive JSON-LD documents that already use the context and shape that they expect. Authors of JSON-LD documents, such as issuers of verifiable credentials , are required to provide proper JSON-LD contexts and follow these rules in order to facilitate interoperability. The text below helps consumers understand how to ensure a JSON-LD document is expressed in a context and shape that their application already understands such that they do not need to transform it in order to consume its contents. Notably, this does not mean that consumers do not need to understand any context at all; rather, consuming applications only need to understand a chosen set of contexts and document shapes to work with and not others. Issuers can publish contexts and information about their verifiable credentials to aid consumers who do not use generalized processors, just as can be done with any other JSON-formatted data. General JSON-LD processing is defined as a mechanism that uses a JSON-LD software library to process a conforming document by performing various transformations . Type-specific credential processing is defined as a lighter-weight mechanism for processing conforming documents , that doesn't require a JSON-LD software library. Some consumers of verifiable credentials only need to consume credentials with specific types. These consumers can use type-specific credential processing instead of generalized processing. Scenarios where type-specific credential processing can be desirable include, but are not limited to, the following: Before applying a securing mechanism to a conforming document , or after verifying a conforming document protected by a securing mechanism, to ensure data integrity . When performing JSON Schema validation, as described in Section 4.11 Data Schemas . When serializing or deserializing verifiable credentials or verifiable presentations into systems that store or index their contents. When operating on verifiable credentials or verifiable presentations in a software application, after verification or validation is performed for securing mechanisms that require general JSON-LD processing . When an application chooses to process the media type using the +json structured media type suffix. That is, type-specific credential processing is allowed as long as the document being consumed or produced is a conforming document . If type-specific credential processing is desired, an implementer is advised to follow this rule: Ensure that all values associated with a @context property are in the expected order, the contents of the context files match known good cryptographic hashes for each file, and domain experts have deemed that the contents are appropriate for the intended use case. Using static context files with a JSON Schema is one acceptable approach to implementing the rule above. This can ensure proper term identification, typing, and order, when performing type-specific credential processing . The rule above guarantees semantic interoperability between the two processing mechanisms for mapping literal JSON keys to URIs via the @context mechanism. While general JSON-LD processing can use previously unseen @context values provided in its algorithms to verify that all terms are correctly specified, implementations that perform type-specific credential processing only accept specific @context values which the implementation is engineered ahead of time to understand, resulting in the same semantics without invoking any JSON-LD APIs. In other words, the context in which the data exchange happens is explicitly stated for both processing mechanisms by using @context in a way that leads to the same conforming document semantics. 7. Algorithms This section contains algorithms that can be used by implementations to perform common operations, such as verification . Conformance requirements phrased as algorithms use normative concepts from the Infra Standard [ INFRA ]. See the section on Algorithm Conformance in the Infra Standard for more guidance on implementation requirements. Note : Implementers can include additional checks, warnings, and errors. Implementers are advised that the algorithms in this section contain the bare minimum set of checks used by implementations to test conformance to this specification. Implementations are expected to provide additional checks that report helpful warnings for developers to help debug potential issues. Similarly, implementations are likely to provide additional checks that could result in new types of errors being reported in order to stop harmful content. Any of these additional checks might be integrated into future versions of this specification. 7.1 Verification This section contains an algorithm that conforming verifier implementations MUST run when verifying a verifiable credential or a verifiable presentation . This algorithm takes a media type ( string inputMediaType ) and secured data ( byte sequence inputData ) and returns a map that contains the following: a status ( boolean status ) a conforming document ( map document ) a media type ( string mediaType ) a controller of the verification method associated with the securing mechanism ( string controller ) a controlled identifier document that is associated with the verification method used to verify the securing mechanism ( map controlledIdentifierDocument ) zero or more warnings ( list of ProblemDetails warnings ) zero or more errors ( list of ProblemDetails errors ) The verification algorithm is as follows: Ensure that the securing mechanism has properly protected the conforming document by performing the following steps: Set the verifyProof function by using the inputMediaType and the Securing Mechanisms section of the Verifiable Credential Extensions document, or other mechanisms known to the implementation, to determine the cryptographic suite to use when verifying the securing mechanism. The verifyProof function MUST implement the interface described in 5.13 Securing Mechanism Specifications . If the verifyProof function expects a byte sequence , provide inputMediaType and inputData to the algorithm. If the verifyProof function expects a map , provide inputMediaType and the result of parse JSON bytes to an Infra value given inputData . Set result to the result of the call to the verifyProof function. If the call was successful, result will contain the status , document , mediaType , controller , controlledIdentifierDocument , warnings , and errors properties. If result . status is set to false , add a CRYPTOGRAPHIC_SECURITY_ERROR to result . errors . If result . status is set to true , ensure that result . document is a conforming document . If it is not, set result . status to false , remove the document property from result , and add at least one MALFORMED_VALUE_ERROR to result . errors . Other warnings and errors MAY be included to aid any debugging process. Return result . The steps for verifying the state of the securing mechanism and verifying that the input document is a conforming document MAY be performed in a different order than that provided above as long as the implementation returns errors for the same invalid inputs. Implementations MAY produce different errors than described above. 7.2 Problem Details When an implementation detects an anomaly while processing a document, a ProblemDetails object can be used to report the issue to other software systems. The interface for these objects follow [ RFC9457 ] to encode the data. A ProblemDetails object consists of the following properties: type The type property MUST be present and its value MUST be a URL identifying the type of problem. title The title property SHOULD provide a short but specific human-readable string for the problem. detail The detail property SHOULD provide a longer human-readable string for the problem. The following problem description types are defined by this specification: https://www.w3.org/TR/vc-data-model#PARSING_ERROR There was an error while parsing input. https://www.w3.org/TR/vc-data-model#CRYPTOGRAPHIC_SECURITY_ERROR The securing mechanism for the document has detected a modification in the contents of the document since it was created; potential tampering detected. See Section 7.1 Verification . https://www.w3.org/TR/vc-data-model#MALFORMED_VALUE_ERROR The value associated with a particular property is malformed. The name of the property and the path to the property SHOULD be provided in the ProblemDetails object. See Section 7.1 Verification . https://www.w3.org/TR/vc-data-model#RANGE_ERROR A provided value is outside of the expected range of an associated value, such as a given index value for an array being larger than the current size of the array. Implementations MAY extend the ProblemDetails object by specifying additional types or properties. See the Extension Member section in [ RFC9457 ] for further guidance on using this mechanism. 8. Accessibility Considerations This section is non-normative. There are a number of accessibility considerations implementers should be aware of when processing data described in this specification. As with implementation of any web standard or protocol, ignoring accessibility issues makes this information unusable by a large subset of the population. It is important to follow accessibility guidelines and standards, such as [ WCAG21 ], to ensure that all people, regardless of ability, can make use of this data. This is especially important when establishing systems using cryptography, which have historically created problems for assistive technologies. This section details the general accessibility considerations to take into account when using this data model. 8.1 Data First Approaches This section is non-normative. Many physical credentials in use today, such as government identification cards, have poor accessibility characteristics, including, but not limited to, small print, reliance on small and high-resolution images, and no affordances for people with vision impairments. When using this data model to create verifiable credentials , it is suggested that data model designers use a data first approach. For example, given the choice of using data or a graphical image to depict a credential , designers should express every element of the image, such as the name of an institution or the professional credential , in a machine-readable way instead of relying on a viewer's interpretation of the image to convey this information. Using a data first approach is preferred because it provides the foundational elements of building different interfaces for people with varying abilities. 9. Internationalization Considerations This section is non-normative. Implementers are advised to be aware of a number of internationalization considerations when publishing data described in this specification. As with any web standards or protocols implementation, ignoring internationalization makes it difficult for data to be produced and consumed across a disparate set of languages and societies, which limits the applicability of the specification and significantly diminishes its value as a standard. Implementers are strongly advised to read the Strings on the Web: Language and Direction Metadata document [ STRING-META ], published by the W3C Internationalization Activity, which elaborates on the need to provide reliable metadata about text to support internationalization. For the latest information on internationalization considerations, implementers are also urged to read the Verifiable Credentials Implementation Guidelines [ VC-IMP-GUIDE ] document. This section outlines general internationalization considerations to take into account when using this data model and is intended to highlight specific parts of the Strings on the Web: Language and Direction Metadata document [ STRING-META ] that implementers might be interested in reading. 9.1 Language and Base Direction Data publishers are strongly encouraged to read the section on Cross-Syntax Expression in the Strings on the Web: Language and Direction Metadata document [ STRING-META ] to ensure that expressing language and base direction information is possible across multiple expression syntaxes, such as [ JSON-LD11 ], [ JSON ], and CBOR [ RFC7049 ]. The general design pattern is to use the following markup template when expressing a text string that is tagged with a language and, optionally, a specific base direction. Example 35 : Design pattern for natural language strings "myProperty": { "@value": " The string value ", "@language": "LANGUAGE" "@direction": "DIRECTION" } When the language value object is used in place of a string value, the object MUST contain a @value property whose value is a string, and SHOULD contain a @language property whose value is a string containing a well-formed Language-Tag as defined by [ BCP47 ], and MAY contain a @direction property whose value is a base direction string defined by the @direction property in [ JSON-LD11 ]. The language value object MUST NOT include any other keys beyond @value , @language , and @direction . Using the design pattern above, the following example expresses the title of a book in the English language without specifying a text direction. Example 36 : Expressing natural language text as English "title": { "@value": " HTML and CSS: Designing and Creating Websites ", "@language": "en" } The next example uses a similar title expressed in the Arabic language with a base direction of right-to-left. Example 37 : Arabic text with a base direction of right-to-left "title": { "@value": " HTML و CSS: تصميم و إنشاء مواقع الويب ", "@language": "ar", "@direction": "rtl" } Note : Properly rendering internationalized text is challenging The text above would most likely be rendered incorrectly as left-to-right without the explicit expression of language and direction because many systems use the first character of a text string to determine its base direction . Multiple language value objects MAY be provided as an array value for the property: Example 38 : Multiple language texts provided for title "title": [ { "@value": " HTML and CSS: Designing and Creating Websites ", "@language": "en" }, { "@value": " HTML و CSS: تصميم و إنشاء مواقع الويب ", "@language": "ar", "@direction": "rtl" } ] Example 39 : Example dual language credential { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://achievement.example/multilingual/v2" ], "type": [ "VerifiableCredential", "ExampleAchievementCredential" ], "issuer": { "id": "did:example:2g55q912ec3476eba2l9812ecbfe", "type": "Profile" }, "validFrom": "2024-03-14T22:32:52Z", "validUntil": "2025-01-01T00:00:00Z",

"credentialSubject": { "type": [ "AchievementSubject" ], "achievement": { "id": "urn:uuid:9a652678-4616-475d-af12-aca21cfbe06d", "type": [ "Achievement" ], "name": { "en": "Successful installation of the Example application", "es": "Instalación exitosa de la aplicación Example" }, "criteria": { "narrative": { "es": "Instaló exitosamente de la aplicación Example.", "en": "Successfully installed the Example application." } } } } } 9.2 Providing Default Language and Direction The language and base direction of each natural language string property value SHOULD be provided, either via the language value structure for each property value, or via a default language and base direction for all values in the entire credential. Using the per-value language value structure is preferred, because using document defaults can result in a requirement that downstream processors perform JSON-LD expansion-based transformation which is otherwise optional. See the String Internationalization section of the [ JSON-LD11 ] specification for more information. Natural language string values that do not have a language associated with them SHOULD be treated as if the language value is undefined (language tag " und "). Natural language string values that do not have a base direction associated with them SHOULD be treated as if the direction value is " auto ". A. Threat Model This section is non-normative. This section details the general threat model for this specification, including security considerations and privacy considerations. The full analysis of each threat, together with the responses to it, is provided in the Verifiable Credentials Data Model Threat Model . Implementers are expected to apply the advice given there to each specific feature provided by this specification. A.1 Target Threats Credential Content Tampering security — An attacker with access to a verifiable credential after it is issued modifies its contents to alter the claims it expresses, or strips its securing mechanism in the hope that a downstream verification process consumes it without detecting that integrity protection is absent. Identity Proofing Failure at Issuance security — An issuer's process for establishing confidence in a subject fails, so an attacker who presents another person's information receives an authentic credential naming the victim as its subject , and every downstream verification succeeds. A.2 Implementation Threats Code Injection via Credential Content security — A verifiable credential carries values containing injectable code, such as markup in an rdf:HTML value, and a consumer that renders the content without adequate handling is made to execute it. Signature-Based Correlation privacy — The values that make up a securing mechanism , such as a signature value, its timestamp, or a public key identifier, remain the same across sessions and domains, letting verifiers link presentations to the same holder even when no correlating identifier appears in the payload. Correlation via Status and Revocation Lookup privacy — The act of checking a credential's status leaks that an interaction is taking place, letting an issuer learn everywhere a credential is presented and enabling issuers and verifiers to collude to correlate the holder . Signing Key Compromise and Mismanagement security — A compromised private signing key lets an attacker forge credentials that verification reports as authentic; reusing a key for more than one purpose or keeping it in service for an over-long cryptoperiod makes compromise more likely. Tampering with Unprotected External Resources security — Content linked from a verifiable credential , such as an image, JSON-LD context, or JSON Schema, lives outside the protection of the securing mechanism , so an attacker who modifies it introduces vulnerabilities even though verification still succeeds. Presentation Exchange Attacks (MITM, Replay, and Spoofing) security — The data model does not by itself prevent man-in-the-middle, replay, and spoofing attacks on the exchange of a verifiable presentation : a verifier cannot be sure it is the intended recipient, that a presentation is not being reused, or that the holder is authorized to present the claims . Inappropriate or Out-of-Context Credential Use security — A valid signature and a successful status check do not show that a credential is appropriate for the context in which it is used, so a verifier that treats verification as sufficient accepts a credential whose source and nature do not fit the purpose at hand. A.3 Deployment Threats Identifier-Based Correlation privacy — A verifiable credential contains long-lived identifiers, such as a subject identifier, email address, or government-issued identifier, that let two verifiers , or an issuer and a verifier , collude to track the holder across domains. Untrustworthy User-Agent Software privacy — Software acting as an entity's user agent, above all a holder's digital wallet, operates against the user's interest by disclosing more than the holder authorized, or cannot act in the best interest of every party when it serves more than one role at once. Excessive Data Disclosure privacy — A verifiable credential carries more personally identifiable information than an interaction requires, or a verifier requests more than the minimum necessary, exposing the subject to disclosure every time the credential is used. Metadata-Based Correlation privacy — The choice of extensions, credential types, and technology profiles acts as a correlating fingerprint when relatively few issuers use a specific combination, reducing the pseudonymity a holder expects. Bearer Credential Reuse and Correlation privacy — Repeated use of the same bearer credential across multiple sites lets those sites collude to track the holder , and information that appears non-identifying on its own can statistically identify an individual. Correlation via Patterns of Use privacy — Even when individual disclosures are minimized, the pattern in which verifiable credentials are presented leads to de-anonymization, whether through repeat presentation to one verifier , collusion between several, or a subject identifier that is stable across presentations . Disclosure to a Malicious or Deceptive Verifier privacy — A verifier acts in bad faith and requests information that could harm the holder , such as a bank account number that is then combined with other information to commit fraud. Data Theft and Credential Honeypots security — Storing verifiable credentials and verifiable presentations creates honeypots of sensitive data that attract attackers, with retention and protection choices across the ecosystem determining the scale of a theft. Issuer-Side Correlation and Privacy Subversion privacy — Many privacy protections depend on the issuer not subverting them; an issuer that issues short-lived, automatically renewed credentials , or mints a unique key per credential , correlates the holder's behavior even when a verifier cannot. Inappropriate Validity Periods security — A validity period that extends beyond the time highly dynamic information is intended to be used leaves a window in which stale information is relied upon, while too short a period burdens holders and verifiers with frequent reissuance. Device Theft and Impersonation security — An attacker who gains possession of a lost or stolen device gains unauthorized access to systems that rely on the victim's verifiable credentials , impersonating the holder . A.4 External Threats Storage Provider Data Mining and Compelled Disclosure privacy — A third-party credential repository exposes stored verifiable credentials to its operator, which mines the personal data or is compelled to disclose it through legal process. Device Tracking and Fingerprinting privacy — Tracking mechanisms external to verifiable credentials , such as address tracking, browser fingerprinting, and advertising trackers, combine with credential data to reveal new correlatable information, and fetching a linked external resource signals activity to the server hosting it. Credential and Data Aggregation privacy — Holding two pieces of information about the same subject reveals more than the two considered separately, letting a verifier or colluding sites build a profile that grows as more information leaks over time. Unauthorized Post-Presentation Use of Data privacy — After a holder shares a verifiable presentation for a stated purpose, the verifier uses the data beyond what the holder consented to, and the data model provides no way for the holder to enforce authorized use after presentation . A.5 Dependency Threats Cryptographic Suite Obsolescence security — The cryptography suites and libraries securing verifiable credentials have a shelf life and eventually succumb to new attacks and advances in technology, after which an attacker forges or modifies a credential and verification still reports it as authentic. Privacy Considerations This section is non-normative. This section details the general privacy considerations and specific privacy implications of deploying the Verifiable Credentials Data Model into production environments. The privacy threats summarized above are analyzed in full, together with the responses to each of them, in the Verifiable Credentials Data Model Threat Model . Spectrum of Privacy This section is non-normative. It is important to recognize there is a spectrum of privacy ranging from pseudonymous to strongly identified. Depending on the use case, people have different comfort levels about the information they are willing to provide and the information that can be derived from it. Figure 13 Privacy spectrum ranging from pseudonymous to fully identified. Privacy solutions are use case specific. For example, many people would prefer to remain anonymous when purchasing alcohol because the regulation is only to verify whether a purchaser is above a specific age. In contrast, when filling prescriptions written by a medical professional for a patient, the pharmacy is legally required to more strongly identify both the prescriber and the patient. No single approach to privacy works for all use cases. Note : Proof of age might be insufficient for some use cases Even those who want to remain anonymous when purchasing alcohol might need to provide photo identification to appropriately assure the merchant. The merchant might not need to know your name or any details other than that you are over a specific age, but in many cases, simple proof of age might be insufficient to meet regulations. The Verifiable Credentials Data Model strives to support the full privacy spectrum and does not take philosophical positions on the correct level of anonymity for any specific transaction. Implementers who want to avoid specific scenarios that are hostile to privacy are guided by the privacy threats and responses documented in the Verifiable Credentials Data Model Threat Model . Bearer Credentials This section is non-normative. A bearer credential is a privacy-enhancing piece of information, such as a concert ticket, that entitles its holder to a specific resource without requiring the holder to divulge sensitive information. In low-risk scenarios, entities often use bearer credentials where multiple holders presenting the same verifiable credential is not a concern or would not result in large economic or reputational losses. Verifiable credentials that are bearer credentials are made possible by not specifying the subject identifier, expressed using the id property , which is nested in the credentialSubject property . For example, the following verifiable credential is a bearer credential : Example 40 : Use of issuer properties Credential ecdsa ecdsa-sd bbs jose cose sd-jwt { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/temporary/28934792387492384", "type": ["VerifiableCredential", "ExampleDegreeCredential"], "issuer": "https://university.example/issuers/14", "validFrom": "2017-10-22T12:23:48Z", "credentialSubject": { // note that the 'id' property is not specified for bearer credentials "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } } } application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/temporary/28934792387492384", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/14", "validFrom": "2017-10-22T12:23:48Z", "credentialSubject": { "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "DataIntegrityProof", "created": "2026-09-05T21:09:22Z", "verificationMethod": "did:key:zDnaeqpc578Kg3k9asdXLMhsQSjh8HMPp3ip3miiWZUUhsv9p", "cryptosuite": "ecdsa-rdfc-2019", "proofPurpose": "assertionMethod", "proofValue": "z4gJE9JhYE7Ysoi4bVDxfZtPoS58xSaToS24VgD5ZCFZwrnnNmG1u7TEiWSoDMZg7atEsjnXhgWDDUhPStt3fjP6H" } } application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/temporary/28934792387492384", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/14", "validFrom": "2017-10-22T12:23:48Z", "credentialSubject": { "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "DataIntegrityProof", "created": "2026-09-05T21:09:22Z", "verificationMethod": "did:key:zDnaee6cRuNdNecab7A7cnbb6w5xovYRWxYirEHstya3usouK", "cryptosuite": "ecdsa-sd-2023", "proofPurpose": "assertionMethod", "proofValue": "u2V0AhVhAbXDWQP7VZ4tVSPZEQ37oKYrxGWkIwkwa3sS-rkbte7wecDF3TxhbNKPfY9jd5v0jHqYUmEwN_nAnB636lSLe6VgjgCQDMxU4UBpX81s3MtMHLl8e0TfnyBXVUPx2MPOcIa_zlVZYIF-zYmjno5WxBA8rB82d5MfISeVMrv-alCp6slMeruQqhVhAz_JTxkYAp3EJGTbBF4VXY_mXDt2ZTpRAlgfgoptM2H7zSge_QU8P6XW77Pg-7gfTKBMEVz4qoFhuSnT5ofgjQ1hAfO9DdRJLyiv_i-y6s0XuVFw54dxY8J5E6rcOEVJg8uCCOQ48WAkNtlqQiOvUE4zBlI_mHUHIHOqswhcG8gT0BFhAmq26f0MIY0Xg6SOKUGKlHlDXWfNB8vs9cJobyjaNIIXfkpQfpkH0P_XBOtuitw64aCu1es7oS26vqwqArod4f1hAAJw-H9rtO-XLxlDrP4NZPZDy7l6bQw7CI1cxwjtR2bZpUUvN3728RIK6vEhhtrjsrCV7aETHy7sumaImZoprqlhAxTQKCH9T2RR3lisBRvZKNmcA9Qg9iS6oqx0V4Wwjsmc4m8s_2aAM2FTiBsZgCirVLNQgzDEBLIcQCwQYLD-f44FnL2lzc3Vlcg" } } application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/temporary/28934792387492384", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/14", "validFrom": "2017-10-22T12:23:48Z", "credentialSubject": { "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } }, "proof": { "type": "DataIntegrityProof", "verificationMethod": "did:key:zUC7JVyoNecN4arDQjjTXVSfyv1V7bwcnMUs6y2BuSeWmzarPohM5DLXAXXxkBRrpjbzZTUdrLaAVoj87nPgXktL3q8JgBvRqqHo9Z88Jfn2tXXM8Q1aTDhNgf1HYL9WEMiULnS", "cryptosuite": "bbs-2023", "proofPurpose": "assertionMethod", "proofValue": "u2V0ChVhQr2JdqpEn1gSsMuVv0OOW4ydQjz7yLRGCP4zyahVs3gVxV3yZa3P3kvbf8aHmIY5NVvxNIvEImIEGaLxcQ9IC-mOqGr_iaymo8bVdWwBAa29YQD3-tli9rF9b1rOCOCaDSL0zj-QnIO3TIaEobJTPayaIdrHmhnEXifHmmlKM3zCnc0pq4l3ZkBkIESZ4DrQomVNYYLMBLFvXdBPRt0k4kRZk93gc0jkscNQB3wJpCXu4OPkNaVJMlX03jEKZdwQ437AaRg2tSqfzd_pbHzZq9O7FyF1fsAT1tn_tHqFT5wrUWfaGtHJRQwv6rnUS3s9HBqQB_1ggtUkRUsfQJWZ0UDSHwnjHqcJ-fOZt0xzG9BaPLElAHaSBZy9pc3N1ZXI" } } 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": "http://university.example/credentials/temporary/28934792387492384", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/14", "validFrom": "2017-10-22T12:23:48Z", "credentialSubject": { "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } } } application/vc+jwt eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ . eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzL3RlbXBvcmFyeS8yODkzNDc5MjM4NzQ5MjM4NCIsInR5cGUiOlsiVmVyaWZpYWJsZUNyZWRlbnRpYWwiLCJFeGFtcGxlRGVncmVlQ3JlZGVudGlhbCJdLCJpc3N1ZXIiOiJodHRwczovL3VuaXZlcnNpdHkuZXhhbXBsZS9pc3N1ZXJzLzE0IiwidmFsaWRGcm9tIjoiMjAxNy0xMC0yMlQxMjoyMzo0OFoiLCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsidHlwZSI6IkV4YW1wbGVCYWNoZWxvckRlZ3JlZSIsIm5hbWUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIn19fQ . 0YPxx2rgTOszjVAQkppdAqdLZP3YXjxNFot_Sby6YXRHd4ZrhvUgMnbvmw_SBmfsKjHnARDpZy08kBTQnmH5mA application/vc { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "id": "http://university.example/credentials/temporary/28934792387492384", "type": [ "VerifiableCredential", "ExampleDegreeCredential" ], "issuer": "https://university.example/issuers/14", "validFrom": "2017-10-22T12:23:48Z", "credentialSubject": { "degree": { "type": "ExampleBachelorDegree", "name": "Bachelor of Science and Arts" } } } application/vc+cose d28443a10128a05901a27b2240636f6e74657874223a5b2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f7632222c2268747470733a2f2f7777772e77332e6f72672f6e732f63726564656e7469616c732f6578616d706c65732f7632225d2c226964223a22687474703a2f2f756e69766572736974792e6578616d706c652f63726564656e7469616c732f74656d706f726172792f3238393334373932333837343932333834222c2274797065223a5b2256657269666961626c6543726564656e7469616c222c224578616d706c6544656772656543726564656e7469616c225d2c22697373756572223a2268747470733a2f2f756e69766572736974792e6578616d706c652f697373756572732f3134222c2276616c696446726f6d223a22323031372d31302d32325431323a32333a34385a222c2263726564656e7469616c5375626a656374223a7b22646567726565223a7b2274797065223a224578616d706c6542616368656c6f72446567726565222c226e616d65223a2242616368656c6f72206f6620536369656e636520616e642041727473227d7d7d5840c4d5efc12f60952fc400cfb6d9807733b836513f3b4d215ad73d52c6dc3b2838df68ad4fc4e5dd568d3d419a4e235eb13fa7ed52031476c59b9aafe144e79627 Encoded Decoded Issuer Disclosures eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMyNTYifQ . eyJpYXQiOjE3ODg2NDI1NjIsImV4cCI6MTc4OTg1MjE2MiwiX3NkX2FsZyI6InNoYS0yNTYiLCJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy8xNCIsInZhbGlkRnJvbSI6IjIwMTctMTAtMjJUMTI6MjM6NDhaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiZGVncmVlIjp7Im5hbWUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIiwiX3NkIjpbImgxWGxtZkJ3R20zVkVLUlhWLWw3NUZoRzh1YUlnb3pYUV8xcXkwV2JGcmciXX19LCJfc2QiOlsiZWlYREpKTE5Yc1VWTENmNVdWb3NtSm5fNmtmV0k3ZlFDTVV1QW9ueHhEWSIsImxqTlZIWGZtS0lpRTRKVTB2dUkza3dkbnR6VkRXWXBydWpPbkhxeHU1alEiXX0 . 6mhhGPj27WO7_540JuzSRy6DTA5nRNmAs2QySRwFv6Iav6Y_nLMdTAgL_7g63V9uiF0eeyivfBkaDwF5N3ymgA ~ WyJ5bnpDaURFNnhPazhydjZ2UThNcmtBIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvdGVtcG9yYXJ5LzI4OTM0NzkyMzg3NDkyMzg0Il0 ~ WyJtYW10NnpvTVJBV25WU2tSS2NVMjZnIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d ~ WyJ1SW40blNBRjYzWkFIU2VCU1NJb19RIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0 ~ { "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro", "alg": "ES256" } { "iat": 1788642562, "exp": 1789852162, "_sd_alg": "sha-256", "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "issuer": "https://university.example/issuers/14", "validFrom": "2017-10-22T12:23:48Z", "credentialSubject": { "degree": { "name": "Bachelor of Science and Arts", "_sd": [ "h1XlmfBwGm3VEKRXV-l75FhG8uaIgozXQ_1qy0WbFrg" ] } }, "_sd": [ "eiXDJJLNXsUVLCf5WVosmJn_6kfWI7fQCMUuAonxxDY", "ljNVHXfmKIiE4JU0vuI3kwdntzVDWYprujOnHqxu5jQ" ] } Claim: id SHA-256 Hash: eiXDJJLNXsUVLCf5WVosmJn_6kfWI7fQCMUuAonxxDY Disclosure(s): WyJ5bnpDaURFNnhPazhydjZ2UThNcmtBIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvdGVtcG9yYXJ5LzI4OTM0NzkyMzg3NDkyMzg0Il0 Contents: [ "ynzCiDE6xOk8rv6vQ8MrkA", "id", "http://university.example/credentials/temporary/28934792387492384" ] Claim: type SHA-256 Hash: ljNVHXfmKIiE4JU0vuI3kwdntzVDWYprujOnHqxu5jQ Disclosure(s): WyJtYW10NnpvTVJBV25WU2tSS2NVMjZnIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVEZWdyZWVDcmVkZW50aWFsIl1d Contents: [ "mamt6zoMRAWnVSkRKcU26g", "type", [ "VerifiableCredential", "ExampleDegreeCredential" ] ] Claim: type SHA-256 Hash: h1XlmfBwGm3VEKRXV-l75FhG8uaIgozXQ_1qy0WbFrg Disclosure(s): WyJ1SW40blNBRjYzWkFIU2VCU1NJb19RIiwgInR5cGUiLCAiRXhhbXBsZUJhY2hlbG9yRGVncmVlIl0 Contents: [ "uIn4nSAF63ZAHSeBSSIo_Q", "type", "ExampleBachelorDegree" ] While bearer credentials are privacy-enhancing, issuers still need to take care in their design to avoid unintentionally divulging more information than the holder of the bearer credential expects. The correlation risks that arise from the design and reuse of bearer credentials , and the responses to them, are described in Bearer Credential Reuse and Correlation in the Verifiable Credentials Data Model Threat Model. Private Browsing This section is non-normative. In an ideal private browsing scenario, no PII will be revealed. Because many credentials include PII, organizations providing software to holders ought to warn them about the possibility of this information being revealed if they use credentials and presentations while in private browsing mode. As each browser vendor handles private browsing differently, and some browsers might not have this feature, it is important that implementers not depend on private browsing mode to provide any privacy protections. Instead, implementers are advised to rely on tooling that directly usable by their software to provide privacy guarantees. Security Considerations This section is non-normative. W3C is migrating to a holistic threat modelling approach and is in the process of deprecating the Security Considerations sections in new specifications. Please refer to Appendix A. Threat Model for documentation related to security considerations. B. Validation This section is non-normative. While this specification does not provide conformance criteria for the process of the validation of verifiable credentials or verifiable presentations , readers might be curious about how the information in this data model is expected to be used by verifiers during the process of validation . This section captures a selection of conversations held by the Working Group related to the expected use of the properties in this specification by verifiers . B.1 Credential Type This section is non-normative. When a verifier requests one or more verifiable credentials from a holder , they can specify the type of credential(s) that they would like to receive. Credential types, as well as validation schemas for each type and each of their claims , are defined by specification authors and are published in places like the Verifiable Credential Extensions . The type of a credential is expressed via the type property. A verifiable credential of a specific type contains specific properties (which might be deeply nested) that can be used to determine whether or not the presentation satisfies a set of processing rules that the verifier executes. By requesting verifiable credentials of a particular type , the verifier is able to gather specific information from the holder , which originated with the issuer of each verifiable credential , that will enable the verifier to determine the next stage of an interaction with a holder . When a verifier requests a verifiable credential of a specific type, there will be a set of mandatory and optional claims that are associated with that type. A verifier's validation of a verifiable credential will fail when mandatory claims are not included, and any claim that is not associated with the specific type will be ignored. In other words, a verifier will perform input validation on the verifiable credential it receives and will reject malformed input based on the credential type specification. B.2 Credential Subject This section is non-normative. In the verifiable credentials presented by a holder , the value associated with the id property for each credentialSubject identifies a subject to the verifier . If the holder is also the subject , then the verifier could authenticate the holder if they have verification metadata related to the holder . The verifier could then authenticate the holder using a signature generated by the holder contained in the verifiable presentation . The id property is optional. Verifiers could use other properties in a verifiable credential to uniquely identify a subject . Note : Authentication is out of scope For information on how authentication and WebAuthn might work with verifiable credentials , see the Verifiable Credentials Implementation Guidelines 1.0 document. B.3 Issuer This section is non-normative. The value associated with the issuer property identifies an issuer to the verifier . Metadata related to the issuer property is available to the verifier through the verification algorithm as defined in Section 7.1 Verification . This metadata includes identification of the verified controller of the verification method used by the securing mechanism to secure each verifiable credential or verifiable presentation , of which the controller is typically the respective issuer or holder . Some ecosystems might have more complex relationships between issuers and controllers of verification methods and might use lists of verified issuers in addition to, or instead of, the mapping described above. B.4 Holder This section is non-normative. The value associated with the holder property is used to identify the holder to the verifier . Often relevant metadata about the holder , as identified by the value of the holder property , is available to, or retrievable by, the verifier . For example, a holder can publish information containing the verification material used to secure verifiable presentations . This metadata is used when checking proofs on verifiable presentations . Some cryptographic identifiers contain all necessary metadata in the identifier itself. In those cases, no additional metadata is required. Other identifiers use verifiable data registries where such metadata is automatically published for use by verifiers , without any additional action by the holder . See the Verifiable Credentials Implementation Guidelines 1.0 and Verifiable Credentials Use Cases for additional examples related to subject and holder . Note : Validation is the process of applying business rules Validation is the process by which verifiers apply business rules to evaluate the propriety of a particular use of a verifiable credential . A verifier might need to validate a given verifiable presentation against complex business rules; for example, the verifier might need confidence that the holder is the same entity as a subject of a verifiable credential . In such a situation, the following factors can provide a verifier with reasonable confidence that the claims expressed regarding that identifier, in included verifiable credentials , are, in fact, about the current presenter: The verifiable presentation is secured, using a mechanism the verifier trusts to protect the integrity of the content. The verifiable presentation includes one or more verifiable credentials that are secured, using a mechanism the verifier trusts to protect the integrity of the content. The identifier in the holder property of the verifiable presentation and at least one identifier property of at least one object in the credentialSubject array are the same. That common identifier can be used to discover or derive the verification material used to verify the integrity of that verifiable presentation . B.5 Issuance Date This section is non-normative. The validFrom is expected to be within an expected range for the verifier . For example, a verifier can check that the start of the validity period for a verifiable credential is not in the future. B.6 Proofs (Signatures) This section is non-normative. The securing mechanism used to prove that the information in a verifiable credential or verifiable presentation was not tampered with is called a cryptographic proof . There are many types of cryptographic proofs including, but not limited to, digital signatures and zero-knowledge proofs. In general, when verifying cryptographic proofs, implementations are expected to ensure: The cryptographic proof is available in a form defined by a known cryptographic suite. All required cryptographic proof properties are present. The cryptographic proof verification algorithm, when applied to the data, results in an accepted cryptographic proof. In general, when verifying digital signatures, implementations are expected to ensure: Acceptably recent metadata regarding the verification material associated with the signature is available. For example, if the verification material is a cryptographic public key, the metadata might include properties related to the validity period, the controller, or the authorized purpose, such as authentication or encryption, of the cryptographic public key. The public key is not suspended, revoked, or expired. The digital signature verifies. Any additional requirements defined by the securing mechanism are satisfied. B.7 Validity Periods This section is non-normative. The verifier expects that the validFrom and validUntil properties will be within a certain range. For example, a verifier can check that the end of the validity period of a verifiable credential is not in the past. Because some credentials can be useful for secondary purposes even if their original validity period has expired, validity period, as expressed using the validFrom and validUntil properties, is always considered a component of validation, which is performed after verification. B.8 Status This section is non-normative. If the credentialStatus property is available, the status of a verifiable credential is expected to be evaluated by the verifier according to the credentialStatus type definition for the verifiable credential and the verifier's own status evaluation criteria. For example, a verifier can ensure the status of the verifiable credential is not "withdrawn for cause by the issuer ". B.9 Schema This section is non-normative. If the credentialSchema property is available, the schema of a verifiable credential is expected to be evaluated by the verifier according to the credentialSchema type definition for the verifiable credential and the verifier's own schema evaluation criteria. For example, if the credentialSchema 's type value is [ VC-JSON-SCHEMA ], then a verifier can ensure a credential's data is valid against the given JSON Schema. B.10 Fitness for Purpose This section is non-normative. Fitness for purpose is about whether the custom properties in the verifiable credential are appropriate for the verifier's purpose. For example, if a verifier needs to determine whether a subject is older than 21 years of age, they might rely on a specific birthdate property , or on more abstract properties , such as ageOver . The issuer is trusted by the verifier to make the claims at hand. For example, a franchised fast food restaurant location trusts the discount coupon claims made by the corporate headquarters of the franchise. Policy information expressed by the issuer in the verifiable credential should be respected by holders and verifiers unless they accept the liability of ignoring the policy. B.11 "Artificial Intelligence" and "Machine Learning" This section is non-normative. Systems using what is today commonly referred to as "artificial intelligence" and/or "machine learning" might be capable of performing complex tasks at a level that meets or exceeds human performance. This might include tasks such as the acquisition and use of verifiable credentials . Using such tasks to distinguish between human and automated "bot" activity, as is commonly done today with a CAPTCHA , for instance, might thereby cease to provide adequate or acceptable protection. Implementers of security architectures that use verifiable credentials and/or perform validation on their content are urged to consider the existence of machine-based actors, such as those which are today commonly referred to as "artificial intelligence", that might legitimately hold verifiable credentials for use in interactions with other systems. Implementers might also consider how threat actors could couple such "artificial intelligence" systems with verifiable credentials to pose as humans when interacting with their systems. Such systems might include, but not be limited to, global infrastructure such as social media, election, energy distribution, supply chain, and autonomous vehicle systems. C. Contexts, Vocabularies, Types, and Credential Schemas C.1 Base Context Implementations MUST treat the base context value, located at https://www.w3.org/ns/credentials/v2 , as already retrieved; the following value is the hexadecimal encoded SHA2-256 digest value of the base context file: 59955ced6697d61e03f2b2556febe5308ab16842846f5b586d7f1f7adec92734 . It is possible to confirm the cryptographic digest above by running the following command from a modern Unix command interface line: curl -s https://www.w3.org/ns/credentials/v2 | openssl dgst -sha256 . It is strongly advised that all JSON-LD Context URLs used by an application use the same mechanism, or a functionally equivalent mechanism, to ensure end-to-end security. Implementations are expected to throw errors if a cryptographic hash value for a resource does not match the expected hash value. Implementations that apply the base context above, as well as other contexts and values in any @context property, during operations such as JSON-LD Expansion or transformation to RDF , are expected to do so without experiencing any errors. If such operations are performed and result in an error, the verifiable credential or verifiable presentation MUST result in a verification failure. Note : See errata if hash value changes are detected It is extremely unlikely that the files that have associated cryptographic hash values in this specification will change. However, if critical errata are found in the specification and corrections are required to ensure ecosystem stability, the cryptographic hash values might change. As such, the HTTP cache times for the files are not set to infinity and implementers are advised to check for errata if a cryptographic hash value change is detected. This section serves as a reminder of the importance of ensuring that, when verifying verifiable credentials and verifiable presentations , the verifier has information that is consistent with what the issuer or holder had when securing the credential or presentation . This information might include at least: The contents of the credential itself, which are secured in verifiable credentials and verifiable presentations by using securing mechanisms. See Section 4.12 Securing Mechanisms for further information. The content in a credential whose meaning depends on a link to an external URL, such as a JSON-LD Context, which can be secured by using a local static copy or a cryptographic digest of the file. See Section 5.3 Integrity of Related Resources for more details. Verifiers are warned that other data that is referenced from within a credential , such as resources that are linked to via URLs, are not cryptographically protected by default. It is considered a best practice to ensure that the same sorts of protections are provided for any URL that is critical to the security of the verifiable credential through the use of permanently cached files and/or cryptographic hashes. Ultimately, knowing the cryptographic digest of any linked external content enables a verifier to confirm that the content is the same as what the issuer or holder intended. C.2 Vocabularies Implementations that depend on RDF vocabulary processing MUST ensure that the following vocabulary URLs used in the base context ultimately resolve to the following files when loading the JSON-LD serializations, which are normative. Other semantically equivalent serializations of the vocabulary files MAY be used by implementations. A cryptographic hash is provided for each JSON-LD document to ensure that developers can verify that the content of each file is correct. JSON-LD Documents and Hashes URL: https://www.w3.org/2018/credentials# Resolved Document: https://www.w3.org/2018/credentials/index.jsonld SHA2-256 Digest: 9db03c54d69a8ec3944f10770e342b33e58a79045c957c35d51285976fc467c4 URL: https://w3id.org/security# Resolved Document: https://w3c.github.io/vc-data-integrity/vocab/security/vocabulary.jsonld SHA2-256 Digest: c7a06ccc144d9d72f435f64802fdfb802a32aefe8b0bcb7504f69754b8c0faeb It is possible to confirm the cryptographic digests listed above by running a command like the following, replacing <DOCUMENT_URL> with the appropriate value, through a modern UNIX-like OS command line interface: curl -sL -H "Accept: application/ld+json" <DOCUMENT_URL> | openssl dgst -sha256 Note : schema.org changes regularly, but is considered stable Implementers and document authors might note that cryptographic digests for schema.org are not provided. This is because the schema.org vocabulary undergoes regular changes; any digest provided would be out of date within weeks of publication. The Working Group discussed this concern and concluded that the vocabulary terms from schema.org , that are used by this specification, have been stable for years and are highly unlikely to change in their semantic meaning. The following base classes are defined in this specification for processors and other specifications that benefit from such definitions: Base Class Purpose CredentialEvidence Serves as a superclass for specific evidence types that are placed into the evidence property. CredentialSchema Serves as a superclass for specific schema types that are placed into the credentialSchema property. CredentialStatus Serves as a superclass for specific credential status types that are placed into the credentialStatus property. ConfidenceMethod Serves as a superclass for specific confidence method types that are placed into the confidenceMethod property. RefreshService Serves as a superclass for specific refresh service types that are placed into the credentialRefresh property. RenderMethod Serves as a superclass for specific render method types that are placed into the renderMethod property. TermsOfUse Serves as a superclass for specific terms of use types that are placed into the termsOfUse property. C.3 Datatypes This section defines datatypes that are used by this specification. C.3.1 The sriString Datatype The sriString datatype is associated with a value to provide the integrity information for a resource using the method specified in the Subresource Integrity specification. The sriString datatype is defined as follows: The URL denoting this datatype https://www.w3.org/2018/credentials#sriString The lexical space See the ABNF grammar , defining the integrity attribute in the [ SRI ] specification, for the restrictions on the string format. The value space A (possibly empty) list of (alg,val) pairs, where alg identifies a hash function, and val is an integer as a standard mathematical concept. The lexical-to-value mapping Any element of the lexical space is mapped to the value space by following the parse metadata algorithm based on the ABNF grammar in the [ SRI ] specification. The canonical mapping The canonical mapping consists of the lexical-to-value mapping. C.4 Differences between Contexts, Types, and CredentialSchemas This section is non-normative. The verifiable credential and verifiable presentation data models leverage a variety of underlying technologies including [ JSON-LD11 ] and [ VC-JSON-SCHEMA ]. This section will provide a comparison of the @context , type , and credentialSchema properties, and cover some of the more specific use cases where it is possible to use these features of the data model. The type property is used to uniquely identify the type of the verifiable credential in which it appears, that is, to indicate which set of claims the verifiable credential contains. This property, and the value VerifiableCredential within the set of its values, are mandatory. Whilst it is good practice to include one additional value depicting the unique subtype of this verifiable credential , it is permitted to either omit or include additional type values in the array. Many verifiers will request a verifiable credential of a specific subtype, then omitting the subtype value could make it more difficult for verifiers to inform the holder which verifiable credential they require. When a verifiable credential has multiple subtypes, listing all of them in the type property is sensible. The use of the type property in a [ JSON-LD11 ] representation of a verifiable credential enables to enforce the semantics of the verifiable credential because the machine is able to check the semantics. With [ JSON-LD11 ], the technology is not only describing the categorization of the set of claims, the technology is also conveying the structure and semantics of the sub-graph of the properties in the graph. In [ JSON-LD11 ], this represents the type of the node in the graph which is why some [ JSON-LD11 ] representations of a verifiable credential will use the type property on many objects in the verifiable credential . The primary purpose of the @context property, from a [ JSON-LD11 ] perspective, is to convey the meaning of the data and term definitions of the data in a verifiable credential , in a machine-readable way. The @context property is used to map the globally unique URLs for properties in verifiable credentials and verifiable presentations into short-form alias names, making [ JSON-LD11 ] representations more human-friendly to read. From a [ JSON-LD11 ] perspective, this mapping also allows the data in a credential to be modeled in a network of machine-readable data, by enhancing how the data in the verifiable credential or verifiable presentation relates to a larger machine-readable data graph. This is useful for telling machines how to relate the meaning of data to other data in an ecosystem where parties are unable to coordinate. This property, with the first value in the set being https://www.w3.org/ns/credentials/v2 , is mandatory. Since the @context property is used to map data to a graph data model, and the type property in [ JSON-LD11 ] is used to describe nodes within the graph, the type property becomes even more important when using the two properties in combination. For example, if the type property is not included within the resolved @context resource using [ JSON-LD11 ], it could lead to claims being dropped and/or their integrity no longer being protected during production and consumption of the verifiable credential . Alternatively, it could lead to errors being raised during production or consumption of a verifiable credential . This will depend on the design choices of the implementation and both paths are used in implementations today, so it's important to pay attention to these properties when using a [ JSON-LD11 ] representation of a verifiable credential or verifiable presentation . The primary purpose of the credentialSchema property is to define the structure of the verifiable credential , and the datatypes for the values of each property that appears. A credentialSchema is useful for defining the contents and structure of a set of claims in a verifiable credential , whereas [ JSON-LD11 ] and a @context in a verifiable credential are best used only for conveying the semantics and term definitions of the data, and can be used to define the structure of the verifiable credential as well. While it is possible to use some [ JSON-LD11 ] features to allude to the contents of the verifiable credential , it's not generally suggested to use @context to constrain the data types of the data model. For example, "@type": "@json" is useful for leaving the semantics open-ended and not strictly defined. This can be dangerous if the implementer is looking to constrain the data type of the claims in the credential , and is expected not to be used. When the credentialSchema and @context properties are used in combination, both producers and consumers can be more confident about the expected contents and data types of the verifiable credential and verifiable presentation . D. IANA Considerations This section is non-normative. This section will be submitted to the Internet Engineering Steering Group (IESG) for review, approval, and registration with IANA. D.1 application/vc This specification registers the application/vc media type specifically for identifying documents conforming to the verifiable credentials format. Type name: application Subtype name: vc Required parameters: None Encoding considerations: Resources that use the application/vc media type are required to conform to all of the requirements for the application/ld+json media type and are therefore subject to the same encoding considerations specified in Section 11 of The JavaScript Object Notation (JSON) Data Interchange Format . Security considerations: As defined in the Verifiable Credentials Data Model v2.0 . Contact: W3C Verifiable Credentials Working Group [email protected] Note that while the verifiable credentials format uses JSON-LD conventions, there are a number of constraints and additional requirements for verifiable credential implementations that justify the use of a specific media type. This media type can be used in an enveloping proof to denote the enveloped payload. The credential is expected to be a valid JSON-LD document . Verifiable credentials served with the application/vc media type are expected to have all JSON-LD 1.1 context information, including references to external contexts, within the body of the document. Contexts linked via a http://www.w3.org/ns/json-ld#context HTTP Link Header (see Section 6.1 of JSON-LD 1.1 ) are ignored. D.2 application/vp This specification registers the application/vp media type specifically for identifying documents conforming to the verifiable presentations format. Type name: application Subtype name: vp Required parameters: None Encoding considerations: Resources that use the application/vp media type are required to conform to all of the requirements for the application/ld+json media type and are therefore subject to the same encoding considerations specified in Section 11 of The JavaScript Object Notation (JSON) Data Interchange Format . Security considerations: As defined in Verifiable Credentials Data Model v2.0 . Contact: W3C Verifiable Credentials Working Group [email protected] Note that while the verifiable presentations format uses JSON-LD conventions, there are a number of constraints and additional requirements for verifiable presentation implementations that justify the use of a specific media type. This media type can be used in an enveloping proof to denote the enveloped payload. The presentation is expected to be a valid JSON-LD document . Verifiable presentations served with the application/vp media type are expected to have all JSON-LD 1.1 context information, including references to external contexts, within the body of the document. Contexts linked via a http://www.w3.org/ns/json-ld#context HTTP Link Header (see Section 6.1 of [ JSON-LD11 ]) are ignored. E. Additional Diagrams for Verifiable Presentations This section is non-normative. Figure 14 below is a variant of Figure 9 : a verifiable presentation referring to two verifiable credentials , and using embedded proofs based on [ VC-DATA-INTEGRITY ]. Each verifiable credential graph is connected to its own separate proof graph ; the verifiableCredential property is used to connect the verifiable presentation to the verifiable credential graphs . The presentation proof graph represents the digital signature of the verifiable presentation graph , both verifiable credential graphs , and the proof graphs linked from the verifiable credential graphs . The complete verifiable presentation consists, in this case, of six information graphs . Figure 14 A variant of Figure 9 : information graphs associated with a verifiable presentation referring to two verifiable credentials, using an embedded proof based on Verifiable Credential Data Integrity 1.0 [ VC-DATA-INTEGRITY ]. Figure 15 below shows the same verifiable presentation as Figure 14 , but using an enveloping proof based on [ VC-JOSE-COSE ]. Each verifiable credential graph contains a single EnvelopedVerifiableCredential instance, referring, via a data: URL [ RFC2397 ], to a verifiable credential secured via an enveloping proof . Figure 15 A variant of Figure 10 : information graphs associated with a verifiable presentation referring to two verifiable credentials using enveloping proofs based on JOSE [ VC-JOSE-COSE ]. F. Revision History This section contains the substantive changes that have been made to this specification over time. Changes since the v2.0 Second Candidate Recommendation : Editorial updates to clarify grammar, flow, and understanding of the specification contents. Align required error condition fields between Working Group specifications. Clarify requirements around self-asserted verifiable credentials . Changes since the v2.0 First Candidate Recommendation : Many editorial updates to clarify grammar, flow, and understanding of the specification contents. Required that the verifier check digest values if they are provided by the issuer. Removed the ProblemDetail integer error codes. Removed @vocab from the base context and added warnings about its use in application-specific context files. Added support for two digest formats for resource integrity. Finalized media types for application/vc and application/vp . Updates to the v2 JSON-LD Context to match new additions. Added a section on enveloped verifiable presentations. Changes since the v1.1 Recommendation : Many editorial updates and fixes to modernize the specification and make it easier to understand particular concepts. Remove duplicated statements regarding proof between Data Integrity and this specification. Clarify how issuer validation occurs. Clarify requirements for securing mechanism extension points. Add dependency on [ INFRA ] for algorithm section. Add requirements for securing mechanism specifications. Clarify how to perform type-specific credential processing. Add mechanism to embed enveloped verifiable credentials in verifiable presentations. Add verification algorithm, interface to securing mechanisms, and ProblemDetails objects. Fine tune allowable values for issuer property. Provide more concrete guidance on how to express language information as well as default language and direction. Add new conformance classes for issuer and verifier implementations. Add new Security Considerations regarding key management. Add new Privacy Considerations for trust boundaries, metadata-based correlation, data theft, and use of Oblivious HTTP. Formally define base classes and properties for vocabulary. Provide warnings around not using advanced JSON-LD features in order to maximize interoperability. Provide more explicit guidance around sets and arrays. Add support for name and description properties for issuers and credentials. Add security considerations around interception, replay, and spoofing attacks. Add JWT and SD-JWT claims to base JSON-LD Context. Clarify the difference between a "credential" and a "verifiable credential". Add section on how to ensure ecosystem compatibility. Add section on type-specific credential processing. Add section on validation and relevance to holders. Add section on media type precision and interpretation. Ensure that dateTimeStamp is used for time values. Provide further guidance on proper use of time values and timezones. Make validFrom optional. Add relatedResource feature. Make base context and vocabularies normative and provide cryptographic hashes for their content. Add renderMethod and confidenceMethod to list of reserved properties. Modernize examples in the specification. Add "Getting Started" section. Add table of reserved properties for properties that are not yet standardized or are at risk for removal. Restrict data model serialization to JSON-LD in compacted document form. Update ZKP section to remove older content. Add termsOfUse to presentations in v2 context. Add default vocabulary for undefined terms to v2 context. Add media types for application/vc and application/vp . Provide guidance on converting to and from conforming documents from other digital credential formats. Change reference to URI/IRI to use WHATWG URL specification. Add normative dependency on Data Integrity and JOSE/COSE securing mechanisms. Rename issuanceDate / expirationDate to validFrom / validUntil . Add JSON Schema support and update examples to use new format. Clarify that credentialSubject values cannot be strings. Create more formal vocabulary document that refers to this specification. Define v2.0 JSON-LD Context. Migrate VC-JWT section to separate securing specification. Move Subject-Holder relationships to Verifiable Credential implementation guide. Increment version number to v2.0 and remove prior REC-track comments. Add normative dependency on Verifiable Credential Data Integrity specification [ VC-DATA-INTEGRITY ]. The section on Disputes was removed due to lack of implementations in v1.0 and v1.1. Changes since the v1.0 Recommendation : Add this revision history section. Update previous normative references that pointed to RFC3339 for date-time details to now normatively reference the date-time details described in XMLSCHEMA11-2 which more accurately reflect date-time use in examples and libraries. Loosen the requirement to allow URLs that cannot be dereferenced in the id property of the credentialStatus and refreshService sections of the data model. Loosen normative statements in the zero-knowledge proofs section to enable compliance of new zero-knowledge proof schemes, such as BBS+, that have been created since the v1.0 specification was published as a Recommendation. Update all references to point to the latest version of the referenced specifications. Fix broken links to papers that have become unavailable to updated locations where the papers are available. Increase accessibility of SVG diagrams. Fix editorial bugs in a few examples related to issuer , issuanceDate , credentialStatus , dates, dead links, and minor syntax errors. Move acknowledgements from Status of the Document section into the Acknowledgements appendix. G. Acknowledgements This section is non-normative. The Working Group thanks the following individuals not only for their contributions toward the content of this document, but also for yeoman's work in this standards community that drove changes, discussion, and consensus among a sea of varied opinions: David Chadwick, Dave Longley, Ted Thibodeau Jr., Brent Zundel, Ivan Herman, Joe Andrieu, and Gabe Cohen. Work on this specification has been supported by the Rebooting the Web of Trust community facilitated by Christopher Allen, Shannon Appelcline, Kiara Robles, Brian Weller, Betty Dhamers, Kaliya Young, Manu Sporny, Drummond Reed, Joe Andrieu, Heather Vescent, Kim Hamilton Duffy, Samantha Chase, Andrew Hughes, Will Abramson, Erica Connell, Eric Schuh, Zaïda Rivai, and Shigeya Suzuki. The participants in the Internet Identity Workshop, facilitated by Phil Windley, Kaliya Young, Doc Searls, and Heidi Nobantu Saul, also supported the refinement of this work through numerous working sessions designed to educate about, debate on, and improve this specification. The Working Group also thanks our Working Group Chairs, Dan Burnett, Matt Stone, Brent Zundel, Wayne Chang, and Kristina Yasuda, as well as our W3C Staff Contacts, Kazuyuki Ashimura and Ivan Herman, for their expert management and steady guidance of the group through multiple W3C standardization cycles. We also thank the Chairs of the W3C Credentials Community Group, Christopher Allen, Joe Andrieu, Kim Hamilton Duffy, Heather Vescent, Wayne Chang, Mike Prorock, Harrison Tang, Kimberly Wilson Linson, and Will Abramson, who oversaw the incubation of a number of work items that were incorporated into this specification. Portions of the work on this specification have been funded by the United States Department of Homeland Security's Science and Technology Directorate under contracts HSHQDC-17-C-00019, 70RSAT20T00000010/P00001, 70RSAT20T00000029, 70RSAT21T00000016/P00001, 70RSAT23T00000005, 70RSAT23C00000030, 70RSAT23R00000006, 70RSAT24T00000014, 70RSAT22T00000001, and the National Science Foundation under NSF 22-572. The content of this specification does not necessarily reflect the position or the policy of the U.S. Government and no official endorsement should be inferred. The Working Group would like to thank the following individuals for reviewing and providing feedback on the specification (in alphabetical order by first name or their Github handle if a name was not provided): Abhishek Mahadevan Raju, Adam C. Migus, Addison Phillips, Adrian Gropper, Aisp-GitHub , Alen Horvat, Alexander Mühle, AlexAndrei98 , Allen Brown, Amy Guy, Andor Kesselman, Andres Paglayan, Andres Uribe, Andrew Hughes, Andrew Jones, Andrew Whitehead, Andy Miller, Anil John, Anthony Camilleri, Anthony Nadalin, Benjamin Collins, Benjamin Goering, Benjamin Young, Bert Van Nuffelen, Bohdan Andriyiv, Brent Zundel, Brian Richter, Bruno Zimmermann, caribouW3 , cdr , Chaoxinhu , Charles "Chaals" McCathieNevile, Charles E. Lehner, Chris Abernethy, Chris Buchanan, Christian Lundkvist, Christine Lemmer-Webber, Christoph Lange, Christopher Allen, Christopher Lemmer Webber, ckennedy422 , Clare Nelson, confiks , Dan Brickley, Daniel Buchner, Daniel Burnett, Daniel Hardman, Darrell O'Donnell, Dave Longley, David Ammouial, David Chadwick, David Ezell, David Hyland-Wood, David I. Lehn, David Janes, David Waite, Denis Ah-Kang, Denisthemalice , Devin Rousso, Dmitri Zagidulin, Dominique Hazael-Massieux, Drummond Reed, Emmanuel , enuoCM , Eric Elliott, Eric Korb, Eric Prud'hommeaux, etaleo , Evstifeev Roman, Fabricio Gregorio, Filip Kolarik, Gabe Cohen, Ganesh Annan, George Aristy, glauserr , Golda Velez, Grace Huang, Grant Noble, Greg Bernstein, Gregg Kellogg, Heather Vescent, Henry Andrews, Henry Story, Ian B. Jacobs, Ilan , Isaac Henderson, isaackps , Iso5786 , Ivan Herman, Jace Hensley, Jack Tanner, James Schoening, Janina Sajka, Jan Forster Cognizone, Jeff Burdges, Jeffrey Yasskin, Jim Masloski, Jim St.Clair, Joe Andrieu, Joel Gustafson, Joel Thorstensson, John Tibbetts, Jonathan Holt, José San Juan, Juan Caballero, Julien Fraichot, Justin Richer, Kaan Uzdoğan, Kaliya Young, Kazuyuki Ashimura, Ken Ebert, Kendall Weihe, Kerri Lemoie, Kevin Dean, Kevin Griffin, Kim Hamilton Duffy, Konstantin Tsabolov, Kristijan Sedlak, Kristina Yasuda, Kyle Den Hartog, Lal Chandran, Lance , Lautaro Dragan, Leonard Rosenthol, Liam Missin, Liam Quin, Line Kofoed, Lionel Wolberger, Logan Porter, Lovesh Harchandani, Lukas J. Han, Mahmoud Alkhraishi, Maik Riechert, Manu Sporny, Marcel Jackisch, Mark Foster, Mark Harrison, Mark Moir, Markus Sabadello, Martin Thomson, Marty Reed, Matt Peterson, Matt Stone, Matthew Peterson, Matthieu Bosquet, Matti Taimela, Melvin Carvalho, Michael B. Jones, Michael Herman, Michael Lodder, Michael Richardson, Mike Prorock, Mike Varley, Mircea Nistor, MIZUKI Sonoko / Igarashi, nage , Nate Otto, Nathan George, Niclas Mietz, Niko Lockenvitz, Nikos Fotiou, Nis Jespersen, Oliver Terbu, Pat McBennett, Patrick St-Louis, Paul Bastian, Paul F. Dietrich, Paulo Jorge Q. Ferreira, Pelle Braendgaard, Pete Rowley, Phil Archer, Phillip Long, Pierre-Antoine Champin, Rajesh Rathnam, Ralph Swick, Renato Iannella, Reto Gmür, Reza Soltani, Richard Bergquist, Richard Ishida, Richard Varn, Rieks Joosten, RorschachRev , Ryan Grant, Samuel Müller, Samuel Smith, Sarven Capadisli, Sebastian Crane, Sebastian Elfors, Shawn Butterfield, Shigeya Suzuki, Sho Nakatani, Shuji Kamitsuna, Snorre Lothar von Gohren Edwin, Sten Reijers, Stephen Curran, Steve Huguenin, Steve McCown, Steven Rowat, Taro , tcibm , Ted Thibodeau Jr., Tim Bouma, Timo Glastra, Tobias Käfer, Tobias Looker, Tom Jones, Torsten Lodderstedt, Tzviya Siegman, Victor Dods, Vincent Kelleher, Vladimir Alexiev, Víctor Herraiz Posada, Wayne Chang, whatisthejava , Will Abramson, William Entriken, and Yancy Ribbens. H. References H.1 Normative references [i18n-glossary] Internationalization Glossary . Richard Ishida; Addison Phillips. W3C. 17 October 2024. W3C Working Group Note. URL: https://www.w3.org/TR/i18n-glossary/ [INFRA] Infra Standard . Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/ [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-LD11-API] JSON-LD 1.1 Processing Algorithms and API . Gregg Kellogg; Dave Longley; Pierre-Antoine Champin. W3C. 16 July 2020. W3C Recommendation. URL: https://www.w3.org/TR/json-ld11-api/ [RFC2119] Key words for use in RFCs to Indicate Requirement Levels . S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/info/rfc2119/ [RFC2397] The "data" URL scheme . L. Masinter. IETF. August 1998. Proposed Standard. URL: https://www.rfc-editor.org/info/rfc2397/ [RFC6838] Media Type Specifications and Registration Procedures . N. Freed; J. Klensin; T. Hansen. IETF. January 2013. Best Current Practice. URL: https://www.rfc-editor.org/info/rfc6838/ [RFC8174] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words . B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/info/rfc8174/ [RFC9457] Problem Details for HTTP APIs . M. Nottingham; E. Wilde; S. Dalal. IETF. July 2023. Proposed Standard. URL: https://www.rfc-editor.org/info/rfc9457/ [SRI] Subresource Integrity . Frederik Braun. W3C. 20 March 2026. W3C Working Draft. URL: https://www.w3.org/TR/sri-2/ [URL] URL Standard . Anne van Kesteren. WHATWG. Living Standard. URL: https://url.spec.whatwg.org/ [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-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/ [XMLSCHEMA11-2] W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes . David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. W3C. 5 April 2012. W3C Recommendation. URL: https://www.w3.org/TR/xmlschema11-2/ H.2 Informative references [BCP47] Tags for Identifying Languages . A. Phillips, Ed.; M. Davis, Ed. IETF. September 2009. Best Current Practice. URL: https://www.rfc-editor.org/info/rfc5646/ [CID] Controlled Identifiers v1.0 . Michael Jones; Manu Sporny. W3C. 15 May 2025. W3C Recommendation. URL: https://www.w3.org/TR/cid-1.0/ [DID] 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/ [ETSI-TRUST-LISTS] Electronic Signatures and Infrastructures (ESI); Trusted Lists . ETSI. ETSI. ETSI Standard TS 119 612 V2.1.1 (2015-07). URL: https://www.etsi.org/deliver/etsi_ts/119600_119699/119612/02.01.01_60/ts_119612v020101p.pdf [JSON] The JavaScript Object Notation (JSON) Data Interchange Format . T. Bray, Ed. IETF. December 2017. Internet Standard. URL: https://www.rfc-editor.org/info/rfc8259/ [LD-BP] Best Practices for Publishing Linked Data . Bernadette Hyland; Ghislain Auguste Atemezing; Boris Villazón-Terrazas. W3C. 9 January 2014. W3C Working Group Note. URL: https://www.w3.org/TR/ld-bp/ [LINKED-DATA] Linked Data Design Issues . Tim Berners-Lee. W3C. 27 July 2006. W3C-Internal Document. URL: https://www.w3.org/DesignIssues/LinkedData.html [RDF-SCHEMA] RDF Schema 1.1 . Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/ [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/ [RFC7049] Concise Binary Object Representation (CBOR) . C. Bormann; P. Hoffman. IETF. October 2013. Proposed Standard. URL: https://www.rfc-editor.org/info/rfc7049/ [RFC7159] The JavaScript Object Notation (JSON) Data Interchange Format . T. Bray, Ed. IETF. March 2014. Proposed Standard. URL: https://www.rfc-editor.org/info/rfc7159/ [RFC7231] Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content . R. Fielding, Ed.; J. Reschke, Ed. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html [RFC9110] HTTP Semantics . R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed. IETF. June 2022. Internet Standard. URL: https://httpwg.org/specs/rfc9110.html [SCHEMA-ORG] Schema.org . W3C Schema.org Community Group. W3C. 6.0. URL: https://schema.org/ [SD-JWT-VC] SD-JWT-based Verifiable Digital Credentials . Oliver Terbu; Daniel Fett; Brian Campbell. Internet Engineering Task Force. Internet-Draft. URL: https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/ [STRING-META] Strings on the Web: Language and Direction Metadata . Richard Ishida; Addison Phillips. W3C. 16 July 2026. FPWD. URL: https://www.w3.org/TR/string-meta/ [VC-BARCODES] Verifiable Credential Barcodes v1.0 . Wesley Smith; Elaine Wooton; Manu Sporny. W3C. 22 August 2026. W3C Working Draft. URL: https://www.w3.org/TR/vc-barcodes-1.0/ [VC-CONFIDENCE-METHOD] Verifiable Credential Confidence Methods v1.0 . Joe Andrieu; Denken Chen. W3C. 17 August 2026. W3C Working Draft. URL: https://www.w3.org/TR/vc-confidence-method/ [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-EXTENSIONS] Verifiable Credential Extensions . Manu Sporny. W3C Verifiable Credentials Working Group. W3C Editor's Draft. URL: https://w3c.github.io/vc-extensions/ [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-JSON-SCHEMA] Verifiable Credentials JSON Schema Specification . Gabe Cohen; Orie Steele. W3C Verifiable Credentials Working Group. FPWD. URL: https://www.w3.org/TR/vc-json-schema/ [VC-OVERVIEW] Verifiable Credentials Overview v1.0 . Ivan Herman. W3C. 30 July 2026. W3C Working Group Note. URL: https://www.w3.org/TR/vc-overview-1.0/ [VC-RENDER-METHOD] Verifiable Credential Rendering Methods v1.0 . Dmitri Zagidulin; Manu Sporny; Patrick St-Louis; Isaac Koh. W3C. 22 August 2026. W3C Working Draft. URL: https://www.w3.org/TR/vc-render-method/ [VC-USE-CASES] Verifiable Credentials Use Cases . Joe Andrieu; Kevin Dean. W3C. 18 March 2026. W3C Working Group Note. URL: https://www.w3.org/TR/vc-use-cases/ [WCAG21] Web Content Accessibility Guidelines (WCAG) 2.1 . Michael Cooper; Andrew Kirkpatrick; Joshue O'Connor; Alastair Campbell. W3C. 6 May 2025. W3C Recommendation. URL: https://www.w3.org/TR/WCAG21/ ↑ Permalink Referenced in: § 1.3 Conformance (2) (3) (4) (5) (6) § 3. Core Data Model § Semantic Interoperability (2) (3) § 5.3 Integrity of Related Resources § 5.8 Representing Time § 5.11 Ecosystem Compatibility (2) (3) (4) (5) (6) § 5.13 Securing Mechanism Specifications (2) (3) (4) (5) § Restrictions on JSON-LD (2) § 6.3 Type-Specific Credential Processing (2) (3) (4) (5) (6) § 7.1 Verification (2) (3) (4) Permalink Referenced in: § 1.3 Conformance § 4.1 Getting Started Permalink Referenced in: § 1.3 Conformance § 5.3 Integrity of Related Resources (2) § 7.1 Verification Permalink exported Referenced in: § Abstract § 1.1 What is a Verifiable Credential? (2) (3) (4) (5) § 1.2 Ecosystem Overview (2) (3) (4) § 2. Terminology (2) (3) (4) (5) (6) (7) (8) (9) (10) § 3. Core Data Model § 3.1 Claims (2) (3) (4) (5) (6) (7) (8) (9) § 3.2 Credentials (2) (3) (4) (5) § 3.3 Presentations (2) § 4.4 Identifiers § 4.6 Names and Descriptions § 4.8 Credential Subject (2) (3) § Presentations Using Derived Credentials (2) § Presentations Including Holder Claims (2) (3) (4) (5) § 5.1 Trust Model (2) (3) § 6.1 JSON-LD § 6.3 Type-Specific Credential Processing § A.1 Target Threats § A.2 Implementation Threats § B.1 Credential Type (2) (3) (4) § B.10 Fitness for Purpose (2) Permalink exported Referenced in: § 1. Introduction (2) (3) (4) (5) § 1.1 What is a Verifiable Credential? (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) § 1.2 Ecosystem Overview (2) § 2. Terminology (2) (3) (4) § 3. Core Data Model (2) (3) § 3.2 Credentials (2) (3) (4) (5) § 3.3 Presentations (2) (3) (4) (5) § 4.2 Verifiable Credentials § 4.5 Types (2) (3) (4) § 4.6 Names and Descriptions (2) (3) (4) (5) (6) (7) (8) (9) § 4.7 Issuer § 4.9 Validity Period (2) (3) (4) § 4.10 Status (2) (3) (4) (5) § 4.11 Data Schemas (2) § 4.12 Securing Mechanisms (2) § 5.1 Trust Model (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) § 5.2 Extensibility (2) § 5.4 Refreshing (2) (3) § 5.5 Terms of Use § 5.6 Evidence (2) (3) (4) § 5.7 Zero-Knowledge Proofs (2) § 8.1 Data First Approaches (2) (3) § A.1 Target Threats § A.2 Implementation Threats (2) (3) (4) (5) § A.3 Deployment Threats (2) (3) (4) § A.4 External Threats § A.5 Dependency Threats § Private Browsing (2) § C.1 Base Context (2) § C.4 Differences between Contexts, Types, and CredentialSchemas (2) Permalink Referenced in: § 4.4 Identifiers (2) (3) (4) (5) (6) (7) (8) § 4.7 Issuer Permalink Referenced in: § 2. Terminology § 3.2 Credentials § 3.3 Presentations § 4.13 Verifiable Presentations § 5.12 Verifiable Credential Graphs § 5.13 Securing Mechanism Specifications Permalink Referenced in: § 1.2 Ecosystem Overview (2) (3) (4) (5) § 2. Terminology (2) (3) (4) § 3.2 Credentials § 3.3 Presentations (2) (3) § 5.1 Trust Model (2) § 5.2 Extensibility § A.3 Deployment Threats Permalink Referenced in: § 2. Terminology (2) (3) § 3.1 Claims (2) § 3.2 Credentials (2) (3) (4) § 3.3 Presentations (2) (3) (4) (5) (6) § 5.2 Extensibility § 5.12 Verifiable Credential Graphs § E. Additional Diagrams for Verifiable Presentations (2) (3) Permalink exported Referenced in: § Abstract § 1.1 What is a Verifiable Credential? § 1.2 Ecosystem Overview (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) § 2. Terminology (2) (3) § 3.3 Presentations (2) (3) (4) § 4.4 Identifiers (2) § 4.10 Status § 4.13 Verifiable Presentations (2) § Presentations Using Derived Credentials § Presentations Including Holder Claims (2) (3) § 5.1 Trust Model (2) (3) (4) (5) (6) (7) (8) (9) § 5.4 Refreshing (2) (3) (4) (5) (6) § 5.5 Terms of Use (2) (3) § 5.7 Zero-Knowledge Proofs (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) § Notable JSON-LD Features § A.2 Implementation Threats (2) (3) § A.3 Deployment Threats (2) (3) (4) (5) (6) (7) (8) (9) § A.4 External Threats (2) (3) § Bearer Credentials (2) (3) (4) § Private Browsing § B.1 Credential Type (2) (3) § B.2 Credential Subject (2) (3) (4) (5) (6) § B.4 Holder (2) (3) (4) (5) (6) § B.10 Fitness for Purpose § C.1 Base Context (2) Permalink exported Referenced in: § Abstract (2) § 1.1 What is a Verifiable Credential? (2) (3) § 1.2 Ecosystem Overview (2) (3) (4) (5) (6) § 2. Terminology (2) (4) (5) § 3.2 Credentials § 3.3 Presentations (2) (3) § 4.4 Identifiers (2) § 4.6 Names and Descriptions § 4.7 Issuer (2) § 4.10 Status (2) (3) (4) § 4.11 Data Schemas (2) § Presentations Using Derived Credentials § Presentations Including Holder Claims (2) § 5.1 Trust Model (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) (17) (18) § 5.3 Integrity of Related Resources (2) (3) (4) § 5.4 Refreshing (2) (3) (4) (5) § 5.5 Terms of Use (2) (3) (4) (5) § 5.6 Evidence (2) (3) (4) § 5.7 Zero-Knowledge Proofs (2) (3) (4) (5) § Notable JSON-LD Features § 6.3 Type-Specific Credential Processing § A.1 Target Threats § A.2 Implementation Threats (2) § A.3 Deployment Threats (2) (3) (4) § Bearer Credentials § B.1 Credential Type § B.3 Issuer (2) § B.8 Status § B.10 Fitness for Purpose (2) § C.1 Base Context (2) Permalink Referenced in: § 2. Terminology (2) § 3.2 Credentials § 3.3 Presentations (2) § 5.12 Verifiable Credential Graphs § Notable JSON-LD Features Permalink exported Referenced in: § 1.1 What is a Verifiable Credential? § 1.2 Ecosystem Overview § 2. Terminology § 3. Core Data Model (2) (3) § 3.3 Presentations (2) (3) (4) (5) (6) (7) § 4.5 Types § 5.5 Terms of Use § 5.7 Zero-Knowledge Proofs § 5.12 Verifiable Credential Graphs (2) (3) § A.2 Implementation Threats (2) § A.3 Deployment Threats § A.4 External Threats § Private Browsing § B.1 Credential Type § C.1 Base Context § E. Additional Diagrams for Verifiable Presentations Permalink exported Referenced in: § 1.2 Ecosystem Overview § 2. Terminology (3) § 5.1 Trust Model (2) § A.4 External Threats Permalink exported Referenced in: § 2. Terminology § 5.7 Zero-Knowledge Proofs Permalink exported Referenced in: § 5.7 Zero-Knowledge Proofs (2) Permalink exported Referenced in: § 1.1 What is a Verifiable Credential? (2) (3) § 1.2 Ecosystem Overview (2) (3) (4) (5) (6) § 2. Terminology (2) (3) (4) (5) (6) (7) (8) § 3.1 Claims (2) (3) § 3.3 Presentations (2) § 4.2 Verifiable Credentials § 4.4 Identifiers (2) § 4.5 Types § 4.8 Credential Subject (2) (3) (4) (5) (6) (7) § 4.10 Status § Presentations Including Holder Claims (2) § 5.1 Trust Model (2) § 5.6 Evidence (2) § 5.7 Zero-Knowledge Proofs (2) (3) § 5.9 Authorization (2) § A.1 Target Threats (2) § A.3 Deployment Threats (2) (3) § A.4 External Threats § Bearer Credentials § B.2 Credential Subject (2) (3) § B.4 Holder (2) § B.10 Fitness for Purpose Permalink exported Referenced in: § 1.1 What is a Verifiable Credential? § 1.2 Ecosystem Overview § 4.5 Types § 4.10 Status § 4.13 Verifiable Presentations § 6. Syntaxes (2) § B. Validation (2) Permalink exported Referenced in: § Abstract (2) § 1. Introduction (2) (3) § 1.1 What is a Verifiable Credential? (2) (3) (4) (5) (6) (7) (8) (9) § 1.2 Ecosystem Overview (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) § 1.3 Conformance § 2. Terminology (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) § 3. Core Data Model (2) (3) § 3.2 Credentials (2) (3) (4) (5) (6) (7) (8) § 3.3 Presentations (2) (3) (4) (5) (6) (7) § 4.1 Getting Started (2) (3) (4) § 4.2 Verifiable Credentials (2) (3) § 4.3 Contexts (2) (3) § 4.4 Identifiers (2) (3) (4) (5) (6) (7) (8) (9) § 4.5 Types (2) (3) (4) (5) § 4.7 Issuer (2) § 4.8 Credential Subject (2) (3) § 4.9 Validity Period (2) § 4.10 Status (2) § 4.11 Data Schemas (2) (3) (4) (5) § 4.12 Securing Mechanisms (2) § 4.13 Verifiable Presentations (2) (3) § Enveloped Verifiable Credentials (2) (3) (4) § Presentations Using Derived Credentials (2) (3) (4) (5) § Presentations Including Holder Claims (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) § 5. Advanced Concepts § 5.1 Trust Model (2) (3) (4) (5) § 5.2 Extensibility (2) (3) (4) (5) (6) § 5.3 Integrity of Related Resources (2) (3) (4) (5) § 5.4 Refreshing (2) (3) (4) (5) (6) (7) (8) (9) (10) § 5.5 Terms of Use (2) (3) (4) (5) (6) (7) (8) § 5.6 Evidence (2) (3) (4) § 5.7 Zero-Knowledge Proofs (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) (17) § 5.8 Representing Time (2) (3) § 5.9 Authorization § 5.12 Verifiable Credential Graphs (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) § 5.13 Securing Mechanism Specifications (2) (3) (4) (5) § 6. Syntaxes (2) § 6.1 JSON-LD § Notable JSON-LD Features (2) (3) § Restrictions on JSON-LD § 6.2 Media Types (2) § Media Type Precision (2) (3) § 6.3 Type-Specific Credential Processing (2) (3) (4) (5) § 7.1 Verification § 8.1 Data First Approaches § A.1 Target Threats § A.2 Implementation Threats (2) § A.3 Deployment Threats (2) (3) (4) (5) § A.4 External Threats (2) § A.5 Dependency Threats § Bearer Credentials (2) (3) § B. Validation § B.1 Credential Type (2) (3) (4) (5) (6) (7) § B.2 Credential Subject (2) (3) § B.3 Issuer § B.4 Holder (2) (3) (4) § B.5 Issuance Date § B.6 Proofs (Signatures) § B.7 Validity Periods § B.8 Status (2) (3) § B.9 Schema (2) § B.10 Fitness for Purpose (2) § B.11 "Artificial Intelligence" and "Machine Learning" (2) (3) (4) § C.1 Base Context (2) (3) (4) § C.4 Differences between Contexts, Types, and CredentialSchemas (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) (17) (18) (19) (20) (21) (22) (23) § D.1 application/vc (2) (3) (4) § E. Additional Diagrams for Verifiable Presentations § F. Revision History Permalink exported Referenced in: § 1.2 Ecosystem Overview (2) § 5.1 Trust Model Permalink exported Referenced in: § 1. Introduction (2) § 1.1 What is a Verifiable Credential? (2) (3) (4) (5) § 1.2 Ecosystem Overview (2) § 1.3 Conformance § 2. Terminology (2) (3) (4) (5) § 3. Core Data Model (2) (3) § 3.3 Presentations (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) § 4.3 Contexts (2) § 4.4 Identifiers § 4.5 Types (2) (3) (4) § 4.13 Verifiable Presentations (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) § Enveloped Verifiable Credentials (2) (3) § Enveloped Verifiable Presentations (2) (3) (4) § Presentations Using Derived Credentials § Presentations Including Holder Claims (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) § 5.4 Refreshing (2) § 5.5 Terms of Use (2) § 5.7 Zero-Knowledge Proofs (2) (3) (4) § 5.13 Securing Mechanism Specifications (2) (3) (4) (5) § 6. Syntaxes (2) § Notable JSON-LD Features § Restrictions on JSON-LD § Media Type Precision (2) (3) § 6.3 Type-Specific Credential Processing (2) § 7.1 Verification § A.2 Implementation Threats § A.3 Deployment Threats § A.4 External Threats § B. Validation § B.2 Credential Subject § B.3 Issuer § B.4 Holder (2) (3) (4) (5) (6) (7) § B.6 Proofs (Signatures) § C.1 Base Context (2) (3) § C.4 Differences between Contexts, Types, and CredentialSchemas (2) (3) (4) (5) § D.2 application/vp (2) (3) (4) § E. Additional Diagrams for Verifiable Presentations (2) (3) (4) (5) (6) Permalink exported Referenced in: § 1. Introduction § 1.1 What is a Verifiable Credential? (2) (3) § 1.2 Ecosystem Overview (2) § 1.3 Conformance § 2. Terminology § 4.5 Types § 4.7 Issuer § 4.11 Data Schemas § 4.13 Verifiable Presentations § 6. Syntaxes § 7. Algorithms § B.2 Credential Subject § B.6 Proofs (Signatures) Permalink exported Referenced in: § Abstract § 1.1 What is a Verifiable Credential? (2) (3) (4) § 1.2 Ecosystem Overview (2) § 2. Terminology (2) (4) (5) (6) § 3.3 Presentations (2) (3) § 4.5 Types (2) § 4.10 Status (2) § 4.11 Data Schemas (2) § 4.13 Verifiable Presentations (2) (3) § Presentations Using Derived Credentials § 5.1 Trust Model (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) § 5.2 Extensibility § 5.3 Integrity of Related Resources (2) § 5.4 Refreshing (2) (3) (4) (5) § 5.5 Terms of Use (2) (3) § 5.6 Evidence (2) (3) § 5.7 Zero-Knowledge Proofs (2) (3) (4) (5) (6) (7) (8) (9) § A.2 Implementation Threats (2) (3) (4) § A.3 Deployment Threats (2) (3) (4) (5) (6) (7) § A.4 External Threats (2) § B. Validation (2) § B.1 Credential Type (2) (3) (4) (5) (6) (7) § B.2 Credential Subject (2) (3) (4) § B.3 Issuer (2) § B.4 Holder (2) (3) (4) (5) (6) (7) § B.5 Issuance Date (2) § B.7 Validity Periods (2) § B.8 Status (2) (3) § B.9 Schema (2) (3) § B.10 Fitness for Purpose (2) (3) (4) § C.1 Base Context (2) (3) Permalink Referenced in: § 1.2 Ecosystem Overview (2) Permalink Referenced in: § 1.2 Ecosystem Overview (2) (3) (2) (3) § 3.2 Credentials § B.4 Holder § B.6 Proofs (Signatures) (2) Permalink Referenced in: § 4.3 Contexts (2) (3) (4) (5) (6) (7) (8) § 4.4 Identifiers (2) § 4.5 Types § 4.7 Issuer (2) (3) (4) § 4.11 Data Schemas § 4.13 Verifiable Presentations (2) § 7.2 Problem Details § F. Revision History Permalink Referenced in: § 4.3 Contexts (2) (3) (4) § 4.4 Identifiers (2) (3) (4) (5) (6) (7) § 4.5 Types (2) (3) § 4.6 Names and Descriptions (2) (3) § 4.7 Issuer (2) (3) (4) § 4.8 Credential Subject (2) (3) (4) (5) § 4.9 Validity Period (2) (3) (4) (5) (6) § 4.10 Status (2) (3) (4) (5) § 4.11 Data Schemas (2) (3) (4) (5) § 4.13 Verifiable Presentations (2) (3) (4) (5) (6) (7) § Presentations Including Holder Claims (2) (3) (4) (5) § 5.2 Extensibility § Semantic Interoperability (2) § 5.4 Refreshing (2) (3) (4) § 5.5 Terms of Use (2) (3) § 5.6 Evidence (2) (3) (4) (5) (6) (7) § 5.10 Reserved Extension Points § 5.13 Securing Mechanism Specifications § Notable JSON-LD Features § 7.2 Problem Details (2) (3) (4) (5) § Bearer Credentials (2) § B.1 Credential Type § B.2 Credential Subject (2) (3) § B.3 Issuer (2) § B.4 Holder (2) § B.6 Proofs (Signatures) (2) § B.10 Fitness for Purpose (2) (3) Permalink Referenced in: § 3.2 Credentials § 3.3 Presentations (2) (3) (4) (5) § 5.13 Securing Mechanism Specifications (2) (3) (4) § E. Additional Diagrams for Verifiable Presentations (2) (3) Permalink exported Referenced in: § 4.5 Types (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) § 4.10 Status § 5.2 Extensibility § 5.4 Refreshing § 5.5 Terms of Use (2) § B.8 Status § B.9 Schema Permalink exported Referenced in: § A.2 Implementation Threats (2) Permalink exported Referenced in: § 3.2 Credentials § 3.3 Presentations (2) (3) § 4.12 Securing Mechanisms § Enveloped Verifiable Credentials § Enveloped Verifiable Presentations § D.1 application/vc § D.2 application/vp § E. Additional Diagrams for Verifiable Presentations (2) (3) Permalink exported Referenced in: § 3.2 Credentials (2) § 3.3 Presentations (2) § 4.12 Securing Mechanisms § 5.13 Securing Mechanism Specifications § E. Additional Diagrams for Verifiable Presentations (2) Permalink Referenced in: § 3.3 Presentations (2) (3) § E. Additional Diagrams for Verifiable Presentations Permalink exported Referenced in: § 3.2 Credentials (2) § 3.3 Presentations (2) (3) (4) (5) (6) § E. Additional Diagrams for Verifiable Presentations (2) (3) (4) (5) Permalink Referenced in: § 6.3 Type-Specific Credential Processing (2) Permalink Referenced in: § Restrictions on JSON-LD (2) § Lists and Arrays § 6.3 Type-Specific Credential Processing (2) (3) (4) Permalink Referenced in: § 7.1 Verification (2) § 7.2 Problem Details (2) (3) Permalink Referenced in: § A.3 Deployment Threats § Bearer Credentials (2) (3) (4) (5)

Related documents

• latn gap#649807
• grek gap#649808
• mong gap#649809
• nkoo gap#649810
• osge osa gap#649811