Securing Verifiable Credentials using JOSE and COSE

W3C Candidate Recommendation Draft

More details about this document
This version:
https://www.w3.org/TR/2024/CRD-vc-jose-cose-20240521/
Latest published version:
https://www.w3.org/TR/vc-jose-cose/
Latest editor's draft:
https://w3c.github.io/vc-jose-cose/
History:
https://www.w3.org/standards/history/vc-jose-cose/
Commit history
Implementation report:
https://w3c.github.io/vc-jose-cose-test-suite/
Editors:
Michael Jones (Self-Issued Consulting)
Michael Prorock (Mesur.io)
Gabe Cohen (Block)
Former editor:
Orie Steele (Transmute)
Feedback:
GitHub w3c/vc-jose-cose (pull requests, new issue, open issues)
Related Documents
VC Data Model
DID Core

Abstract

This specification defines how to secure credentials and presentations conforming to the Verifiable Credential data model [VC-DATA-MODEL-2.0] with JSON Object Signing and Encryption (JOSE), Selective Disclosure for JWTs [SD-JWT], and CBOR Object Signing and Encryption (COSE) [RFC9052]. This enables the Verifiable Credential data model [VC-DATA-MODEL-2.0] to be implemented with standards for signing and encryption that are widely adopted.

Status of This Document

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

The Working Group is actively seeking implementation feedback for this specification. In order to exit the Candidate Recommendation phase, the Working Group has set the requirement of at least two independent implementations for each mandatory feature in the specification. For details on the conformance testing process, see the test suite listed in the implementation report.

This document was published by the Verifiable Credentials Working Group as a Candidate Recommendation Draft using the Recommendation track.

Publication as a Candidate Recommendation does not imply endorsement by W3C and its Members. A Candidate Recommendation Draft integrates changes from the previous Candidate Recommendation that the Working Group intends to include in a subsequent Candidate Recommendation Snapshot.

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

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 which 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 03 November 2023 W3C Process Document.

1. Introduction

This specification defines how to secure media types expressing Verifiable Credentials and Verifiable Presentations as described in [VC-DATA-MODEL-2.0] using approaches defined by the JOSE, OAuth, and COSE working groups at the IETF. This includes JSON Web Signature (JWS) [RFC7515], Selective Disclosure for JWTs [SD-JWT], and CBOR Object Signing and Encryption (COSE) [RFC9052]. It uses content types [RFC6838] and structured suffixes [MULTIPLE-SUFFIXES] to distinguish between the data types of unsecured documents conforming to [VC-DATA-MODEL-2.0] and the data types of secured documents conforming to [VC-DATA-MODEL-2.0].

JSON Web Signature (JWS) [RFC7515] defines a standard means of digitally signing documents, including JSON documents, using JSON-based data structures. It provides a means to ensure the integrity, authenticity, and non-repudiation of the information contained in the document. Selective Disclosure for JWTs (SD-JWT) [SD-JWT] builds on JWS by also providing a mechanism enabling selective disclosure of document elements. These properties make JWS and SD-JWT especially well suited to securing documents conforming to [VC-DATA-MODEL-2.0].

CBOR Object Signing and Encryption (COSE) [RFC9052] defines a standard means of representing digitally signed data structures using Concise Binary Object Representation (CBOR) [RFC8949]. Like JWS, COSE provides a standardized way to secure the integrity, authenticity, and confidentiality of information. It offers a flexible and extensible set of cryptographic options, allowing for a wide range of algorithms to be used for signing and encryption.

COSE supports two main operations: signing and encryption. For signing, COSE allows the creation of digital signatures over CBOR data using various algorithms such as RSA, ECDSA, and EdDSA. These signatures provide assurance of data integrity and authenticity. COSE also supports encryption, enabling the confidentiality of CBOR data by encrypting it with symmetric or asymmetric encryption algorithms.

2. Terminology

This section defines the terms used in this specification. A link to these terms is included whenever they appear in this specification.

public key
Cryptographic material that can be used to verify digital proofs created with a corresponding private key.
private key
Cryptographic material that can be used to generate digital proofs.
authentication
A process by which an entity can prove to a verifier that it has a specific attribute or controls a specific secret.
decentralized identifier (DID)
A globally unique persistent identifier that does not require a centralized registration authority and is often generated and/or registered cryptographically. The generic format of a DID is defined in [DID-CORE]. Many — but not all — DID methods make use of distributed ledger technology (DLT) or some other form of decentralized network.
controller
An entity that has the capability to make changes to a controller document.
controller document
A set of data that specifies one or more relationships between a controller and a set of data, such as a set of public cryptographic keys.
subject
The entity identified by the id property in a controller document. Anything can be a subject: person, group, organization, physical thing, digital thing, logical thing, etc.
distributed ledger (DLT)
A non-centralized system for recording events. These systems establish sufficient confidence for participants to rely upon the data recorded by others to make operational decisions. They typically use distributed databases where different nodes use a consensus protocol to confirm the ordering of cryptographically signed transactions. The linking of digitally signed transactions over time often makes the history of the ledger effectively immutable.
resource
As defined by [RFC3986]: "...the term 'resource' is used in a general sense for whatever might be identified by a URI." Similarly, any resource might serve as a subject identified by a DID.
verifiable credential
A standard data model and representation format for expressing cryptographically-verifiable digital credentials, as defined by the W3C Verifiable Credentials specification [VC-DATA-MODEL-2.0].
verification method

A set of parameters that can be used together with a process to independently verify a proof. For example, a cryptographic public key can be used as a verification method with respect to a digital signature; in such usage, it verifies that the signer possessed the associated cryptographic private key.

"Verification" and "proof" in this definition are intended to apply broadly. For example, a cryptographic public key might be used during Diffie-Hellman key exchange to negotiate a shared symmetric key for encryption. This guarantees the integrity of the key agreement process. It is thus another type of verification method, even though descriptions of the process might not use the words "verification" or "proof."

verification relationship

An expression of the relationship between the subject and a verification method. An example of a verification relationship is authentication.

3. Securing the VC Data Model

This section outlines how to secure documents conforming to [VC-DATA-MODEL-2.0] using JOSE, SD-JWT, and COSE.

Documents conforming to [VC-DATA-MODEL-2.0], and their associated media types, rely on JSON-LD, which is an extensible format for describing linked data; see JSON-LD Relationship to RDF.

A benefit to this approach is that payloads can be made to conform directly to [VC-DATA-MODEL-2.0] without any mappings or transformation, while at the same time supporting registered header parameters and claims that are understood in the context of JOSE, SD-JWT, and COSE.

It is RECOMMENDED that media types be used to distinguish verifiable credentials and verifiable presentations from other kinds of secured JSON or CBOR.

The most specific media type (or subtype) available SHOULD be used, instead of more generic media types (or supertypes). For example, rather than the general application/sd-jwt, application/vc+ld+json+sd-jwt SHOULD be used, unless there is a more specific media type that would even better identify the secured envelope format.

If implementations do not know which media type to use, media types defined in this specification MUST be used.

3.1 With JOSE

3.1.1 Securing JSON-LD Verifiable Credentials with JOSE

This section details how to use JOSE to secure verifiable credentials conforming to [VC-DATA-MODEL-2.0].

A conforming JWS issuer implementation MUST use [RFC7515] to secure this media type. The unsecured verifiable credential is the unencoded JWS payload.

The typ header parameter SHOULD be vc+ld+json+jwt. When present, the cty header parameter SHOULD be vc+ld+json. See Registered Header Parameter Names for additional details regarding usage of typ and cty.

A conforming JWS verifier implementation MUST use [RFC7515] to verify conforming JWS documents that use this media type.

Example 1: A simple example of a verifiable credential secured with JOSE

Protected Headers

{
  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
  "alg": "ES384"
}

application/vc+ld+json

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/1872",
  "type": [
    "VerifiableCredential",
    "ExampleAlumniCredential"
  ],
  "issuer": "https://university.example/issuers/565049",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSchema": {
    "id": "https://example.org/examples/degree.json",
    "type": "JsonSchema"
  },
  "credentialSubject": {
    "id": "did:example:123",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  }
}

application/vc+ld+json+jwt

eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMzODQifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzE4NzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiRXhhbXBsZUFsdW1uaUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTY2hlbWEiOnsiaWQiOiJodHRwczovL2V4YW1wbGUub3JnL2V4YW1wbGVzL2RlZ3JlZS5qc29uIiwidHlwZSI6Ikpzb25TY2hlbWEifSwiY3JlZGVudGlhbFN1YmplY3QiOnsiaWQiOiJkaWQ6ZXhhbXBsZToxMjMiLCJkZWdyZWUiOnsidHlwZSI6IkJhY2hlbG9yRGVncmVlIiwibmFtZSI6IkJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMifX19.ZIdYJmCnG6oAZ8J5WApDHw0ZcjXM7Drp4z9NUaJTd-sH6ybY17KZe8LRlSshuCVwoIc_pixnAFmVa83VneAID7gKo8nE8jiwRR7nIbKm3_9FtZzshc-lpxi5zvlDfurn

See Verifiable Credentials Data Model v2.0 for more details regarding this example.

3.1.2 Securing JSON-LD Verifiable Presentations with JOSE

This section details how to use JOSE to secure verifiable presentations conforming to [VC-DATA-MODEL-2.0].

A conforming JWS issuer implementation MUST use [RFC7515] to secure this media type. The unsecured verifiable presentation is the unencoded JWS payload.

The typ header parameter SHOULD be vp+ld+json+jwt. When present, the cty header parameter SHOULD be vp+ld+json. See Registered Header Parameter Names for additional details regarding usage of typ and cty.

A conforming JWS verifier implementation MUST use [RFC7515] to verify conforming JWS documents that use this media type.

Credentials in verifiable presentations MUST use the Enveloped Verifiable Credential type defined by the [VC-DATA-MODEL-2.0].

Credentials in verifiable presentations MUST be secured. These credentials are secured using JWS in this case.

Example 2: A simple example of a verifiable presentation secured with JOSE

Protected Headers

{
  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
  "alg": "ES384"
}

application/vp+ld+json

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": "VerifiablePresentation",
  "verifiableCredential": [
    {
      "@context": "https://www.w3.org/ns/credentials/v2",
      "id": "data:application/vc+ld+json+jwt;eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMzODQifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzE4NzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiRXhhbXBsZUFsdW1uaUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTY2hlbWEiOnsiaWQiOiJodHRwczovL2V4YW1wbGUub3JnL2V4YW1wbGVzL2RlZ3JlZS5qc29uIiwidHlwZSI6Ikpzb25TY2hlbWEifSwiY3JlZGVudGlhbFN1YmplY3QiOnsiaWQiOiJkaWQ6ZXhhbXBsZToxMjMiLCJkZWdyZWUiOnsidHlwZSI6IkJhY2hlbG9yRGVncmVlIiwibmFtZSI6IkJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMifX19.d2k4O3FytQJf83kLh-HsXuPvh6yeOlhJELVo5TF71gu7elslQyOf2ZItAXrtbXF4Kz9WivNdztOayz4VUQ0Mwa8yCDZkP9B2pH-9S_tcAFxeoeJ6Z4XnFuL_DOfkR1fP",
      "type": "EnvelopedVerifiableCredential"
    }
  ]
}

application/vp+ld+json+jwt

eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMzODQifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwidHlwZSI6IlZlcmlmaWFibGVQcmVzZW50YXRpb24iLCJ2ZXJpZmlhYmxlQ3JlZGVudGlhbCI6W3siQGNvbnRleHQiOiJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJpZCI6ImRhdGE6YXBwbGljYXRpb24vdmMrbGQranNvbitqd3Q7ZXlKcmFXUWlPaUpGZUVoclFrMVhPV1p0WW10MlZqSTJObTFTY0hWUU1uTlZXVjlPWDBWWFNVNHhiR0Z3VlhwUE9ISnZJaXdpWVd4bklqb2lSVk16T0RRaWZRLmV5SkFZMjl1ZEdWNGRDSTZXeUpvZEhSd2N6b3ZMM2QzZHk1M015NXZjbWN2Ym5NdlkzSmxaR1Z1ZEdsaGJITXZkaklpTENKb2RIUndjem92TDNkM2R5NTNNeTV2Y21jdmJuTXZZM0psWkdWdWRHbGhiSE12WlhoaGJYQnNaWE12ZGpJaVhTd2lhV1FpT2lKb2RIUndPaTh2ZFc1cGRtVnljMmwwZVM1bGVHRnRjR3hsTDJOeVpXUmxiblJwWVd4ekx6RTROeklpTENKMGVYQmxJanBiSWxabGNtbG1hV0ZpYkdWRGNtVmtaVzUwYVdGc0lpd2lSWGhoYlhCc1pVRnNkVzF1YVVOeVpXUmxiblJwWVd3aVhTd2lhWE56ZFdWeUlqb2lhSFIwY0hNNkx5OTFibWwyWlhKemFYUjVMbVY0WVcxd2JHVXZhWE56ZFdWeWN5ODFOalV3TkRraUxDSjJZV3hwWkVaeWIyMGlPaUl5TURFd0xUQXhMVEF4VkRFNU9qSXpPakkwV2lJc0ltTnlaV1JsYm5ScFlXeFRZMmhsYldFaU9uc2lhV1FpT2lKb2RIUndjem92TDJWNFlXMXdiR1V1YjNKbkwyVjRZVzF3YkdWekwyUmxaM0psWlM1cWMyOXVJaXdpZEhsd1pTSTZJa3B6YjI1VFkyaGxiV0VpZlN3aVkzSmxaR1Z1ZEdsaGJGTjFZbXBsWTNRaU9uc2lhV1FpT2lKa2FXUTZaWGhoYlhCc1pUb3hNak1pTENKa1pXZHlaV1VpT25zaWRIbHdaU0k2SWtKaFkyaGxiRzl5UkdWbmNtVmxJaXdpYm1GdFpTSTZJa0poWTJobGJHOXlJRzltSUZOamFXVnVZMlVnWVc1a0lFRnlkSE1pZlgxOS5kMms0TzNGeXRRSmY4M2tMaC1Ic1h1UHZoNnllT2xoSkVMVm81VEY3MWd1N2Vsc2xReU9mMlpJdEFYcnRiWEY0S3o5V2l2TmR6dE9heXo0VlVRME13YTh5Q0Raa1A5QjJwSC05U190Y0FGeGVvZUo2WjRYbkZ1TF9ET2ZrUjFmUCIsInR5cGUiOiJFbnZlbG9wZWRWZXJpZmlhYmxlQ3JlZGVudGlhbCJ9XX0.xLjbq2oCoGx680494FBRV_JQ4uHAzlICAJe3wXVWFmTFr9G6ngDp72K8ZhNSflgsDchI5j-ZyKlEo3CJfcruceBHI6bMZMPf0p80EPIs6cEe2ASeEoQr7PYpABNTAP7R

See Verifiable Credentials Data Model v2.0 for more details regarding this example.

Implementations MUST support the JWS compact serialization. Use of the JWS JSON serialization is NOT RECOMMENDED.

3.1.3 JOSE Header Parameters and JWT Claims

When present in the JOSE Header or the JWT Claims Set, members registered in the IANA JSON Web Token Claims registry or the IANA JSON Web Signature and Encryption Header Parameters registry are to be interpreted as defined by the specifications referenced in the registries.

The normative statements in Registered Header Parameter Names, JOSE Header, and Replicating Claims as Header Parameters apply to securing credentials and presentations.

The unencoded JOSE Header is JSON (application/json), not JSON-LD (application/ld+json).

It is RECOMMENDED to use the IANA JSON Web Token Claims registry and the IANA JSON Web Signature and Encryption Header Parameters registry to identify any claims and header parameters that might be confused with members defined by Verifiable Credentials Data Model v2.0 [VC-DATA-MODEL-2.0]. These include but are not limited to: iss, kid, alg, iat, exp, and cnf.

When the iat and/or exp JWT claims are present, they represent the issuance and expiration time of the signature, respectively. Note that these are different from the validFrom and validUntil properties defined in Validity Period, which represent the validity of the data that is being secured.

The claims and security provided by this specification are independent of the data secured and semantics provided by the Verifiable Credentials Data Model v2.0 [VC-DATA-MODEL-2.0]. This means that while the security features of this specification ensure data integrity and authenticity, they do not dictate the interpretation of claim data.

Implementers SHOULD avoid setting JWT claims to values that conflict with the values of verifiable credential properties when a claim and property pair refer to the same conceptual entity, especially with pairs such as iss and issuer, jti and id, and sub and credentialSubject.id. For example, JWK claim iss should not be set to a value which conflicts with the value of verifiable credential property issuer.

The JWT Claim Names vc and vp MUST NOT be present.

Additional members may be present as header parameters and claims. If they are not understood, they MUST be ignored.

3.2 With SD-JWT

3.2.1 Securing JSON-LD Verifiable Credentials with SD-JWT

This section details how to use JOSE to secure verifiable credentials conforming to [VC-DATA-MODEL-2.0].

A conforming SD-JWT issuer implementation MUST use Selective Disclosure for JWTs (SD-JWT) [SD-JWT] to secure this media type. The unsecured verifiable credential is the input JSON claim set. The Issuer then converts the input JSON claim set (i.e., the unsecured verifiable credential) into an SD-JWT payload according to SD-JWT issuance instructions.

The typ header parameter SHOULD be vc+ld+json+sd-jwt. When present, the cty header parameter SHOULD be vc+ld+json. See Registered Header Parameter Names for additional details regarding usage of typ and cty.

A conforming SD-JWT verifier implementation MUST use [SD-JWT] to verify conforming JWS documents that use this media type.

Example 3: A simple example of a verifiable credential secured with SD-JWT
eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMzODQifQ.eyJfc2RfYWxnIjoic2hhLTI1NiIsIkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy92MiIsImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy9leGFtcGxlcy92MiJdLCJpc3N1ZXIiOiJodHRwczovL3VuaXZlcnNpdHkuZXhhbXBsZS9pc3N1ZXJzLzU2NTA0OSIsInZhbGlkRnJvbSI6IjIwMTAtMDEtMDFUMTk6MjM6MjRaIiwiY3JlZGVudGlhbFNjaGVtYSI6eyJfc2QiOlsiR25MdFZjRkh5V1lxQi1DbGxXQUVuMGtWYm84QUx6emhKNmU2ZnRUNXRGMCIsInp4TXNyS24tdVVzcnJUMk1fRTFNWExRcmtIUWZzNHFuZm1GbFV1NnREQTgiXX0sImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImRlZ3JlZSI6eyJuYW1lIjoiQmFjaGVsb3Igb2YgU2NpZW5jZSBhbmQgQXJ0cyIsIl9zZCI6WyJzaVpvVUpfcnJxMXNKaTVURXVBY1UwMFNIWmczUGx0M2lVMDF3Y1FTeEhrIl19LCJfc2QiOlsiZl9KUEUxS2ZtWmhkV2s2MHhiNzhyTDhSeHZEWlUwTWlYVjl4VEUyVFV4OCJdfSwiX3NkIjpbIkJjeXVOVWhNSTFmVnZhYUZnUXdKazZBTXNhNXZURnlqZkZIa2tuUmNRbkEiLCJtZTRSc1JONHlvaDViY2VvN1NEMExuVGRDS3ZBQXVyQkNjQzlXeUJLa0EwIl19._mGg3fYHAP9drcpFcCGVQpGDb1BHKFoP1SRoZxdzkhe1f6FGBlfebaQpOEW6vad70h_zImKAtYvwt2jlfuSyx_fyXny9h4p5PBbEofPyi-hXc0nhA_X0yKitH1PvPCYz~WyJrN3VybG8yeWtEeTBDdUZRMWRGcWdBIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMTg3MiJd~WyI5cmlvWjRVTHdPa09aQ0VyYld1bE13IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl1d~WyJNSEZwUzM5d0pOUDBBUm05S2xhcVBnIiwgImlkIiwgImh0dHBzOi8vZXhhbXBsZS5vcmcvZXhhbXBsZXMvZGVncmVlLmpzb24iXQ~WyJqNDQ5cURWUXFWQlk3UHpxWWdrTDZ3IiwgInR5cGUiLCAiSnNvblNjaGVtYSJd~WyJlOWtYbG5HOGJrWm9zSDBnSy1BaW93IiwgImlkIiwgImRpZDpleGFtcGxlOjEyMyJd~WyJxSk9zQU5fZnpxMk1sWkkzaHVwMXh3IiwgInR5cGUiLCAiQmFjaGVsb3JEZWdyZWUiXQ
{
  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
  "alg": "ES384"
}
{
  "_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-01T19:23:24Z",
  "credentialSchema": {
    "_sd": [
      "GnLtVcFHyWYqB-CllWAEn0kVbo8ALzzhJ6e6ftT5tF0",
      "zxMsrKn-uUsrrT2M_E1MXLQrkHQfs4qnfmFlUu6tDA8"
    ]
  },
  "credentialSubject": {
    "degree": {
      "name": "Bachelor of Science and Arts",
      "_sd": [
        "siZoUJ_rrq1sJi5TEuAcU00SHZg3Plt3iU01wcQSxHk"
      ]
    },
    "_sd": [
      "f_JPE1KfmZhdWk60xb78rL8RxvDZU0MiXV9xTE2TUx8"
    ]
  },
  "_sd": [
    "BcyuNUhMI1fVvaaFgQwJk6AMsa5vTFyjfFHkknRcQnA",
    "me4RsRN4yoh5bceo7SD0LnTdCKvAAurBCcC9WyBKkA0"
  ]
}

Claim: id

SHA-256 Hash: BcyuNUhMI1fVvaaFgQwJk6AMsa5vTFyjfFHkknRcQnA

Disclosure(s): WyJrN3VybG8yeWtEeTBDdUZRMWRGcWdBIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMTg3MiJd

Contents: [
  "k7urlo2ykDy0CuFQ1dFqgA",
  "id",
  "http://university.example/credentials/1872"
]

Claim: type

SHA-256 Hash: me4RsRN4yoh5bceo7SD0LnTdCKvAAurBCcC9WyBKkA0

Disclosure(s): WyI5cmlvWjRVTHdPa09aQ0VyYld1bE13IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl1d

Contents: [
  "9rioZ4ULwOkOZCErbWulMw",
  "type",
  [
    "VerifiableCredential",
    "ExampleAlumniCredential"
  ]
]

Claim: id

SHA-256 Hash: GnLtVcFHyWYqB-CllWAEn0kVbo8ALzzhJ6e6ftT5tF0

Disclosure(s): WyJNSEZwUzM5d0pOUDBBUm05S2xhcVBnIiwgImlkIiwgImh0dHBzOi8vZXhhbXBsZS5vcmcvZXhhbXBsZXMvZGVncmVlLmpzb24iXQ

Contents: [
  "MHFpS39wJNP0ARm9KlaqPg",
  "id",
  "https://example.org/examples/degree.json"
]

Claim: type

SHA-256 Hash: zxMsrKn-uUsrrT2M_E1MXLQrkHQfs4qnfmFlUu6tDA8

Disclosure(s): WyJqNDQ5cURWUXFWQlk3UHpxWWdrTDZ3IiwgInR5cGUiLCAiSnNvblNjaGVtYSJd

Contents: [
  "j449qDVQqVBY7PzqYgkL6w",
  "type",
  "JsonSchema"
]

Claim: id

SHA-256 Hash: f_JPE1KfmZhdWk60xb78rL8RxvDZU0MiXV9xTE2TUx8

Disclosure(s): WyJlOWtYbG5HOGJrWm9zSDBnSy1BaW93IiwgImlkIiwgImRpZDpleGFtcGxlOjEyMyJd

Contents: [
  "e9kXlnG8bkZosH0gK-Aiow",
  "id",
  "did:example:123"
]

Claim: type

SHA-256 Hash: siZoUJ_rrq1sJi5TEuAcU00SHZg3Plt3iU01wcQSxHk

Disclosure(s): WyJxSk9zQU5fZnpxMk1sWkkzaHVwMXh3IiwgInR5cGUiLCAiQmFjaGVsb3JEZWdyZWUiXQ

Contents: [
  "qJOsAN_fzq2MlZI3hup1xw",
  "type",
  "BachelorDegree"
]

See Verifiable Credentials Data Model v2.0 for more details regarding this example.

3.2.2 Securing JSON-LD Verifiable Presentations with SD-JWT

This section details how to use SD-JWT to secure verifiable presentations conforming to [VC-DATA-MODEL-2.0].

A conforming SD-JWT issuer implementation MUST use [SD-JWT] to secure this media type. The unsecured verifiable presentation is the unencoded SD-JWT payload.

The typ header parameter SHOULD be vp+ld+json+sd-jwt. When present, the cty header parameter SHOULD be vp+ld+json. See Registered Header Parameter Names for additional details regarding usage of typ and cty.

A conforming SD-JWT verifier implementation MUST use [SD-JWT] to verify conforming JWS documents that use this media type.

Credentials in verifiable presentations MUST use the Enveloped Verifiable Credential type defined by the [VC-DATA-MODEL-2.0].

Credentials in verifiable presentations MUST be secured. These credentials are secured using SD-JWT in this case.

Example 4: A simple example of a verifiable presentation secured with SD-JWT
eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMzODQifQ.eyJfc2RfYWxnIjoic2hhLTI1NiIsIkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy92MiIsImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy9leGFtcGxlcy92MiJdLCJ2ZXJpZmlhYmxlQ3JlZGVudGlhbCI6W3siQGNvbnRleHQiOiJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJfc2QiOlsiS0I5V0U4TnVIeFpObkl0azRVVWVLdFJRNW5xcXpjTVVDdWNfdzBSaFg4RSIsImxUMTk4cTduVG5Pb0RJSk00VWkySWNZMWtfTTY3VUh3UmhFOXNKVGhFeFUiXX1dLCJfc2QiOlsiWndJYkNFTG16YWVqQXYtd241eXpfSUM4dFUxcnU5SEZwQV9oMk56bFdQOCJdfQ.SpwN-4RkLwvllr7Gm_G_I1Y5hL7kR9g7to6YK2o1MBjdiWkEmQqEjM9qexIYXE6O3GdEBTlmo5l9nb1Upyc7_wBsnHowhMbFQ46glJUaLIB5Xwt4S8dfy_rkbkE4hzvL~WyJQRXEzMzBWdUtOTVpsMFZ5bkZDRWRRIiwgInR5cGUiLCAiVmVyaWZpYWJsZVByZXNlbnRhdGlvbiJd~WyJnWHd5WVAtVTJEZDlUdU8zZDlJa1J3IiwgInR5cGUiLCAiRW52ZWxvcGVkVmVyaWZpYWJsZUNyZWRlbnRpYWwiXQ~WyJPZ0dDalJNenpZejZPUDF2d3cwa2t3IiwgImlkIiwgImRhdGE6YXBwbGljYXRpb24vdmMrbGQranNvbitzZC1qd3Q7ZXlKaGJHY2lPaUpGVXpNNE5DSXNJbXRwWkNJNklsVlJUVjlmYmxFMFV6WkNUemh1VVRSdVQwNVllSEI0YUhSb2IzbE9lR0kxTTB4WloxbDZMVEpCUW5NaUxDSjBlWEFpT2lKMmNDdHNaQ3RxYzI5dUszTmtMV3AzZENJc0ltTjBlU0k2SW5ad0syeGtLMnB6YjI0aWZRLmV5SkFZMjl1ZEdWNGRDSTZXeUpvZEhSd2N6b3ZMM2QzZHk1M015NXZjbWN2Ym5NdlkzSmxaR1Z1ZEdsaGJITXZkaklpTENKb2RIUndjem92TDNkM2R5NTNNeTV2Y21jdmJuTXZZM0psWkdWdWRHbGhiSE12WlhoaGJYQnNaWE12ZGpJaVhTd2lkbVZ5YVdacFlXSnNaVU55WldSbGJuUnBZV3dpT2x0N0lrQmpiMjUwWlhoMElqcGJJbWgwZEhCek9pOHZkM2QzTG5jekxtOXlaeTl1Y3k5amNtVmtaVzUwYVdGc2N5OTJNaUlzSW1oMGRIQnpPaTh2ZDNkM0xuY3pMbTl5Wnk5dWN5OWpjbVZrWlc1MGFXRnNjeTlsZUdGdGNHeGxjeTkyTWlKZExDSnBjM04xWlhJaU9pSm9kSFJ3Y3pvdkwzVnVhWFpsY25OcGRIa3VaWGhoYlhCc1pTOXBjM04xWlhKekx6VTJOVEEwT1NJc0luWmhiR2xrUm5KdmJTSTZJakl3TVRBdE1ERXRNREZVTVRrNk1qTTZNalJhSWl3aVkzSmxaR1Z1ZEdsaGJGTjFZbXBsWTNRaU9uc2lZV3gxYlc1cFQyWWlPbnNpYm1GdFpTSTZJa1Y0WVcxd2JHVWdWVzVwZG1WeWMybDBlU0lzSWw5elpDSTZXeUpvZWs5TFJ6VTJjREk1YzFCeVRHRkROVUU0Um5kRmRVY3pWVTA1ZFVsWlUxcDFjVTlZY3pKbFZHSkJJbDE5TENKZmMyUWlPbHNpV1ZkWFZtVkRSbmR4UW1rNFdEQnFTRjlqVjBOV1dVMTZTVE5oT0hCalRFVllSV1ppY0ZOU1FWbG5keUpkZlN3aVgzTmtJanBiSWpKSlpqaGhhVXM0UkVad1ZXSjRkRWMxY0dNd2VsOVNhRkp6Ym0xeWJHRlJNRWh6Y1RrNFdGTnlZV3NpTENKVWVEWjRaV1pNVlVkVVpVcGZZV3RWVUZkR2VITnZiVWhvYkd0V1ZucGZOelZvYVZaNmVXcHlZbVZ6SWwxOVhTd2lYM05rSWpwYklqZDJhbmwwVlZOM1pFSjBNWFE1Umt0bE9WRmZTM0pJUlhoRldHeHJURUZhVHpCS00wSnBkMjAwZGxraVhTd2lYM05rWDJGc1p5STZJbk5vWVMweU5UWWlMQ0pwWVhRaU9qRTNNRFkxTmpJNE5Ea3NJbVY0Y0NJNk1UY3pPREU0TlRJME9Td2lZMjVtSWpwN0ltcDNheUk2ZXlKcmRIa2lPaUpGUXlJc0ltTnlkaUk2SWxBdE16ZzBJaXdpWVd4bklqb2lSVk16T0RRaUxDSjRJam9pZFd0RWQxVTJaemxRVVZSRlVXaFlhRWd5Y2tSWk5uZE1RbGczVUhGbFVqWkJjR2xoVkhCRVVYb3djbDh0ZERsNlVYTnhlbTU0WjBoRWNFNW9la1psUXlJc0lua2lPaUpNUW5oVlluQlZkRk5HTVZWS1ZUVnBZbkpJZGtwSU5qQlVTRzVZTWsxeGEweEhaR2x0VTFsMFVHUjRSbGt4T0VkaGNsZGlTM0ZaVjBkalVrWkhWRTlCSW4xOWZRLmtZRDYzWXRCTlluTFVUdzZTemYxdnNfVWczVUJYaFB3Q3lxcE5tUG5QRGEzclhaUWhRTGRCMUJnYW9POHpnUS1jM0I0MWZ4YVhNbkxIWVY5LUIyMHVib1NwSlAwQi0yVnJlOTE3ZVF0MWNTRHN3REdBX1l0dm40QlNxWVZCQjJKfld5SkZNa0ZzUnpoc1kycDBRVkZyY2xsSWJqbEliblZSSWl3Z0luUjVjR1VpTENBaVZtVnlhV1pwWVdKc1pWQnlaWE5sYm5SaGRHbHZiaUpkfld5STVObGRZTURSbmVubzRjVlp6T1ZaTFUyd3dZVFZuSWl3Z0ltbGtJaXdnSW1oMGRIQTZMeTkxYm1sMlpYSnphWFI1TG1WNFlXMXdiR1V2WTNKbFpHVnVkR2xoYkhNdk1UZzNNaUpkfld5SmFla1UyVkZWYWFtdEhNVzFEV1hCS01FaG5jMGwzSWl3Z0luUjVjR1VpTENCYklsWmxjbWxtYVdGaWJHVkRjbVZrWlc1MGFXRnNJaXdnSWtWNFlXMXdiR1ZCYkhWdGJtbERjbVZrWlc1MGFXRnNJbDFkfld5SXRRM05zUzI1R1pHRlliMkppUVdzeVUwSkJWR1IzSWl3Z0ltbGtJaXdnSW1ScFpEcGxlR0Z0Y0d4bE9tVmlabVZpTVdZM01USmxZbU0yWmpGak1qYzJaVEV5WldNeU1TSmR-V3lKdVJtMU9XbDlJY3pCM1dXTm9PRmRrZVRkblFVTlJJaXdnSW1sa0lpd2dJbVJwWkRwbGVHRnRjR3hsT21NeU56WmxNVEpsWXpJeFpXSm1aV0l4WmpjeE1tVmlZelptTVNKZCJd
{
  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
  "alg": "ES384"
}
{
  "_sd_alg": "sha-256",
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "verifiableCredential": [
    {
      "@context": "https://www.w3.org/ns/credentials/v2",
      "_sd": [
        "KB9WE8NuHxZNnItk4UUeKtRQ5nqqzcMUCuc_w0RhX8E",
        "lT198q7nTnOoDIJM4Ui2IcY1k_M67UHwRhE9sJThExU"
      ]
    }
  ],
  "_sd": [
    "ZwIbCELmzaejAv-wn5yz_IC8tU1ru9HFpA_h2NzlWP8"
  ]
}

Claim: type

SHA-256 Hash: ZwIbCELmzaejAv-wn5yz_IC8tU1ru9HFpA_h2NzlWP8

Disclosure(s): WyJQRXEzMzBWdUtOTVpsMFZ5bkZDRWRRIiwgInR5cGUiLCAiVmVyaWZpYWJsZVByZXNlbnRhdGlvbiJd

Contents: [
  "PEq330VuKNMZl0VynFCEdQ",
  "type",
  "VerifiablePresentation"
]

Claim: type

SHA-256 Hash: KB9WE8NuHxZNnItk4UUeKtRQ5nqqzcMUCuc_w0RhX8E

Disclosure(s): WyJnWHd5WVAtVTJEZDlUdU8zZDlJa1J3IiwgInR5cGUiLCAiRW52ZWxvcGVkVmVyaWZpYWJsZUNyZWRlbnRpYWwiXQ

Contents: [
  "gXwyYP-U2Dd9TuO3d9IkRw",
  "type",
  "EnvelopedVerifiableCredential"
]

Claim: id

SHA-256 Hash: lT198q7nTnOoDIJM4Ui2IcY1k_M67UHwRhE9sJThExU

Disclosure(s): WyJPZ0dDalJNenpZejZPUDF2d3cwa2t3IiwgImlkIiwgImRhdGE6YXBwbGljYXRpb24vdmMrbGQranNvbitzZC1qd3Q7ZXlKaGJHY2lPaUpGVXpNNE5DSXNJbXRwWkNJNklsVlJUVjlmYmxFMFV6WkNUemh1VVRSdVQwNVllSEI0YUhSb2IzbE9lR0kxTTB4WloxbDZMVEpCUW5NaUxDSjBlWEFpT2lKMmNDdHNaQ3RxYzI5dUszTmtMV3AzZENJc0ltTjBlU0k2SW5ad0syeGtLMnB6YjI0aWZRLmV5SkFZMjl1ZEdWNGRDSTZXeUpvZEhSd2N6b3ZMM2QzZHk1M015NXZjbWN2Ym5NdlkzSmxaR1Z1ZEdsaGJITXZkaklpTENKb2RIUndjem92TDNkM2R5NTNNeTV2Y21jdmJuTXZZM0psWkdWdWRHbGhiSE12WlhoaGJYQnNaWE12ZGpJaVhTd2lkbVZ5YVdacFlXSnNaVU55WldSbGJuUnBZV3dpT2x0N0lrQmpiMjUwWlhoMElqcGJJbWgwZEhCek9pOHZkM2QzTG5jekxtOXlaeTl1Y3k5amNtVmtaVzUwYVdGc2N5OTJNaUlzSW1oMGRIQnpPaTh2ZDNkM0xuY3pMbTl5Wnk5dWN5OWpjbVZrWlc1MGFXRnNjeTlsZUdGdGNHeGxjeTkyTWlKZExDSnBjM04xWlhJaU9pSm9kSFJ3Y3pvdkwzVnVhWFpsY25OcGRIa3VaWGhoYlhCc1pTOXBjM04xWlhKekx6VTJOVEEwT1NJc0luWmhiR2xrUm5KdmJTSTZJakl3TVRBdE1ERXRNREZVTVRrNk1qTTZNalJhSWl3aVkzSmxaR1Z1ZEdsaGJGTjFZbXBsWTNRaU9uc2lZV3gxYlc1cFQyWWlPbnNpYm1GdFpTSTZJa1Y0WVcxd2JHVWdWVzVwZG1WeWMybDBlU0lzSWw5elpDSTZXeUpvZWs5TFJ6VTJjREk1YzFCeVRHRkROVUU0Um5kRmRVY3pWVTA1ZFVsWlUxcDFjVTlZY3pKbFZHSkJJbDE5TENKZmMyUWlPbHNpV1ZkWFZtVkRSbmR4UW1rNFdEQnFTRjlqVjBOV1dVMTZTVE5oT0hCalRFVllSV1ppY0ZOU1FWbG5keUpkZlN3aVgzTmtJanBiSWpKSlpqaGhhVXM0UkVad1ZXSjRkRWMxY0dNd2VsOVNhRkp6Ym0xeWJHRlJNRWh6Y1RrNFdGTnlZV3NpTENKVWVEWjRaV1pNVlVkVVpVcGZZV3RWVUZkR2VITnZiVWhvYkd0V1ZucGZOelZvYVZaNmVXcHlZbVZ6SWwxOVhTd2lYM05rSWpwYklqZDJhbmwwVlZOM1pFSjBNWFE1Umt0bE9WRmZTM0pJUlhoRldHeHJURUZhVHpCS00wSnBkMjAwZGxraVhTd2lYM05rWDJGc1p5STZJbk5vWVMweU5UWWlMQ0pwWVhRaU9qRTNNRFkxTmpJNE5Ea3NJbVY0Y0NJNk1UY3pPREU0TlRJME9Td2lZMjVtSWpwN0ltcDNheUk2ZXlKcmRIa2lPaUpGUXlJc0ltTnlkaUk2SWxBdE16ZzBJaXdpWVd4bklqb2lSVk16T0RRaUxDSjRJam9pZFd0RWQxVTJaemxRVVZSRlVXaFlhRWd5Y2tSWk5uZE1RbGczVUhGbFVqWkJjR2xoVkhCRVVYb3djbDh0ZERsNlVYTnhlbTU0WjBoRWNFNW9la1psUXlJc0lua2lPaUpNUW5oVlluQlZkRk5HTVZWS1ZUVnBZbkpJZGtwSU5qQlVTRzVZTWsxeGEweEhaR2x0VTFsMFVHUjRSbGt4T0VkaGNsZGlTM0ZaVjBkalVrWkhWRTlCSW4xOWZRLmtZRDYzWXRCTlluTFVUdzZTemYxdnNfVWczVUJYaFB3Q3lxcE5tUG5QRGEzclhaUWhRTGRCMUJnYW9POHpnUS1jM0I0MWZ4YVhNbkxIWVY5LUIyMHVib1NwSlAwQi0yVnJlOTE3ZVF0MWNTRHN3REdBX1l0dm40QlNxWVZCQjJKfld5SkZNa0ZzUnpoc1kycDBRVkZyY2xsSWJqbEliblZSSWl3Z0luUjVjR1VpTENBaVZtVnlhV1pwWVdKc1pWQnlaWE5sYm5SaGRHbHZiaUpkfld5STVObGRZTURSbmVubzRjVlp6T1ZaTFUyd3dZVFZuSWl3Z0ltbGtJaXdnSW1oMGRIQTZMeTkxYm1sMlpYSnphWFI1TG1WNFlXMXdiR1V2WTNKbFpHVnVkR2xoYkhNdk1UZzNNaUpkfld5SmFla1UyVkZWYWFtdEhNVzFEV1hCS01FaG5jMGwzSWl3Z0luUjVjR1VpTENCYklsWmxjbWxtYVdGaWJHVkRjbVZrWlc1MGFXRnNJaXdnSWtWNFlXMXdiR1ZCYkhWdGJtbERjbVZrWlc1MGFXRnNJbDFkfld5SXRRM05zUzI1R1pHRlliMkppUVdzeVUwSkJWR1IzSWl3Z0ltbGtJaXdnSW1ScFpEcGxlR0Z0Y0d4bE9tVmlabVZpTVdZM01USmxZbU0yWmpGak1qYzJaVEV5WldNeU1TSmR-V3lKdVJtMU9XbDlJY3pCM1dXTm9PRmRrZVRkblFVTlJJaXdnSW1sa0lpd2dJbVJwWkRwbGVHRnRjR3hsT21NeU56WmxNVEpsWXpJeFpXSm1aV0l4WmpjeE1tVmlZelptTVNKZCJd

Contents: [
  "OgGCjRMzzYz6OP1vww0kkw",
  "id",
  "data:application/vc+ld+json+sd-jwt;eyJhbGciOiJFUzM4NCIsImtpZCI6IlVRTV9fblE0UzZCTzhuUTRuT05YeHB4aHRob3lOeGI1M0xZZ1l6LTJBQnMiLCJ0eXAiOiJ2cCtsZCtqc29uK3NkLWp3dCIsImN0eSI6InZwK2xkK2pzb24ifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwidmVyaWZpYWJsZUNyZWRlbnRpYWwiOlt7IkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy92MiIsImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy9leGFtcGxlcy92MiJdLCJpc3N1ZXIiOiJodHRwczovL3VuaXZlcnNpdHkuZXhhbXBsZS9pc3N1ZXJzLzU2NTA0OSIsInZhbGlkRnJvbSI6IjIwMTAtMDEtMDFUMTk6MjM6MjRaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiYWx1bW5pT2YiOnsibmFtZSI6IkV4YW1wbGUgVW5pdmVyc2l0eSIsIl9zZCI6WyJoek9LRzU2cDI5c1ByTGFDNUE4RndFdUczVU05dUlZU1p1cU9YczJlVGJBIl19LCJfc2QiOlsiWVdXVmVDRndxQmk4WDBqSF9jV0NWWU16STNhOHBjTEVYRWZicFNSQVlndyJdfSwiX3NkIjpbIjJJZjhhaUs4REZwVWJ4dEc1cGMwel9SaFJzbm1ybGFRMEhzcTk4WFNyYWsiLCJUeDZ4ZWZMVUdUZUpfYWtVUFdGeHNvbUhobGtWVnpfNzVoaVZ6eWpyYmVzIl19XSwiX3NkIjpbIjd2anl0VVN3ZEJ0MXQ5RktlOVFfS3JIRXhFWGxrTEFaTzBKM0Jpd200dlkiXSwiX3NkX2FsZyI6InNoYS0yNTYiLCJpYXQiOjE3MDY1NjI4NDksImV4cCI6MTczODE4NTI0OSwiY25mIjp7Imp3ayI6eyJrdHkiOiJFQyIsImNydiI6IlAtMzg0IiwiYWxnIjoiRVMzODQiLCJ4IjoidWtEd1U2ZzlQUVRFUWhYaEgyckRZNndMQlg3UHFlUjZBcGlhVHBEUXowcl8tdDl6UXNxem54Z0hEcE5oekZlQyIsInkiOiJMQnhVYnBVdFNGMVVKVTVpYnJIdkpINjBUSG5YMk1xa0xHZGltU1l0UGR4RlkxOEdhcldiS3FZV0djUkZHVE9BIn19fQ.kYD63YtBNYnLUTw6Szf1vs_Ug3UBXhPwCyqpNmPnPDa3rXZQhQLdB1BgaoO8zgQ-c3B41fxaXMnLHYV9-B20uboSpJP0B-2Vre917eQt1cSDswDGA_Ytvn4BSqYVBB2J~WyJFMkFsRzhsY2p0QVFrcllIbjlIbnVRIiwgInR5cGUiLCAiVmVyaWZpYWJsZVByZXNlbnRhdGlvbiJd~WyI5NldYMDRneno4cVZzOVZLU2wwYTVnIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMTg3MiJd~WyJaekU2VFVaamtHMW1DWXBKMEhnc0l3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl1d~WyItQ3NsS25GZGFYb2JiQWsyU0JBVGR3IiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd~WyJuRm1OWl9IczB3WWNoOFdkeTdnQUNRIiwgImlkIiwgImRpZDpleGFtcGxlOmMyNzZlMTJlYzIxZWJmZWIxZjcxMmViYzZmMSJd"
]

See Verifiable Credentials Data Model v2.0 for more details regarding this example.

Implementations MUST support the compact serialization (application/sd-jwt) and MAY support the JSON serialization (application/sd-jwt+json). If the JSON serialization is used, it is RECOMMENDED that a profile be defined to ensure any additional JSON members are understood consistently.

3.3 With COSE

COSE [RFC9052] is a common approach to encoding and securing information using CBOR [RFC8949]. Verifiable credentials MAY be secured using COSE [RFC9052] and SHOULD be identified through use of content types as outlined in this section.

3.3.1 Securing JSON-LD Verifiable Credentials with COSE

This section details how to secure data with the type application/vc+ld+json with COSE.

A conforming COSE issuer implementation MUST use COSE_Sign1 as specified in [RFC9052] to secure this media type. The unsecured verifiable credential is the unencoded COSE_Sign1 payload.

The typ header parameter SHOULD be application/vc+ld+json+cose. See I-D.ietf-cose-typ-header-parameter for the COSE "typ" (type) header parameter. When present, the content type (3) header parameter SHOULD be application/vc+ld+json. See Common COSE Header Parameters for additional details.

A conforming COSE verifier implementation MUST use COSE_Sign1 as specified in [RFC9052] to verify conforming COSE documents that use this media type.

Example 5: A simple example of a verifiable credential secured with COSE

application/vc+ld+json

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/1872",
  "type": [
    "VerifiableCredential",
    "ExampleAlumniCredential"
  ],
  "issuer": "https://university.example/issuers/565049",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSchema": {
    "id": "https://example.org/examples/degree.json",
    "type": "JsonSchema"
  },
  "credentialSubject": {
    "id": "did:example:123",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  }
}

application/cbor-diagnostic

/ cose-sign1 / 18([
  / protected / << {
    / alg / 1 : -35 / ES384 /
  } >>,
  / unprotected / {
  },
  / payload / nil,
  / signature / h'e726dc9a...388258df'
])

application/vc+ld+json+cose (detached payload)

d28444a1013822a0f65860e726dc9aab526ed434f420fe7848ba7de7e6ab5e7f9d25d56b4b4513888069e2f439bc24b5ec04d39a2182c7e8ea7cb9483a2d89a863b4b81089de8b85e32c1c6f4a9e7ba5cf11818945aa9ada396f749749e1aa674a908bc69b98e5388258df

See Verifiable Credentials Data Model v2.0 for more details regarding this example.

3.3.2 Securing JSON-LD Verifiable Presentations with COSE

This section details how to use COSE to secure verifiable presentations conforming to [VC-DATA-MODEL-2.0].

A conforming COSE issuer implementation MUST use COSE_Sign1 as specified in [RFC9052] to secure this media type. The unsecured verifiable presentation is the unencoded COSE_Sign1 payload.

The typ header parameter SHOULD be application/vp+ld+json+cose. When present, the cty header parameter SHOULD be application/vp+ld+json. See Common COSE Header Parameters for additional details.

A conforming COSE verifier implementation MUST use COSE_Sign1 as specified in [RFC9052] to verify conforming COSE documents that use this media type.

Credentials in verifiable presentations MUST use the Enveloped Verifiable Credential type defined by the [VC-DATA-MODEL-2.0].

Credentials in verifiable presentations MUST be secured. These credentials are secured using COSE in this case.

Example 6: A simple example of a verifiable presentation secured with COSE

application/vp+ld+json

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": "VerifiablePresentation",
  "verifiableCredential": [
    {
      "@context": "https://www.w3.org/ns/credentials/v2",
      "id": "data:application/vc+ld+json+sd-jwt;eyJhbGciOiJFUzM4NCIsImtpZCI6IlVRTV9fblE0UzZCTzhuUTRuT05YeHB4aHRob3lOeGI1M0xZZ1l6LTJBQnMiLCJ0eXAiOiJ2cCtsZCtqc29uK3NkLWp3dCIsImN0eSI6InZwK2xkK2pzb24ifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwidmVyaWZpYWJsZUNyZWRlbnRpYWwiOlt7IkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy92MiIsImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy9leGFtcGxlcy92MiJdLCJpc3N1ZXIiOiJodHRwczovL3VuaXZlcnNpdHkuZXhhbXBsZS9pc3N1ZXJzLzU2NTA0OSIsInZhbGlkRnJvbSI6IjIwMTAtMDEtMDFUMTk6MjM6MjRaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiYWx1bW5pT2YiOnsibmFtZSI6IkV4YW1wbGUgVW5pdmVyc2l0eSIsIl9zZCI6WyJoek9LRzU2cDI5c1ByTGFDNUE4RndFdUczVU05dUlZU1p1cU9YczJlVGJBIl19LCJfc2QiOlsiWVdXVmVDRndxQmk4WDBqSF9jV0NWWU16STNhOHBjTEVYRWZicFNSQVlndyJdfSwiX3NkIjpbIjJJZjhhaUs4REZwVWJ4dEc1cGMwel9SaFJzbm1ybGFRMEhzcTk4WFNyYWsiLCJUeDZ4ZWZMVUdUZUpfYWtVUFdGeHNvbUhobGtWVnpfNzVoaVZ6eWpyYmVzIl19XSwiX3NkIjpbIjd2anl0VVN3ZEJ0MXQ5RktlOVFfS3JIRXhFWGxrTEFaTzBKM0Jpd200dlkiXSwiX3NkX2FsZyI6InNoYS0yNTYiLCJpYXQiOjE3MDY1NjI4NDksImV4cCI6MTczODE4NTI0OSwiY25mIjp7Imp3ayI6eyJrdHkiOiJFQyIsImNydiI6IlAtMzg0IiwiYWxnIjoiRVMzODQiLCJ4IjoidWtEd1U2ZzlQUVRFUWhYaEgyckRZNndMQlg3UHFlUjZBcGlhVHBEUXowcl8tdDl6UXNxem54Z0hEcE5oekZlQyIsInkiOiJMQnhVYnBVdFNGMVVKVTVpYnJIdkpINjBUSG5YMk1xa0xHZGltU1l0UGR4RlkxOEdhcldiS3FZV0djUkZHVE9BIn19fQ.kYD63YtBNYnLUTw6Szf1vs_Ug3UBXhPwCyqpNmPnPDa3rXZQhQLdB1BgaoO8zgQ-c3B41fxaXMnLHYV9-B20uboSpJP0B-2Vre917eQt1cSDswDGA_Ytvn4BSqYVBB2J~WyJFMkFsRzhsY2p0QVFrcllIbjlIbnVRIiwgInR5cGUiLCAiVmVyaWZpYWJsZVByZXNlbnRhdGlvbiJd~WyI5NldYMDRneno4cVZzOVZLU2wwYTVnIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMTg3MiJd~WyJaekU2VFVaamtHMW1DWXBKMEhnc0l3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl1d~WyItQ3NsS25GZGFYb2JiQWsyU0JBVGR3IiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd~WyJuRm1OWl9IczB3WWNoOFdkeTdnQUNRIiwgImlkIiwgImRpZDpleGFtcGxlOmMyNzZlMTJlYzIxZWJmZWIxZjcxMmViYzZmMSJd",
      "type": "EnvelopedVerifiableCredential"
    }
  ]
}

application/cbor-diagnostic

/ cose-sign1 / 18([
  / protected / << {
    / alg / 1 : -35 / ES384 /
  } >>,
  / unprotected / {
  },
  / payload / nil,
  / signature / h'dca9bd23...f996fa0c'
])

application/vp+ld+json+cose (detached payload)

d28444a1013822a0f65860dca9bd23a039d1d41e6550a704d88f5b3e477c75d315d4965ca6de540a6cd293f60d3bcd9b43ea170708371a8566809bff6fdc9cb5c3f3dafd8f604abf8407fc989eeb91774419c23ebb7da08cab6f9a90f55cb80dff2f89f474cfdff996fa0c

See Verifiable Credentials Data Model v2.0 for more details regarding this example.

3.3.3 COSE Header Parameters and CWT Claims

When present in the COSE Header or as CWT Claims, members registered in the IANA CBOR Web Token (CWT) Claims registry or the IANA COSE Header Parameters registry are to be interpreted as defined by the specifications referenced in those registries. CBOR Web Token (CWT) [RFC8392] Claims MAY be included in a COSE header parameter, as specified in I-D.ietf-cose-cwt-claims-in-headers.

The normative statements in Header Parameters, Claims, and CBOR Web Token (CWT) Claims in COSE Headers apply to securing credentials and presentations.

It is RECOMMENDED to use the IANA CBOR Web Token Claims registry and the IANA COSE Header Parameters registry to identify any claims and header parameters that might be confused with members defined by Verifiable Credentials Data Model v2.0 [VC-DATA-MODEL-2.0]. These include but are not limited to: iss, kid, alg, iat, exp, and cnf.

When the iat and/or exp CWT claims are present, they represent the issuance and expiration time of the signature, respectively. Note that these are different from the validFrom and validUntil properties defined in Validity Period, which represent the validity of the data that is being secured.

Additional members may be present as header parameters and claims. If they are not understood, they MUST be ignored.

4. Key Discovery

Issue 160: Controller Documents vs DID Documents post-CR

The working group is still discussing how to close many related issues.

When iss is absent and the issuer is identified as a DID Subject, the kid MUST be an absolute DID URL.

Example 7: An issuer identified by a DID
{
  "issuer": "did:example:123"
  // ...
}
Example 8: An absolute DID URL as a kid
{
  "alg": "ES384",
  "kid": "did:example:123#key-456
}

When iss is absent, and the holder is identified as a DID Subject, the kid MUST be an absolute DID URL.

Example 9: A holder identified by a DID
{
  "holder": "did:example:abc"
  // ...
}
Example 10: A kid as an absolute DID URL
{
  "alg": "ES384",
  "kid": "did:example:abc#key-456
}

When iss is absent, and the issuer is identified as a [URL], the kid MUST be an absolute [URL] to a verification method listed in a controller document.

Example 11: An issuer identified by a controller document identifier
{
  "issuer": {
    "id": "https://university.example/issuers/565049"
  }
  // ...
}
Example 12: A kid as a controller document verification method identifier
{
  "alg": "ES384",
  "kid": "https://university.example/issuers/565049#key-123
}

When the holder is identified as a [URL], and iss is absent, the kid MUST be an absolute [URL] to a verification method listed in a controller document.

Example 13: A holder identified by a controller document identifier
{
  "holder": {
    "id": "https://university.example/issuers/565049"
  }
  // ...
}
Example 14: A kid as a controller document verification method identifier
{
  "alg": "ES384",
  "kid": "https://university.example/issuers/565049#key-123
}

When iss is present and is a [URL], the kid MUST match a key discovered via a JWT Issuer Metadata Request, as described in [SD-JWT-VC].

Issue: (AT RISK) Feature depends on demonstration of independent implementations

This normative statement depends on the IETF OAuth working group draft [SD-JWT-VC]. This feature is at risk and will be removed from the specification if at least two independent, interoperable implementations are not demonstrated.

To complete the verification process, a verifier needs to obtain the cryptographic keys used to secure the credential.

There are several different ways to discover the verification keys of the issuers and holders.

4.1 Using Header Parameters and Claims for Key Discovery

These JOSE header parameters and JWT claims can be used by verifiers to discover verification keys.

4.1.1 kid

If kid is present in the JOSE Header or the COSE Header, a verifier can use this parameter as a hint indicating which key was used to secure the verifiable credential, when performing a verification process as defined in RFC7515.

kid MUST be present when the key of the issuer or subject is expressed as a DID URL.

4.1.2 iss

If iss is present in the JOSE Header, the JWT Claims, or the COSE Header, a verifier can use this parameter to obtain a JSON Web Key to use in the verification process.

The value of the issuer property can be either a string or an object. When issuer value is a string, iss value, if present, MUST match issuer value. When issuer value is an object with an id value, iss value, if present, MUST match issuer.id value.

If kid is also present in the JOSE Header, it is used to distinguish the specific key used.

4.1.3 cnf

If cnf is present in the JOSE Header, the JWT Claims, or the COSE Header, a verifier MAY use this parameter to identify a proof-of-possession key in the manner described in [RFC7800] or [RFC8747] for use in the verification process.

Use of a proof-of-possession key provided by the Holder to the Issuer to establish a cryptographic binding to the Holder in the Verifiable Credential that is verifiable by the Verifier in the Verifiable Presentation is RECOMMENDED.

4.2 Well-Known URIs

Issue 160: Controller Documents vs DID Documents post-CR

The working group is currently exploring how Defining Well-Known Uniform Resource Identifiers (URIs) could be leveraged to assist a verifier in discovering verification keys for issuers and holders.

4.2.1 JWT Issuer

When the issuer value is a URL using the HTTPS scheme, issuer metadata including the issuer's public keys can be retrieved using the mechanism defined in [SD-JWT-VC].

Issue: (AT RISK) Feature depends on demonstration of independent implementations

This normative statement depends on the IETF OAuth working group draft [SD-JWT-VC]. This feature is at risk and will be removed from the specification if at least two independent, interoperable implementations are not demonstrated.

4.3 Controller Documents

A controller document is a set of data that specifies one or more relationships between a controller and a set of data, such as a set of public cryptographic keys. The controller document SHOULD contain verification relationships that explicitly permit the use of certain verification methods for specific purposes.

4.3.1 Verification Methods

A controller document can express verification methods, such as cryptographic public keys, which can be used to authenticate or authorize interactions with the controller or associated parties. For example, a cryptographic public key can be used as a verification method with respect to a digital signature; in such usage, it verifies that the signer could use the associated cryptographic private key. Verification methods might take many parameters. An example of this is a set of five cryptographic keys from which any three are required to contribute to a cryptographic threshold signature.

verificationMethod

The verificationMethod property is OPTIONAL. If present, its value MUST be a set of verification methods, where each verification method is expressed using a map. The verification method map MUST include the id, type, controller, and specific verification material properties that are determined by the value of type and are defined in 4.3.1.1 Verification Material. A verification method MAY include additional properties.

id

The value of the id property for a verification method MUST be a string that conforms to the [URL] syntax.

type
The value of the type property MUST be a string that references exactly one verification method type. To maximize interoperability, the verification method type SHOULD be JsonWebKey.
controller
The value of the controller property MUST be a string that conforms to the [URL] syntax.
revoked
The revoked property is OPTIONAL. If present, its value MUST be an [XMLSCHEMA11-2] combined date and time string specifying when the verification method SHOULD cease to be used. Once the value is set, it is not expected to be updated, and systems depending on the value are expected to not verify any proofs associated with the verification method at or after the time of revocation.
Example 15: Example verification method structure
{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/security/jwk/v1"
  ]
  "id": "did:example:123456789abcdefghi",
  ...
  "verificationMethod": [{
    "id": ...,
    "type": ...,
    "controller": ...,
    "publicKeyJwk": ...
  }]
}
Note: Verification method controller(s) and controller(s)

The semantics of the controller property are the same when the subject of the relationship is the controller document as when the subject of the relationship is a verification method, such as a cryptographic public key. Since a key can't control itself, and the key controller cannot be inferred from the controller document, it is necessary to explicitly express the identity of the controller of the key. The difference is that the value of controller for a verification method is not necessarily a controller. Controllers are expressed using the `controller` property at the highest level of the controller document.

4.3.1.1 Verification Material

Verification material MUST be expressed in the publicKeyJwk property of a JsonWebKey. This key material is retrieved based on hints in the JOSE or COSE message envelopes, such as kid or iss. At the time of writing, there is no standard way to retrieve a public key in JWK format from a DID URL or controller document.

A verification method MUST NOT contain multiple verification material properties for the same material. For example, expressing key material in a verification method using both publicKeyJwk and another representation is prohibited.

Implementations MAY convert keys between formats as desired for operational purposes or to interface with cryptographic libraries. As an internal implementation detail, such conversion MUST NOT affect the external representation of key material.

An example of a controller document containing verification methods using both properties above is shown below.

Example 16: Verification method using publicKeyJwk
{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/security/jwk/v1"
  ]
  "id": "did:example:123456789abcdefghi",
  ...
  "verificationMethod": [
    {
      "id": "did:example:123#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A",
      "type": "JsonWebKey", // external (property value)
      "controller": "did:example:123",
      "publicKeyJwk": {
        "crv": "Ed25519", // external (property name)
        "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ", // external (property name)
        "kty": "OKP", // external (property name)
        "kid": "_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A" // external (property name)
      }
    }
  ],
  ...
}
4.3.1.2 JsonWebKey

The JSON Web Key (JWK) is a specific type of verification method that uses the JWK specification [RFC7517] to encode key types into a set of parameters.

When specifying a JsonWebKey, the object takes the following form:

type
The value of the type property MUST contain the string JsonWebKey.
publicKeyJwk

The publicKeyJwk property is REQUIRED, and its value MUST be a JSON Web Key that conforms to [RFC7517]. It is RECOMMENDED that verification methods that use JWKs [RFC7517] to represent their public keys use the value of kid as their fragment identifier. It is RECOMMENDED that JWK kid values be set to the public key fingerprint [RFC7638]. See the first key in the example below for an instance of a public key with a compound key identifier.

As specified in Section 4.4 of the JWK specification, the OPTIONAL alg property identifies the algorithm intended for use with the public key, and SHOULD be included to prevent security issues that can arise when using the same key with multiple algorithms. As specified in Section 6.2.1.1 of the JWA specification, describing a key using an elliptic curve, the REQUIRED crv property is used to identify the particular curve type of the public key. As specified in Section 4.1.4 of the JWS specification, the OPTIONAL kid property is a hint used to help discover the key; if present, the kid value SHOULD match, or be included in, the id property of the encapsulating JsonWebKey object, as part of the path, query, or fragment of the URL.

secretKeyJwk
The secretKeyJwk property is OPTIONAL. If present, its value MUST be a map representing a JSON Web Key that conforms to [RFC7517]. It MUST NOT be used if the data structure containing it is public or may be revealed to parties other than the legitimate holders of the secret key.

An example of an object that conforms to JsonWebKey is provided below:

Example 17: JSON Web Key encoding of a secp384r1 (P-384) public key
{
  "id": "did:example:123456789abcdefghi#key-1",
  "type": "JsonWebKey",
  "controller": "did:example:123456789abcdefghi",
  "publicKeyJwk": {
      "kid": "key-1",
      "kty": "EC",
      "crv": "P-384",
      "alg": "ES384",
      "x": "1F14JSzKbwxO-Heqew5HzEt-0NZXAjCu8w-RiuV8_9tMiXrSZdjsWqi4y86OFb5d",
      "y": "dnd8yoq-NOJcBuEYgdVVMmSxonXg-DU90d7C4uPWb_Lkd4WIQQEH0DyeC2KUDMIU"
    }
}

In the example above, the publicKeyJwk value contains the JSON Web Key. The kty property encodes the key type of "OKP", which means "Octet string key pairs". The alg property identifies the algorithm intended for use with the public key, which in this case is ES384. The crv property identifies the particular curve type of the public key, P-384. The x property specifies the point on the P-384 curve that is associated with the public key.

The publicKeyJwk property MUST NOT contain any property marked as "Private" or "Secret" in any registry contained in the JOSE Registries [JOSE-REGISTRIES], including "d".

JSON Web Key is also capable of encoding secret keys, sometimes referred to as private keys.

Example 18: JSON Web Key encoding of a secp384r1 (P-384) secret key
{
  "id": "did:example:123456789abcdefghi#key-1",
  "type": "JsonWebKey",
  "controller": "did:example:123456789abcdefghi",
  "secretKeyJwk": {
      "kty": "EC",
      "crv": "P-384",
      "alg": "ES384",
      "d": "fGwges0SX1mj4eZamUCL4qtZijy9uT15fI4gKTuRvre4Kkoju2SHM4rlFOeKVraH",
      "x": "1F14JSzKbwxO-Heqew5HzEt-0NZXAjCu8w-RiuV8_9tMiXrSZdjsWqi4y86OFb5d",
      "y": "dnd8yoq-NOJcBuEYgdVVMmSxonXg-DU90d7C4uPWb_Lkd4WIQQEH0DyeC2KUDMIU"
    }
}

The private key example above is almost identical to the previous example of the public key, except that the information is stored in the secretKeyJwk property (rather than the publicKeyJwk), and the private key value is encoded in the d property thereof (alongside the x property, which still specifies the point on the secp384r1 curve that is associated with the public key).

4.3.1.3 Referring to Verification Methods

Verification methods can be referenced from properties associated with various verification relationships as described in 4.3.2 Verification Relationships. Referencing verification methods allows them to be used by more than one verification relationship.

If the value of a verification method property is a URL string, the verification method has been included by reference and its properties will need to be retrieved from elsewhere in the controller document or from another controller document. This is done by dereferencing the URL and searching the resulting resource for a verification method map with an id property whose value matches the URL.

Example 19: Referencing verification methods
    {
...

      "authentication": [
        // this key is referenced and might be used by
        // more than one verification relationship
        "did:example:123456789abcdefghi#keys-1",
      ],

...
    }

4.3.2 Verification Relationships

A verification relationship expresses the relationship between the controller and a verification method.

Different verification relationships enable the associated verification methods to be used for different purposes. It is up to a verifier to ascertain the validity of a verification attempt by checking that the verification method used is contained in the appropriate verification relationship property of the controller document.

The verification relationship between the controller and the verification method is explicit in the controller document. Verification methods that are not associated with a particular verification relationship cannot be used for that verification relationship.

The controller document does not express revoked keys using a verification relationship. If a referenced verification method is not in the latest controller document used to dereference it, then that verification method is considered invalid or revoked.

The following sections define several useful verification relationships. A controller document MAY include any of these, or other properties, to express a specific verification relationship. To maximize global interoperability, any such properties used SHOULD be registered in the VC Specifications Directory.

4.3.2.1 Authentication

The authentication verification relationship is used to specify how the controller is expected to be authenticated, for purposes such as logging into a website or engaging in any sort of challenge-response protocol.

authentication
The authentication property is OPTIONAL. If present, its value MUST be a set of one or more verification methods. Each verification method MAY be embedded or referenced.
Example 20: Authentication property containing three verification methods
{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://www.w3.org/ns/credentials/v2"
  ],
  "id": "did:example:123456789abcdefghi",
  ...
  "authentication": [
    // this method can be used to authenticate as did:...fghi
    "did:example:123456789abcdefghi#keys-1",
  ...
}

If authentication is established, it is up to the application to decide what to do with that information.

This is useful to any authentication verifier that needs to check to see whether an entity that is attempting to authenticate is, in fact, presenting a valid proof of authentication. When a verifier receives some data (in some protocol-specific format) that contains a proof that was made for the purpose of "authentication", and that says that an entity is identified by the id, then that verifier checks to ensure that the proof can be verified using a verification method (e.g., public key) listed under `authentication` in the controller document.

Note that the verification method indicated by the `authentication` property of a controller document can only be used to authenticate the controller. To authenticate a different controller, the entity associated with the value of controller needs to authenticate with its own controller document and associated `authentication` verification relationship.

4.3.2.2 Assertion

The assertionMethod verification relationship is used to specify how the controller is expected to express claims, such as for the purposes of issuing a Verifiable Credential [VC-DATA-MODEL-2.0].

assertionMethod
The assertionMethod property is OPTIONAL. If present, its value MUST be a set of one or more verification methods. Each verification method MAY be embedded or referenced.

This property is useful, for example, during the processing of a verifiable credential by a verifier.

Example 21: Assertion method property
{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://www.w3.org/ns/credentials/v2"
  ],
  "id": "did:example:123456789abcdefghi",
  ...
  "assertionMethod": [
    // this method can be used to assert statements as did:...fghi
    "did:example:123456789abcdefghi#keys-1",
  ...
}

5. 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, NOT RECOMMENDED, OPTIONAL, RECOMMENDED, REQUIRED, and SHOULD 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.

5.1 Conformance Classes

A conforming JWS document is one that conforms to all of the "MUST" statements in Section 3.1 With JOSE.

A conforming JWS issuer implementation produces conforming JWS documents and MUST secure them as described in Section 3.1 With JOSE.

A conforming JWS verifier implementation verifies conforming JWS documents as described in Section 3.1 With JOSE.

A conforming SD-JWT document is one that conforms to all of the "MUST" statements in Section 3.2 With SD-JWT.

A conforming SD-JWT issuer implementation produces conforming SD-JWT documents and MUST secure them as described in Section 3.2 With SD-JWT.

A conforming SD-JWT verifier implementation verifies conforming SD-JWT documents as described in Section 3.2 With SD-JWT.

A conforming COSE document is one that conforms to all of the "MUST" statements in Section 3.3 With COSE.

A conforming COSE issuer implementation produces conforming COSE documents and MUST secure them as described in Section 3.3 With COSE.

A conforming COSE verifier implementation verifies conforming COSE documents as described in Section 3.3 With COSE.

5.2 Securing Verifiable Credentials

The Verifiable Credentials Data Model v2.0 describes the approach taken by JSON Web Tokens to secure JWT Claims Sets as applying an external proof.

The normative statements in Securing Mechanisms apply to securing application/vc+ld+json and application/vp+ld+json, application/vc+ld+json+sd-jwt and application/vp+ld+json+sd-jwt, as well as application/vc+ld+json+cose and application/vp+ld+json+cose.

JSON Web Token implementers are advised to review Implementation Requirements.

Accordingly, Issuers, Holders, and Verifiers MUST understand the JSON Web Token header parameter "alg": "none" when securing [VC-DATA-MODEL-2.0] with JSON Web Tokens. When content types from [VC-DATA-MODEL-2.0] are secured using JSON Web Tokens, the header parameter "alg": "none", MUST be used to communicate that a JWT Claims Set (a Verifiable Credential or a Verifiable Presentation) has no integrity protection. When a JWT Claims Set (a Verifiable Credential or a Verifiable Presentation) contains proof, and the JSON Web Token header contains "alg": "none", the JWT Claims Set MUST be considered to have no integrity protection.

Verifiable Credentials and Verifiable Presentations are not required to be secured or integrity protected or to contain a proof member.

Issuers, Holders, and Verifiers MUST ignore all JWT Claims Sets that have no integrity protection.

The JWT Claim Names vc and vp MUST NOT be present in any JWT Claims Set.

6. IANA Considerations

6.1 Media Types

6.1.1 application/vc+ld+json+jwt

This specification registers the application/vc+ld+json+jwt Media Type specifically for identifying a JSON Web Token (JWT) with a payload conforming to the Verifiable Credential Data Model.

Type name: application
Subtype name: vc+ld+json+jwt
Required parameters: None
Encoding considerations: binary; application/jwt values are a series of base64url-encoded values (some of which may be the empty string) separated by period ('.').
Security considerations:

As defined in this specification. See also the security considerations in JSON Web Token (JWT).

Contact: W3C Verifiable Credentials Working Group public-vc-wg@w3.org

6.1.2 application/vp+ld+json+jwt

This specification registers the application/vp+ld+json+jwt Media Type specifically for identifying a JSON Web Token (JWT) with a payload conforming to Verifiable Presentations.

Type name: application
Subtype name: vp+ld+json+jwt
Required parameters: None
Encoding considerations: binary; application/jwt values are a series of base64url-encoded values (some of which may be the empty string) separated by period ('.').
Security considerations:

As defined in this specification. See also the security considerations in JSON Web Token (JWT).

Contact: W3C Verifiable Credentials Working Group public-vc-wg@w3.org

6.1.3 application/vc+ld+json+sd-jwt

This specification registers the application/vc+ld+json+sd-jwt Media Type specifically for identifying a Selective Disclosure for JWTs (SD-JWT) with a payload conforming to the Verifiable Credential Data Model.

Type name: application
Subtype name: vc+ld+json+sd-jwt
Required parameters: None
Encoding considerations: binary; application/sd-jwt values are a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') or tilde ('~') characters.
Security considerations:

As defined in this specification. See also the security considerations in Selective Disclosure for JWTs (SD-JWT).

Contact: W3C Verifiable Credentials Working Group public-vc-wg@w3.org

6.1.4 application/vp+ld+json+sd-jwt

This specification registers the application/vp+ld+json+sd-jwt Media Type specifically for identifying a Selective Disclosure for JWTs (SD-JWT) with a payload conforming to Verifiable Presentations.

Type name: application
Subtype name: vp+ld+json+sd-jwt
Required parameters: None
Encoding considerations: binary; application/sd-jwt values are a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') or tilde ('~') characters.
Security considerations:

As defined in this specification. See also the security considerations in Selective Disclosure for JWTs (SD-JWT).

Contact: W3C Verifiable Credentials Working Group public-vc-wg@w3.org

6.1.5 application/vc+ld+json+cose

This specification registers the application/vc+ld+json+cose Media Type specifically for identifying a COSE object [RFC9052] with a payload conforming to the Verifiable Credential Data Model.

Type name: application
Subtype name: vc+ld+json+cose
Required parameters: None
Encoding considerations: binary (CBOR)
Security considerations:

As defined in this specification. See also the security considerations in [RFC9052].

Contact: W3C Verifiable Credentials Working Group public-vc-wg@w3.org

6.1.6 application/vp+ld+json+cose

This specification registers the application/vp+ld+json+cose Media Type specifically for identifying a COSE object [RFC9052] with a payload conforming to Verifiable Presentations.

Type name: application
Subtype name: vp+ld+json+cose
Required parameters: None
Encoding considerations: binary (CBOR)
Security considerations:

As defined in this specification. See also the security considerations in [RFC9052].

Contact: W3C Verifiable Credentials Working Group public-vc-wg@w3.org

6.2 Structured Syntax Suffixes

6.2.1 +ld+json+jwt

This specification registers the +ld+json+jwt Structured Suffix in the IANA "Structured Syntax Suffixes" registry [IANA-STRUCTURED-SUFFIX] for indicating that the media type is encoded as a JSON Web Token (JWT) with a JSON-LD payload.

Name: ld+json+jwt
+suffix: +ld+json+jwt
References: this specification
Encoding considerations: binary; jwt values are a series of base64url-encoded values (some of which may be the empty string) separated by period ('.').
Security considerations:

As defined in this specification. See also the security considerations in JSON Web Token (JWT) and [json-ld11].

Contact: W3C Verifiable Credentials Working Group public-vc-wg@w3.org
Author/Change Controller: W3C Verifiable Credentials Working Group public-vc-wg@w3.org

6.2.2 +json+jwt

This specification registers the +json+jwt Structured Suffix in the IANA "Structured Syntax Suffixes" registry [IANA-STRUCTURED-SUFFIX] for indicating that the media type is encoded as a JSON Web Token (JWT) with a JSON payload.

Name: json+jwt
+suffix: +json+jwt
References: this specification
Encoding considerations: binary; jwt values are a series of base64url-encoded values (some of which may be the empty string) separated by period ('.').
Security considerations:

As defined in this specification. See also the security considerations in JSON Web Token (JWT).

Contact: W3C Verifiable Credentials Working Group public-vc-wg@w3.org
Author/Change Controller: W3C Verifiable Credentials Working Group public-vc-wg@w3.org

6.2.3 +ld+json+sd-jwt

This specification registers the +ld+json+sd-jwt Structured Suffix in the IANA "Structured Syntax Suffixes" registry [IANA-STRUCTURED-SUFFIX] for indicating that the media type is encoded as an Selective Disclosure for JWTs (SD-JWT) with a JSON-LD payload.

Name: ld+json+sd-jwt
+suffix: +ld+json+sd-jwt
References: this specification
Encoding considerations: binary; sd-jwt values are a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') or tilde ('~') characters.
Security considerations:

As defined in this specification. See also the security considerations in Selective Disclosure for JWTs (SD-JWT).

Contact: W3C Verifiable Credentials Working Group public-vc-wg@w3.org
Author/Change Controller: W3C Verifiable Credentials Working Group public-vc-wg@w3.org

6.2.4 +json+sd-jwt

This specification registers the +json+sd-jwt Structured Suffix in the IANA "Structured Syntax Suffixes" registry [IANA-STRUCTURED-SUFFIX] for indicating that the media type is encoded as an Selective Disclosure for JWTs (SD-JWT) with a JSON payload.

Name: json+sd-jwt
+suffix: +json+sd-jwt
References: this specification
Encoding considerations: binary; sd-jwt values are a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') or tilde ('~') characters.
Security considerations:

As defined in this specification. See also the security considerations in Selective Disclosure for JWTs (SD-JWT).

Contact: W3C Verifiable Credentials Working Group public-vc-wg@w3.org
Author/Change Controller: W3C Verifiable Credentials Working Group public-vc-wg@w3.org

6.2.5 +ld+json+cose

This specification registers the +ld+json+cose Structured Suffix in the IANA "Structured Syntax Suffixes" registry [IANA-STRUCTURED-SUFFIX] for indicating that the media type is encoded as a COSE object [RFC9052] with a JSON-LD payload.

Name: ld+json+cose
+suffix: +ld+json+cose
References: this specification
Encoding considerations: binary (CBOR)
Security considerations:

As defined in this specification. See also the security considerations in [RFC9052] and [json-ld11].

Contact: W3C Verifiable Credentials Working Group public-vc-wg@w3.org
Author/Change Controller: W3C Verifiable Credentials Working Group public-vc-wg@w3.org

6.2.6 +json+cose

This specification registers the +json+cose Structured Suffix in the IANA "Structured Syntax Suffixes" registry [IANA-STRUCTURED-SUFFIX] for indicating that the media type is encoded as a COSE object [RFC9052] with a JSON payload.

Name: json+cose
+suffix: +json+cose
References: this specification
Encoding considerations: binary (CBOR)
Security considerations:

As defined in this specification. See also the security considerations in [RFC9052].

Contact: W3C Verifiable Credentials Working Group public-vc-wg@w3.org
Author/Change Controller: W3C Verifiable Credentials Working Group public-vc-wg@w3.org

7. Other Considerations

7.1 Privacy Considerations

Verifiable Credentials often contain sensitive information that needs to be protected to ensure the privacy and security of organizations and individuals. This section outlines some privacy considerations relevant to implementers and users.

Implementers are advised to note and abide by all privacy considerations called out in [VC-DATA-MODEL-2.0].

Implementers are additionally advised to reference the Privacy Consideration section of the JWT specification for privacy guidance.

In addition to the privacy recommendations in the [VC-DATA-MODEL-2.0], the following considerations are given:

These considerations are not exhaustive, and implementers and users are advised to consult additional privacy resources and best practices to ensure the privacy and security of Verifiable Credentials implemented using this specification.

7.2 Security Considerations

This section outlines security considerations for implementers and users of this specification. It is important to carefully consider these factors to ensure the security and integrity of Verifiable Credentials when implemented using JOSE or COSE.

When implementing this specification, it is essential to address all security issues relevant to broad cryptographic applications. This especially includes protecting the user's asymmetric private and symmetric secret keys, as well as employing countermeasures against various attacks. Failure to adequately address these issues could compromise the security and integrity of Verifiable Credentials, potentially leading to unauthorized access, modification, or disclosure of sensitive information.

Implementers are advised to follow best practices and established cryptographic standards to ensure the secure handling of keys and other sensitive data. Additionally, conduct regular security assessments and audits to identify and address any vulnerabilities or threats.

Follow all security considerations outlined in [RFC7515] and [RFC7519].

When utilizing JSON-LD, take special care around remote retrieval of contexts and follow the additional security considerations noted in [json-ld11].

As noted in [RFC7515] when utilizing JSON [RFC7159], strict validation is a security requirement. If malformed JSON is received, it may be impossible to reliably interpret the producer's intent, potentially leading to ambiguous or exploitable situations. To prevent these risks, it is essential to use a JSON parser that strictly validates the syntax of all input data. It is essential that any JSON inputs that do not conform to the JSON-text syntax defined in [RFC7159] be rejected in their entirety by JSON parsers. Failure to reject invalid input could compromise the security and integrity of Verifiable Credentials.

7.3 Accessibility

This section is non-normative.

When implementing this specification, it is crucial for technical implementers to consider various accessibility factors. Ignoring accessibility concerns renders the information unusable for a significant portion of the population. To ensure equal access for all individuals, regardless of their abilities, it is vital to adhere to accessibility guidelines and standards, such as the Web Content Accessibility Guidelines (WCAG 2.1) [WCAG21]. This becomes even more critical when establishing systems that involve cryptography, as they have historically posed challenges for assistive technologies.

Implementers are advised to note and abide by all accessibility considerations called out in [VC-DATA-MODEL-2.0].

8. Examples

This section is non-normative.

8.1 Controllers

Example 22: A minimal controller document
{
  "id": "https://vendor.example",
}
Example 23: A controller document with verification method
{
  "id": "https://university.example/issuers/565049",
  "verificationMethod": [{
    "id": "https://university.example/issuers/565049#key-123",
    "type": "JsonWebKey",
    "controller": "https://university.example/issuers/565049",
    "publicKeyJwk": {
      "kty": "EC",
      "crv": "P-384",
      "alg": "ES384",
      "x": "PxgAmVYOQvSNcMYL2tOzoLwSWn4Ta3tIMPEUKR8pxeb-gmR11-DyKHBoIiY-2LhM",
      "y": "BZEBTkImVdpwvxR9THIRw16eblnj5-tZa7m-ww5uVd4kyPJNRoWUn2aT9ZuarAe-"
    }
  }]
}
Example 24: A controller document with verification relationships
{
  "id": "https://university.example/issuers/565049",
  "verificationMethod": [{
    "id": "https://university.example/issuers/565049#key-123",
    "type": "JsonWebKey",
    "controller": "https://university.example/issuers/565049",
    "publicKeyJwk": {
      "kty": "EC",
      "crv": "P-384",
      "alg": "ES384",
      "x": "PxgAmVYOQvSNcMYL2tOzoLwSWn4Ta3tIMPEUKR8pxeb-gmR11-DyKHBoIiY-2LhM",
      "y": "BZEBTkImVdpwvxR9THIRw16eblnj5-tZa7m-ww5uVd4kyPJNRoWUn2aT9ZuarAe-"
    }
  }],
  "authentication": ["https://university.example/issuers/565049#key-123"],
  "assertionMethod": ["https://university.example/issuers/565049#key-123"]
}
Example 25: A verifiable credential controller document
{
  "@context": [
        "https://www.w3.org/ns/did/v1",
        "https://w3id.org/security/jwk/v1",
        {
            "@vocab": "https://vendor.example#"
        }
  ],
  "id": "did:web:vendor.example",
  "alsoKnownAs": ["https://vendor.example",
    "did:jwk:eyJraWQiOiJ1cm46aWV0ZjpwYXJhbXM6b2F1dGg6andrLXRodW1icHJpbnQ6c2hhLTI1NjpGZk1iek9qTW1RNGVmVDZrdndUSUpqZWxUcWpsMHhqRUlXUTJxb2JzUk1NIiwia3R5IjoiT0tQIiwiY3J2IjoiRWQyNTUxOSIsImFsZyI6IkVkRFNBIiwieCI6IkFOUmpIX3p4Y0tCeHNqUlBVdHpSYnA3RlNWTEtKWFE5QVBYOU1QMWo3azQifQ"
  ],
  "verificationMethod": [{
    "id": "#urn:ietf:params:oauth:jwk-thumbprint:sha-256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs",
    "type": "JsonWebKey",
    "controller": "did:web:vendor.example",
    "publicKeyJwk": {
      "kty": "EC",
      "crv": "P-521",
      "alg": "ES512",
      "x": "AFTyMw-fIYJNg6fBVJvOPOsLxmnNj8HgqMChyRL0swLaefVAc7wrWZ8okQJqMmvv03JRUp277meQZM3JcvXFkH1v",
      "y": "ALn96CrD88b4TClmkl1sk0xk2FgAIda97ZF8TUOjbeWSzbKnN2KB6pqlpbuJ2xIRXvsn5BWQVlAT2JGpGwDNMyV1"
    }
  }, {
    "id": "#z6MkhEdpG12jyQegrr62ACRmNY8gc531W2j9Xo39cHphuCEH",
    "type": "JsonWebKey2020",
    "controller": "https://vendor.example",
    "publicKeyJwk": {
      "kid": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:FfMbzOjMmQ4efT6kvwTIJjelTqjl0xjEIWQ2qobsRMM",
      "kty": "OKP",
      "crv": "Ed25519",
      "alg": "EdDSA",
      "x": "ANRjH_zxcKBxsjRPUtzRbp7FSVLKJXQ9APX9MP1j7k4"
    }
  }, {
    "id": "#subject-authentication",
    "type": "JsonWebKey",
    "controller": "did:web:vendor.example",
    "publicKeyJwk": {
      "kty": "EC",
      "crv": "P-384",
      "alg": "ES384",
      "x": "PxgAmVYOQvSNcMYL2tOzoLwSWn4Ta3tIMPEUKR8pxeb-gmR11-DyKHBoIiY-2LhM",
      "y": "BZEBTkImVdpwvxR9THIRw16eblnj5-tZa7m-ww5uVd4kyPJNRoWUn2aT9ZuarAe-"
    }
  }, {
    "id": "#credential-issuance",
    "type": "JsonWebKey",
    "controller": "did:web:vendor.example",
    "publicKeyJwk": {
      "kty": "EC",
      "crv": "P-256",
      "alg": "ES256",
      "x": "MYvnaI87pfrn3FpTqW-yNiFcF1K7fedJiqapm20_q7c",
      "y": "9YEbT6Tyuc7xp9yRvhOUVKK_NIHkn5HpK9ZMgvK5pVw"
    }
  }, {
    "id": "#key-agreement",
    "type": "JsonWebKey",
    "controller": "did:web:vendor.example",
    "publicKeyJwk": {
      "kty": "OKP",
      "crv": "X25519",
      "alg": "ECDH-ES+A128KW",
      "x": "qLZkSTbstvMWPTivmiQglEFWG2Ff7gNDVoVisdZTr1I"
    }
  }],
  "authentication": ["#subject-authentication"],
  "assertionMethod": ["#credential-issuance"]
}

8.2 Credentials

Example 26: A revocable credential with multiple subjects

application/vc+ld+json

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "https://contoso.example/credentials/23894672394",
  "type": [
    "VerifiableCredential",
    "K9UnitCredential"
  ],
  "issuer": {
    "id": "https://contoso.example"
  },
  "validFrom": "2015-04-16T05:11:32.432Z",
  "credentialStatus": {
    "id": "https://contoso.example/credentials/status/4#273762",
    "type": "StatusList2021Entry",
    "statusPurpose": "revocation",
    "statusListIndex": "273762",
    "statusListCredential": "https://contoso.example/credentials/status/4"
  },
  "credentialSubject": [
    {
      "id": "did:example:1312387641",
      "type": "Person"
    },
    {
      "id": "did:example:63888231",
      "type": "Dog"
    }
  ]
}

application/cbor-diagnostic

/ cose-sign1 / 18([
  / protected / << {
    / alg / 1 : -35 / ES384 /
  } >>,
  / unprotected / {
  },
  / payload / nil,
  / signature / h'b7bf065d...2a12f407'
])

application/vc+ld+json+cose (detached payload)

d28444a1013822a0f65860b7bf065d04c5fe6f15a32495950cd678e856b775137e406f01b945030e1e34cfe2ea0f9eaaace8bfde8b69ab06de3d53cab45ef9e306f26d129e33f8f3b49afb3fa78db75d34ddcf3766fec7bd3f7ba1ed0535eab50949408c84f4dc2a12f407

Protected Headers

{
  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
  "alg": "ES384"
}

application/vc+ld+json

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "https://contoso.example/credentials/23894672394",
  "type": [
    "VerifiableCredential",
    "K9UnitCredential"
  ],
  "issuer": {
    "id": "https://contoso.example"
  },
  "validFrom": "2015-04-16T05:11:32.432Z",
  "credentialStatus": {
    "id": "https://contoso.example/credentials/status/4#273762",
    "type": "StatusList2021Entry",
    "statusPurpose": "revocation",
    "statusListIndex": "273762",
    "statusListCredential": "https://contoso.example/credentials/status/4"
  },
  "credentialSubject": [
    {
      "id": "did:example:1312387641",
      "type": "Person"
    },
    {
      "id": "did:example:63888231",
      "type": "Dog"
    }
  ]
}

application/vc+ld+json+jwt

eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMzODQifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwczovL2NvbnRvc28uZXhhbXBsZS9jcmVkZW50aWFscy8yMzg5NDY3MjM5NCIsInR5cGUiOlsiVmVyaWZpYWJsZUNyZWRlbnRpYWwiLCJLOVVuaXRDcmVkZW50aWFsIl0sImlzc3VlciI6eyJpZCI6Imh0dHBzOi8vY29udG9zby5leGFtcGxlIn0sInZhbGlkRnJvbSI6IjIwMTUtMDQtMTZUMDU6MTE6MzIuNDMyWiIsImNyZWRlbnRpYWxTdGF0dXMiOnsiaWQiOiJodHRwczovL2NvbnRvc28uZXhhbXBsZS9jcmVkZW50aWFscy9zdGF0dXMvNCMyNzM3NjIiLCJ0eXBlIjoiU3RhdHVzTGlzdDIwMjFFbnRyeSIsInN0YXR1c1B1cnBvc2UiOiJyZXZvY2F0aW9uIiwic3RhdHVzTGlzdEluZGV4IjoiMjczNzYyIiwic3RhdHVzTGlzdENyZWRlbnRpYWwiOiJodHRwczovL2NvbnRvc28uZXhhbXBsZS9jcmVkZW50aWFscy9zdGF0dXMvNCJ9LCJjcmVkZW50aWFsU3ViamVjdCI6W3siaWQiOiJkaWQ6ZXhhbXBsZToxMzEyMzg3NjQxIiwidHlwZSI6IlBlcnNvbiJ9LHsiaWQiOiJkaWQ6ZXhhbXBsZTo2Mzg4ODIzMSIsInR5cGUiOiJEb2cifV19.dO3_o88K-1Hf_OHESQEmhMD940eeB1MXdxFzzKv6We6AWw2uvV_fELAoCPEoAoResPPj8gdWQrhejEGiA6vp0yTZew1k7yyBTwxNNmm2l7ShfyPYUXYzowABNAgCG6x8
eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMzODQifQ.eyJfc2RfYWxnIjoic2hhLTI1NiIsIkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy92MiIsImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy9leGFtcGxlcy92MiJdLCJpc3N1ZXIiOnsiX3NkIjpbIlFZcHdLWU1MZUtMaUFFbjFnT1RCVHZTSFNzUGJOLU1wQmltZFJ1V19sUmMiXX0sInZhbGlkRnJvbSI6IjIwMTUtMDQtMTZUMDU6MTE6MzIuNDMyWiIsImNyZWRlbnRpYWxTdGF0dXMiOnsic3RhdHVzUHVycG9zZSI6InJldm9jYXRpb24iLCJzdGF0dXNMaXN0SW5kZXgiOiIyNzM3NjIiLCJzdGF0dXNMaXN0Q3JlZGVudGlhbCI6Imh0dHBzOi8vY29udG9zby5leGFtcGxlL2NyZWRlbnRpYWxzL3N0YXR1cy80IiwiX3NkIjpbIkZGLUtONnZrRWt6NU1taG40SmZOdDFzODJjT2NDQjRvTjF5ZGcxTEtYNk0iLCJUdS1QTWMtOU1PTWNCZl9wQWluOUFDTGx4M3REVGdqdXE0YW1ZUVpOM1lrIl19LCJjcmVkZW50aWFsU3ViamVjdCI6W3siX3NkIjpbIjJJajF5SFFwUE03LU5uSFRVOW5YTmVtUUVoOHpmSlpVcF9SX2Jnd0dEOWciLCJyVTd0LWVZa2RuWGlsUVpRaFdBYnQ1WlZtZXFtUlFhM0UzN3NiOUxSWGJRIl19LHsiX3NkIjpbIllyWWd2bTJNU0VTZ2tHUC1FQkM5UmJ0VzdUaWk0RVdQbWd5blVWeGhjNHciLCJhTk1VRnBWeHVHMk00T0hCa2VzZ2JaaU1ndHFPT0hlaEl4T2hBZEEyNWxJIl19XSwiX3NkIjpbIjRodzJPU1dWb1R4UHUybmxUVG1NVUw2bGF6bzVMQVY4SldCd2x4M1pxSTQiLCJQMmdscldQMVZpTUtaQjZ1SUR2ZHB3YmV5UXhDb3lxYV9XdXdUd0VIa2Q0Il19.Hp-4k6S8Z2rkN2JquVx8qkCr7PQwDwB-UWdRci-_Jrr6Mnd4NJ_tzaky2xHZLJgl1iOEflUYjnXJsDp29tUgJMhcY6JWZuumv8B0lJQVUAJxujf0r_OftEhdNPlfV1_4~WyI1OHpfSnNOVlR5eHJ2SmFjMnlXZkR3IiwgImlkIiwgImh0dHBzOi8vY29udG9zby5leGFtcGxlL2NyZWRlbnRpYWxzLzIzODk0NjcyMzk0Il0~WyI2alI5b2cyUWt2d1hJVGtMVDhpVjVBIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIks5VW5pdENyZWRlbnRpYWwiXV0~WyJGQ2gyZDRNOUZMWUJQUGRPamVzTTVRIiwgImlkIiwgImh0dHBzOi8vY29udG9zby5leGFtcGxlIl0~WyJ2RDNsby1KX01MczNwSGRuekVtLWJnIiwgImlkIiwgImh0dHBzOi8vY29udG9zby5leGFtcGxlL2NyZWRlbnRpYWxzL3N0YXR1cy80IzI3Mzc2MiJd~WyJlWFNsM3p3a0pzeFRZUVota0RqSFlBIiwgInR5cGUiLCAiU3RhdHVzTGlzdDIwMjFFbnRyeSJd~WyJBcVB1M1ZOYUNCbWw0M3NjVmREUVFnIiwgImlkIiwgImRpZDpleGFtcGxlOjEzMTIzODc2NDEiXQ~WyJWZDY2cndQaWRwdGY4elA1TmQ2dkd3IiwgInR5cGUiLCAiUGVyc29uIl0~WyIxVFMyMS1KYWlfTXZWQ0RDV01PNUh3IiwgImlkIiwgImRpZDpleGFtcGxlOjYzODg4MjMxIl0~WyJ3UUIzRWhUZkU4Y1VsY185OGhZVDNnIiwgInR5cGUiLCAiRG9nIl0
{
  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
  "alg": "ES384"
}
{
  "_sd_alg": "sha-256",
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "issuer": {
    "_sd": [
      "QYpwKYMLeKLiAEn1gOTBTvSHSsPbN-MpBimdRuW_lRc"
    ]
  },
  "validFrom": "2015-04-16T05:11:32.432Z",
  "credentialStatus": {
    "statusPurpose": "revocation",
    "statusListIndex": "273762",
    "statusListCredential": "https://contoso.example/credentials/status/4",
    "_sd": [
      "FF-KN6vkEkz5Mmhn4JfNt1s82cOcCB4oN1ydg1LKX6M",
      "Tu-PMc-9MOMcBf_pAin9ACLlx3tDTgjuq4amYQZN3Yk"
    ]
  },
  "credentialSubject": [
    {
      "_sd": [
        "2Ij1yHQpPM7-NnHTU9nXNemQEh8zfJZUp_R_bgwGD9g",
        "rU7t-eYkdnXilQZQhWAbt5ZVmeqmRQa3E37sb9LRXbQ"
      ]
    },
    {
      "_sd": [
        "YrYgvm2MSESgkGP-EBC9RbtW7Tii4EWPmgynUVxhc4w",
        "aNMUFpVxuG2M4OHBkesgbZiMgtqOOHehIxOhAdA25lI"
      ]
    }
  ],
  "_sd": [
    "4hw2OSWVoTxPu2nlTTmMUL6lazo5LAV8JWBwlx3ZqI4",
    "P2glrWP1ViMKZB6uIDvdpwbeyQxCoyqa_WuwTwEHkd4"
  ]
}

Claim: id

SHA-256 Hash: 4hw2OSWVoTxPu2nlTTmMUL6lazo5LAV8JWBwlx3ZqI4

Disclosure(s): WyI1OHpfSnNOVlR5eHJ2SmFjMnlXZkR3IiwgImlkIiwgImh0dHBzOi8vY29udG9zby5leGFtcGxlL2NyZWRlbnRpYWxzLzIzODk0NjcyMzk0Il0

Contents: [
  "58z_JsNVTyxrvJac2yWfDw",
  "id",
  "https://contoso.example/credentials/23894672394"
]

Claim: type

SHA-256 Hash: P2glrWP1ViMKZB6uIDvdpwbeyQxCoyqa_WuwTwEHkd4

Disclosure(s): WyI2alI5b2cyUWt2d1hJVGtMVDhpVjVBIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIks5VW5pdENyZWRlbnRpYWwiXV0

Contents: [
  "6jR9og2QkvwXITkLT8iV5A",
  "type",
  [
    "VerifiableCredential",
    "K9UnitCredential"
  ]
]

Claim: id

SHA-256 Hash: QYpwKYMLeKLiAEn1gOTBTvSHSsPbN-MpBimdRuW_lRc

Disclosure(s): WyJGQ2gyZDRNOUZMWUJQUGRPamVzTTVRIiwgImlkIiwgImh0dHBzOi8vY29udG9zby5leGFtcGxlIl0

Contents: [
  "FCh2d4M9FLYBPPdOjesM5Q",
  "id",
  "https://contoso.example"
]

Claim: id

SHA-256 Hash: FF-KN6vkEkz5Mmhn4JfNt1s82cOcCB4oN1ydg1LKX6M

Disclosure(s): WyJ2RDNsby1KX01MczNwSGRuekVtLWJnIiwgImlkIiwgImh0dHBzOi8vY29udG9zby5leGFtcGxlL2NyZWRlbnRpYWxzL3N0YXR1cy80IzI3Mzc2MiJd

Contents: [
  "vD3lo-J_MLs3pHdnzEm-bg",
  "id",
  "https://contoso.example/credentials/status/4#273762"
]

Claim: type

SHA-256 Hash: Tu-PMc-9MOMcBf_pAin9ACLlx3tDTgjuq4amYQZN3Yk

Disclosure(s): WyJlWFNsM3p3a0pzeFRZUVota0RqSFlBIiwgInR5cGUiLCAiU3RhdHVzTGlzdDIwMjFFbnRyeSJd

Contents: [
  "eXSl3zwkJsxTYQZ-kDjHYA",
  "type",
  "StatusList2021Entry"
]

Claim: id

SHA-256 Hash: 2Ij1yHQpPM7-NnHTU9nXNemQEh8zfJZUp_R_bgwGD9g

Disclosure(s): WyJBcVB1M1ZOYUNCbWw0M3NjVmREUVFnIiwgImlkIiwgImRpZDpleGFtcGxlOjEzMTIzODc2NDEiXQ

Contents: [
  "AqPu3VNaCBml43scVdDQQg",
  "id",
  "did:example:1312387641"
]

Claim: type

SHA-256 Hash: rU7t-eYkdnXilQZQhWAbt5ZVmeqmRQa3E37sb9LRXbQ

Disclosure(s): WyJWZDY2cndQaWRwdGY4elA1TmQ2dkd3IiwgInR5cGUiLCAiUGVyc29uIl0

Contents: [
  "Vd66rwPidptf8zP5Nd6vGw",
  "type",
  "Person"
]

Claim: id

SHA-256 Hash: YrYgvm2MSESgkGP-EBC9RbtW7Tii4EWPmgynUVxhc4w

Disclosure(s): WyIxVFMyMS1KYWlfTXZWQ0RDV01PNUh3IiwgImlkIiwgImRpZDpleGFtcGxlOjYzODg4MjMxIl0

Contents: [
  "1TS21-Jai_MvVCDCWMO5Hw",
  "id",
  "did:example:63888231"
]

Claim: type

SHA-256 Hash: aNMUFpVxuG2M4OHBkesgbZiMgtqOOHehIxOhAdA25lI

Disclosure(s): WyJ3UUIzRWhUZkU4Y1VsY185OGhZVDNnIiwgInR5cGUiLCAiRG9nIl0

Contents: [
  "wQB3EhTfE8cUlc_98hYT3g",
  "type",
  "Dog"
]

Example 27: A credential with a schema

application/vc+ld+json

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "https://contoso.example/credentials/35327255",
  "type": [
    "VerifiableCredential",
    "KYCExample"
  ],
  "issuer": "did:web:contoso.example",
  "validFrom": "2019-05-25T03:10:16.992Z",
  "validUntil": "2027-05-25T03:10:16.992Z",
  "credentialSchema": {
    "id": "https://contoso.example/bafybeigdyr...lqabf3oclgtqy55fbzdi",
    "type": "JsonSchema"
  },
  "credentialSubject": {
    "id": "did:example:1231588",
    "type": "Person"
  }
}

application/cbor-diagnostic

/ cose-sign1 / 18([
  / protected / << {
    / alg / 1 : -35 / ES384 /
  } >>,
  / unprotected / {
  },
  / payload / nil,
  / signature / h'ffffab3a...0ad09e62'
])

application/vc+ld+json+cose (detached payload)

d28444a1013822a0f65860ffffab3abf653c77647b0d5b28a7a0481e9511f2f8ded33cdbd11d087d7a196a91b7a97ff13d24bae9b9690e6106f7aceefd4079ac6008402e4ca8d7491bdc2c94392e1a6d83010c4338d199dc80429a16bf8bdebc5aab3cca4aec050ad09e62

Protected Headers

{
  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
  "alg": "ES384"
}

application/vc+ld+json

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "https://contoso.example/credentials/35327255",
  "type": [
    "VerifiableCredential",
    "KYCExample"
  ],
  "issuer": "did:web:contoso.example",
  "validFrom": "2019-05-25T03:10:16.992Z",
  "validUntil": "2027-05-25T03:10:16.992Z",
  "credentialSchema": {
    "id": "https://contoso.example/bafybeigdyr...lqabf3oclgtqy55fbzdi",
    "type": "JsonSchema"
  },
  "credentialSubject": {
    "id": "did:example:1231588",
    "type": "Person"
  }
}

application/vc+ld+json+jwt

eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMzODQifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwczovL2NvbnRvc28uZXhhbXBsZS9jcmVkZW50aWFscy8zNTMyNzI1NSIsInR5cGUiOlsiVmVyaWZpYWJsZUNyZWRlbnRpYWwiLCJLWUNFeGFtcGxlIl0sImlzc3VlciI6ImRpZDp3ZWI6Y29udG9zby5leGFtcGxlIiwidmFsaWRGcm9tIjoiMjAxOS0wNS0yNVQwMzoxMDoxNi45OTJaIiwidmFsaWRVbnRpbCI6IjIwMjctMDUtMjVUMDM6MTA6MTYuOTkyWiIsImNyZWRlbnRpYWxTY2hlbWEiOnsiaWQiOiJodHRwczovL2NvbnRvc28uZXhhbXBsZS9iYWZ5YmVpZ2R5ci4uLmxxYWJmM29jbGd0cXk1NWZiemRpIiwidHlwZSI6Ikpzb25TY2hlbWEifSwiY3JlZGVudGlhbFN1YmplY3QiOnsiaWQiOiJkaWQ6ZXhhbXBsZToxMjMxNTg4IiwidHlwZSI6IlBlcnNvbiJ9fQ.fIisesXLfhHtBloWj-a-BJakl2bSEDq45Elzesm8gMr_76FgveUHIq20tyi05cGDWGmDq67yeUyDFzPZk87MiS16ft7lvArM7268MgkSNmpwIlmCk-ymk1C7fAdYLp3z
eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMzODQifQ.eyJfc2RfYWxnIjoic2hhLTI1NiIsIkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy92MiIsImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy9leGFtcGxlcy92MiJdLCJpc3N1ZXIiOiJkaWQ6d2ViOmNvbnRvc28uZXhhbXBsZSIsInZhbGlkRnJvbSI6IjIwMTktMDUtMjVUMDM6MTA6MTYuOTkyWiIsInZhbGlkVW50aWwiOiIyMDI3LTA1LTI1VDAzOjEwOjE2Ljk5MloiLCJjcmVkZW50aWFsU2NoZW1hIjp7Il9zZCI6WyJGXzNLOWd1bmpYaWNyYm1EWlRST2p2LUZIWDdoNm1WdHZybkhvTWdnUS1zIiwiZnhBZmRnSFpqRWhwWVM3Z2l2djJxMWkzcFhpZDE1UXk5cTUtMVlON05MbyJdfSwiY3JlZGVudGlhbFN1YmplY3QiOnsiX3NkIjpbIkRHcTdJdXRWT1NrcUR5bGlHMG1LRWEtTlBVdjdCYkExVVVHVmRPVTRSMzgiLCJZLUUyYjlHLThTeWhvRl9qcDlFNWZBNVBoUjlXcDVDanBIZVhiQUtNMGNBIl19LCJfc2QiOlsiTXpTaHhXVmFnbnlSQ2h6OW0xam9zRk4wLUJhcXFSLW82Yk1DXzV3TkZMSSIsImVaRWl5RFpFd09tUllhNHBJWEdzSkpPdTBDOFVZN3JTTEJVemRlTDhkS0EiXX0.5bFvyxgDojzyR1A92YlpEwiKWBoyCXLk6UBmzbejremb4fXQT8b8rEnmJFHy-Yh49pWuLs_zOxLz1rhh_p90H1Vha77Rm-JNP-cVTKxPyeaR843umpztSyjstSJIQwyC~WyJnVW5TblRibzY3dURPaG1OVjBUU25BIiwgImlkIiwgImh0dHBzOi8vY29udG9zby5leGFtcGxlL2NyZWRlbnRpYWxzLzM1MzI3MjU1Il0~WyJfdjhZWU9GX216TTNEQXlOT0FNMEV3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIktZQ0V4YW1wbGUiXV0~WyJ3VV9jLWp2dlB1aExCY3h0UGY1X0pBIiwgImlkIiwgImh0dHBzOi8vY29udG9zby5leGFtcGxlL2JhZnliZWlnZHlyLi4ubHFhYmYzb2NsZ3RxeTU1ZmJ6ZGkiXQ~WyJXVmJSOHBDVVNMVFd4dnk4eWhrOUF3IiwgInR5cGUiLCAiSnNvblNjaGVtYSJd~WyJWSjJzREFvRGR3dnN3V2pkN2tjemVRIiwgImlkIiwgImRpZDpleGFtcGxlOjEyMzE1ODgiXQ~WyItOHg1Ul9TRURJcUtrVG5mdnlBNWdnIiwgInR5cGUiLCAiUGVyc29uIl0
{
  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
  "alg": "ES384"
}
{
  "_sd_alg": "sha-256",
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "issuer": "did:web:contoso.example",
  "validFrom": "2019-05-25T03:10:16.992Z",
  "validUntil": "2027-05-25T03:10:16.992Z",
  "credentialSchema": {
    "_sd": [
      "F_3K9gunjXicrbmDZTROjv-FHX7h6mVtvrnHoMggQ-s",
      "fxAfdgHZjEhpYS7givv2q1i3pXid15Qy9q5-1YN7NLo"
    ]
  },
  "credentialSubject": {
    "_sd": [
      "DGq7IutVOSkqDyliG0mKEa-NPUv7BbA1UUGVdOU4R38",
      "Y-E2b9G-8SyhoF_jp9E5fA5PhR9Wp5CjpHeXbAKM0cA"
    ]
  },
  "_sd": [
    "MzShxWVagnyRChz9m1josFN0-BaqqR-o6bMC_5wNFLI",
    "eZEiyDZEwOmRYa4pIXGsJJOu0C8UY7rSLBUzdeL8dKA"
  ]
}

Claim: id

SHA-256 Hash: eZEiyDZEwOmRYa4pIXGsJJOu0C8UY7rSLBUzdeL8dKA

Disclosure(s): WyJnVW5TblRibzY3dURPaG1OVjBUU25BIiwgImlkIiwgImh0dHBzOi8vY29udG9zby5leGFtcGxlL2NyZWRlbnRpYWxzLzM1MzI3MjU1Il0

Contents: [
  "gUnSnTbo67uDOhmNV0TSnA",
  "id",
  "https://contoso.example/credentials/35327255"
]

Claim: type

SHA-256 Hash: MzShxWVagnyRChz9m1josFN0-BaqqR-o6bMC_5wNFLI

Disclosure(s): WyJfdjhZWU9GX216TTNEQXlOT0FNMEV3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIktZQ0V4YW1wbGUiXV0

Contents: [
  "_v8YYOF_mzM3DAyNOAM0Ew",
  "type",
  [
    "VerifiableCredential",
    "KYCExample"
  ]
]

Claim: id

SHA-256 Hash: F_3K9gunjXicrbmDZTROjv-FHX7h6mVtvrnHoMggQ-s

Disclosure(s): WyJ3VV9jLWp2dlB1aExCY3h0UGY1X0pBIiwgImlkIiwgImh0dHBzOi8vY29udG9zby5leGFtcGxlL2JhZnliZWlnZHlyLi4ubHFhYmYzb2NsZ3RxeTU1ZmJ6ZGkiXQ

Contents: [
  "wU_c-jvvPuhLBcxtPf5_JA",
  "id",
  "https://contoso.example/bafybeigdyr...lqabf3oclgtqy55fbzdi"
]

Claim: type

SHA-256 Hash: fxAfdgHZjEhpYS7givv2q1i3pXid15Qy9q5-1YN7NLo

Disclosure(s): WyJXVmJSOHBDVVNMVFd4dnk4eWhrOUF3IiwgInR5cGUiLCAiSnNvblNjaGVtYSJd

Contents: [
  "WVbR8pCUSLTWxvy8yhk9Aw",
  "type",
  "JsonSchema"
]

Claim: id

SHA-256 Hash: DGq7IutVOSkqDyliG0mKEa-NPUv7BbA1UUGVdOU4R38

Disclosure(s): WyJWSjJzREFvRGR3dnN3V2pkN2tjemVRIiwgImlkIiwgImRpZDpleGFtcGxlOjEyMzE1ODgiXQ

Contents: [
  "VJ2sDAoDdwvswWjd7kczeQ",
  "id",
  "did:example:1231588"
]

Claim: type

SHA-256 Hash: Y-E2b9G-8SyhoF_jp9E5fA5PhR9Wp5CjpHeXbAKM0cA

Disclosure(s): WyItOHg1Ul9TRURJcUtrVG5mdnlBNWdnIiwgInR5cGUiLCAiUGVyc29uIl0

Contents: [
  "-8x5R_SEDIqKkTnfvyA5gg",
  "type",
  "Person"
]

8.3 Presentations

Example 28: Presentation

application/vp+ld+json

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": "VerifiablePresentation",
  "verifiableCredential": [
    {
      "@context": "https://www.w3.org/ns/credentials/v2",
      "id": "data:application/vc+ld+json+cose;base64url,UXpWalYuLi5STWpV",
      "type": "EnvelopedVerifiableCredential"
    },
    {
      "@context": "https://www.w3.org/ns/credentials/v2",
      "id": "data:application/vc+ld+json+jwt;eyVjV...RMjU",
      "type": "EnvelopedVerifiableCredential"
    },
    {
      "@context": "https://www.w3.org/ns/credentials/v2",
      "id": "data:application/vc+ld+json+sd-jwt;eyVjV...RMjU",
      "type": "EnvelopedVerifiableCredential"
    }
  ]
}

application/cbor-diagnostic

/ cose-sign1 / 18([
  / protected / << {
    / alg / 1 : -35 / ES384 /
  } >>,
  / unprotected / {
  },
  / payload / nil,
  / signature / h'788a0db3...2f876726'
])

application/vp+ld+json+cose (detached payload)

d28444a1013822a0f65860788a0db39676d1c398c72e424f56b08734c26c170c869bba080ff34752560731145b37f5d0d56938e0408c562374bc8648867eb266b976afae91fc442810454ae8c2d6e021a8bb79c45ea1bdb6589d928b8741569481a97311ad69002f876726

Protected Headers

{
  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
  "alg": "ES384"
}

application/vp+ld+json

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": "VerifiablePresentation",
  "verifiableCredential": [
    {
      "@context": "https://www.w3.org/ns/credentials/v2",
      "id": "data:application/vc+ld+json+cose;base64url,VVhwV2FsWXVMaTVTVFdwVg",
      "type": "EnvelopedVerifiableCredential"
    },
    {
      "@context": "https://www.w3.org/ns/credentials/v2",
      "id": "data:application/vc+ld+json+jwt;eyVjV...RMjU",
      "type": "EnvelopedVerifiableCredential"
    },
    {
      "@context": "https://www.w3.org/ns/credentials/v2",
      "id": "data:application/vc+ld+json+sd-jwt;eyVjV...RMjU",
      "type": "EnvelopedVerifiableCredential"
    }
  ]
}

application/vp+ld+json+jwt

eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMzODQifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwidHlwZSI6IlZlcmlmaWFibGVQcmVzZW50YXRpb24iLCJ2ZXJpZmlhYmxlQ3JlZGVudGlhbCI6W3siQGNvbnRleHQiOiJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJpZCI6ImRhdGE6YXBwbGljYXRpb24vdmMrbGQranNvbitjb3NlO2Jhc2U2NHVybCxWVmh3VjJGc1dYVk1hVFZUVkZkd1ZnIiwidHlwZSI6IkVudmVsb3BlZFZlcmlmaWFibGVDcmVkZW50aWFsIn0seyJAY29udGV4dCI6Imh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy92MiIsImlkIjoiZGF0YTphcHBsaWNhdGlvbi92YytsZCtqc29uK2p3dDtleVZqVi4uLlJNalUiLCJ0eXBlIjoiRW52ZWxvcGVkVmVyaWZpYWJsZUNyZWRlbnRpYWwifSx7IkBjb250ZXh0IjoiaHR0cHM6Ly93d3cudzMub3JnL25zL2NyZWRlbnRpYWxzL3YyIiwiaWQiOiJkYXRhOmFwcGxpY2F0aW9uL3ZjK2xkK2pzb24rc2Qtand0O2V5VmpWLi4uUk1qVSIsInR5cGUiOiJFbnZlbG9wZWRWZXJpZmlhYmxlQ3JlZGVudGlhbCJ9XX0.0h9cGwxYlLFhaHe6tVZWf1tG7ziLmbKNCS38e3-KGGMcP0_OAJwc40xXC4NvuvnRtvLUo5EyjJSeiY07Vg5zRTh9KX26s93FVHxXe0sBruXajlWmKBZdek89qoGX-QPV
eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMzODQifQ.eyJfc2RfYWxnIjoic2hhLTI1NiIsIkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy92MiIsImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy9leGFtcGxlcy92MiJdLCJ2ZXJpZmlhYmxlQ3JlZGVudGlhbCI6W3siQGNvbnRleHQiOiJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJfc2QiOlsiV09jRENBOU5FWlhTZXJNRVhOMmZRUUVvUGxfREhyNzVmbUlEWWo0cHU0cyIsImstOXM1T2o4aTAtd2Z1MnJzaGdTZlZwYnNTNGs5YUpFYnozbHpuX0FwUnciXX0seyJAY29udGV4dCI6Imh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy92MiIsIl9zZCI6WyJSOEVMalpfWGlhYmpBZzdISXkyUVR5SE5fM1MtRWhoYVVVc1NvRFA0M1BnIiwiWjFDNk5pR2k0bHVrVnJqd0dUaHZtekkxbnc0MzVwcjlyUmtJN0M5aEt6byJdfSx7IkBjb250ZXh0IjoiaHR0cHM6Ly93d3cudzMub3JnL25zL2NyZWRlbnRpYWxzL3YyIiwiX3NkIjpbIjZvOTBqNW1MQUlDRU51N3dpREpxSlB4cnFoVzMwVWVHQXhJTnBIWlBwQkUiLCJtXzVmZ2gzQlU0RVRBT0E0MTU5bWJYQldvTVZpdEkyY3RKd3RiakpNTHJzIl19XSwiX3NkIjpbIkVkV1lOeFhYNGdTcHRySmFuSWVDcHUzd2V1bVBSV19TZERKblliQ05mTmMiXX0.wCwrRdY9nXBD9QZBOmGGv0x2ul2YnY25HnF530pGTukk9HLlKpGrM08sqq0um79loCypmp7PV6JlwJ5NYo0YsR7VeugW4BI4-yhVWFNt1YJJmhMod-gKG8asPPXxPPtu~WyJGR3QzdkFfY1RSZEZnU0RsNzdBZDRBIiwgInR5cGUiLCAiVmVyaWZpYWJsZVByZXNlbnRhdGlvbiJd~WyJRaUhMemtBS1FobnJoV0V1RkFOeDlBIiwgImlkIiwgImRhdGE6YXBwbGljYXRpb24vdmMrbGQranNvbitjb3NlO2Jhc2U2NHVybCwgVlZod1YyRnNXWFZNYVRWVFZGZHdWZyJd~WyJaQ0dqSnJqbm92N0MwSjg1b1h3LXZBIiwgInR5cGUiLCAiRW52ZWxvcGVkVmVyaWZpYWJsZUNyZWRlbnRpYWwiXQ~WyJkbTNXbFc4OGFaZnBDVDhqWTVoVUpRIiwgImlkIiwgImRhdGE6YXBwbGljYXRpb24vdmMrbGQranNvbitqd3Q7ZXlWalYuLi5STWpVIl0~WyJIa0Z0WkRrSk5jdDFzdnpVd2NQOUhRIiwgInR5cGUiLCAiRW52ZWxvcGVkVmVyaWZpYWJsZUNyZWRlbnRpYWwiXQ~WyJnTDRtX3lqTW9wNTBOcHJ2T0h2cjd3IiwgImlkIiwgImRhdGE6YXBwbGljYXRpb24vdmMrbGQranNvbitzZC1qd3Q7ZXlWalYuLi5STWpVIl0~WyJIeUdUcXZscTJycjV1M1RSeWpKYnFRIiwgInR5cGUiLCAiRW52ZWxvcGVkVmVyaWZpYWJsZUNyZWRlbnRpYWwiXQ
{
  "kid": "ExHkBMW9fmbkvV266mRpuP2sUY_N_EWIN1lapUzO8ro",
  "alg": "ES384"
}
{
  "_sd_alg": "sha-256",
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "verifiableCredential": [
    {
      "@context": "https://www.w3.org/ns/credentials/v2",
      "_sd": [
        "WOcDCA9NEZXSerMEXN2fQQEoPl_DHr75fmIDYj4pu4s",
        "k-9s5Oj8i0-wfu2rshgSfVpbsS4k9aJEbz3lzn_ApRw"
      ]
    },
    {
      "@context": "https://www.w3.org/ns/credentials/v2",
      "_sd": [
        "R8ELjZ_XiabjAg7HIy2QTyHN_3S-EhhaUUsSoDP43Pg",
        "Z1C6NiGi4lukVrjwGThvmzI1nw435pr9rRkI7C9hKzo"
      ]
    },
    {
      "@context": "https://www.w3.org/ns/credentials/v2",
      "_sd": [
        "6o90j5mLAICENu7wiDJqJPxrqhW30UeGAxINpHZPpBE",
        "m_5fgh3BU4ETAOA4159mbXBWoMVitI2ctJwtbjJMLrs"
      ]
    }
  ],
  "_sd": [
    "EdWYNxXX4gSptrJanIeCpu3weumPRW_SdDJnYbCNfNc"
  ]
}

Claim: type

SHA-256 Hash: EdWYNxXX4gSptrJanIeCpu3weumPRW_SdDJnYbCNfNc

Disclosure(s): WyJGR3QzdkFfY1RSZEZnU0RsNzdBZDRBIiwgInR5cGUiLCAiVmVyaWZpYWJsZVByZXNlbnRhdGlvbiJd

Contents: [
  "FGt3vA_cTRdFgSDl77Ad4A",
  "type",
  "VerifiablePresentation"
]

Claim: id

SHA-256 Hash: WOcDCA9NEZXSerMEXN2fQQEoPl_DHr75fmIDYj4pu4s

Disclosure(s): WyJRaUhMemtBS1FobnJoV0V1RkFOeDlBIiwgImlkIiwgImRhdGE6YXBwbGljYXRpb24vdmMrbGQranNvbitjb3NlO2Jhc2U2NHVybCwgVlZod1YyRnNXWFZNYVRWVFZGZHdWZyJd

Contents: [
  "QiHLzkAKQhnrhWEuFANx9A",
  "id",
  "data:application/vc+ld+json+cose;base64url, VVhwV2FsWXVMaTVTVFdwVg"
]

Claim: type

SHA-256 Hash: k-9s5Oj8i0-wfu2rshgSfVpbsS4k9aJEbz3lzn_ApRw

Disclosure(s): WyJaQ0dqSnJqbm92N0MwSjg1b1h3LXZBIiwgInR5cGUiLCAiRW52ZWxvcGVkVmVyaWZpYWJsZUNyZWRlbnRpYWwiXQ

Contents: [
  "ZCGjJrjnov7C0J85oXw-vA",
  "type",
  "EnvelopedVerifiableCredential"
]

Claim: id

SHA-256 Hash: R8ELjZ_XiabjAg7HIy2QTyHN_3S-EhhaUUsSoDP43Pg

Disclosure(s): WyJkbTNXbFc4OGFaZnBDVDhqWTVoVUpRIiwgImlkIiwgImRhdGE6YXBwbGljYXRpb24vdmMrbGQranNvbitqd3Q7ZXlWalYuLi5STWpVIl0

Contents: [
  "dm3WlW88aZfpCT8jY5hUJQ",
  "id",
  "data:application/vc+ld+json+jwt;eyVjV...RMjU"
]

Claim: type

SHA-256 Hash: Z1C6NiGi4lukVrjwGThvmzI1nw435pr9rRkI7C9hKzo

Disclosure(s): WyJIa0Z0WkRrSk5jdDFzdnpVd2NQOUhRIiwgInR5cGUiLCAiRW52ZWxvcGVkVmVyaWZpYWJsZUNyZWRlbnRpYWwiXQ

Contents: [
  "HkFtZDkJNct1svzUwcP9HQ",
  "type",
  "EnvelopedVerifiableCredential"
]

Claim: id

SHA-256 Hash: 6o90j5mLAICENu7wiDJqJPxrqhW30UeGAxINpHZPpBE

Disclosure(s): WyJnTDRtX3lqTW9wNTBOcHJ2T0h2cjd3IiwgImlkIiwgImRhdGE6YXBwbGljYXRpb24vdmMrbGQranNvbitzZC1qd3Q7ZXlWalYuLi5STWpVIl0

Contents: [
  "gL4m_yjMop50NprvOHvr7w",
  "id",
  "data:application/vc+ld+json+sd-jwt;eyVjV...RMjU"
]

Claim: type

SHA-256 Hash: m_5fgh3BU4ETAOA4159mbXBWoMVitI2ctJwtbjJMLrs

Disclosure(s): WyJIeUdUcXZscTJycjV1M1RSeWpKYnFRIiwgInR5cGUiLCAiRW52ZWxvcGVkVmVyaWZpYWJsZUNyZWRlbnRpYWwiXQ

Contents: [
  "HyGTqvlq2rr5u3TRyjJbqQ",
  "type",
  "EnvelopedVerifiableCredential"
]

8.4 Data URIs

Example 29: A simple URI-encoded Verifiable Credential
data:application/vc+ld+json+sd-jwt;eyJhbGciOiJFUzM4NCIsImtpZCI6IlNJM1JITm91aDhvODFOT09OUFFVQUw3RWdaLWtJNl94ajlvUkV2WDF4T3ciLCJ0eXAiOiJ2YytsZCtqc29uK3NkLWp3dCIsImN0eSI6InZjK2xkK2pzb24ifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTY2hlbWEiOnsiX3NkIjpbIkU3dU1sSWFyS29iYXJTdEZGRjctZm5qaV9sQVdnM3BGMkV5dVc4dWFYakUiLCJYelRaSVgyNGdDSWxSQVFHclFoNU5FRm1XWkQtZ3Z3dkIybzB5Y0FwNFZzIl19LCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsibmFtZSI6IkJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMiLCJfc2QiOlsiT3oxUEZIMG0tWk9TdEhwUVZyeGlmVlpKRzhvNmlQQmNnLVZ2SXQwd2plcyJdfSwiX3NkIjpbIkVZQ1daMTZZMHB5X1VNNzRHU3NVYU9zT19mdDExTlVSaFFUTS1TT1lFTVEiXX0sIl9zZCI6WyJqT055NnZUbGNvVlAzM25oSTdERGN3ekVka3d2R3VVRXlLUjdrWEVLd3VVIiwid21BdHpwc0dRbDJveS1PY2JrSEVZcE8xb3BoX3VYcWVWVTRKekF0aFFibyJdLCJfc2RfYWxnIjoic2hhLTI1NiIsImlzcyI6Imh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL2lzc3VlcnMvNTY1MDQ5IiwiaWF0IjoxNjk3Mjg5OTk2LCJleHAiOjE3Mjg5MTIzOTYsImNuZiI6eyJqd2siOnsia3R5IjoiRUMiLCJjcnYiOiJQLTM4NCIsImFsZyI6IkVTMzg0IiwieCI6InZFdV84WGxZT0ZFU2hTcVRpZ2JSYWduZ0ZGM1p5U0xrclNHekh3azFBT1loanhlazVhV21HY2UwZU05S0pWOEIiLCJ5IjoiRUpNY2czWXBzUTB3M2RLNHlVa25QczE1Z0lsY2Yyay03dzFKLTNlYlBiOERENmQtUkhBeGUwMDkzSWpfdTRCOSJ9fX0.rYzbxb6j1dwop8_s491iArVVJNm6A6C3b742gOm_qYO3zdkyQU4_VxxOSJ8ECcmWj2r5KyiCNC1ojfO4Yms-zBsjt7PoMYpYWBplsqXpiIvnehmM7D0eOLi40uHXki0X~WyJSWTg1YTZNMmEwX3VDWlFTVGZmTFdRIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMTg3MiJd~WyJMeG5GYTBXVm8wRUluVy1QdS1fd1dRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl1d~WyJUQVdrakpCaVpxdC1rVU54X1EweUJBIiwgImlkIiwgImh0dHBzOi8vZXhhbXBsZS5vcmcvZXhhbXBsZXMvZGVncmVlLmpzb24iXQ~WyJTd2xuZFpPZzZEZ1ZERFp5X0RvYVFBIiwgInR5cGUiLCAiSnNvblNjaGVtYSJd~WyJuSnJlU3E1Nzg3RGZMSDJCbU03cXFRIiwgImlkIiwgImRpZDpleGFtcGxlOjEyMyJd~WyIxMjNNd3hNcHRiek02YUk2aW03ME1RIiwgInR5cGUiLCAiQmFjaGVsb3JEZWdyZWUiXQ
Example 30: A simple URI-encoded Verifiable Presentation
data:application/vp+ld+json+sd-jwt;eyJhbGciOiJFUzM4NCIsImtpZCI6IlNJM1JITm91aDhvODFOT09OUFFVQUw3RWdaLWtJNl94ajlvUkV2WDF4T3ciLCJ0eXAiOiJ2YytsZCtqc29uK3NkLWp3dCIsImN0eSI6InZjK2xkK2pzb24ifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTY2hlbWEiOnsiX3NkIjpbIkU3dU1sSWFyS29iYXJTdEZGRjctZm5qaV9sQVdnM3BGMkV5dVc4dWFYakUiLCJYelRaSVgyNGdDSWxSQVFHclFoNU5FRm1XWkQtZ3Z3dkIybzB5Y0FwNFZzIl19LCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsibmFtZSI6IkJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMiLCJfc2QiOlsiT3oxUEZIMG0tWk9TdEhwUVZyeGlmVlpKRzhvNmlQQmNnLVZ2SXQwd2plcyJdfSwiX3NkIjpbIkVZQ1daMTZZMHB5X1VNNzRHU3NVYU9zT19mdDExTlVSaFFUTS1TT1lFTVEiXX0sIl9zZCI6WyJqT055NnZUbGNvVlAzM25oSTdERGN3ekVka3d2R3VVRXlLUjdrWEVLd3VVIiwid21BdHpwc0dRbDJveS1PY2JrSEVZcE8xb3BoX3VYcWVWVTRKekF0aFFibyJdLCJfc2RfYWxnIjoic2hhLTI1NiIsImlzcyI6Imh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL2lzc3VlcnMvNTY1MDQ5IiwiaWF0IjoxNjk3Mjg5OTk2LCJleHAiOjE3Mjg5MTIzOTYsImNuZiI6eyJqd2siOnsia3R5IjoiRUMiLCJjcnYiOiJQLTM4NCIsImFsZyI6IkVTMzg0IiwieCI6InZFdV84WGxZT0ZFU2hTcVRpZ2JSYWduZ0ZGM1p5U0xrclNHekh3azFBT1loanhlazVhV21HY2UwZU05S0pWOEIiLCJ5IjoiRUpNY2czWXBzUTB3M2RLNHlVa25QczE1Z0lsY2Yyay03dzFKLTNlYlBiOERENmQtUkhBeGUwMDkzSWpfdTRCOSJ9fX0.rYzbxb6j1dwop8_s491iArVVJNm6A6C3b742gOm_qYO3zdkyQU4_VxxOSJ8ECcmWj2r5KyiCNC1ojfO4Yms-zBsjt7PoMYpYWBplsqXpiIvnehmM7D0eOLi40uHXki0X~WyJTd2xuZFpPZzZEZ1ZERFp5X0RvYVFBIiwgInR5cGUiLCAiSnNvblNjaGVtYSJd~WyIxMjNNd3hNcHRiek02YUk2aW03ME1RIiwgInR5cGUiLCAiQmFjaGVsb3JEZWdyZWUiXQ~WyJMeG5GYTBXVm8wRUluVy1QdS1fd1dRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl1d~WyJSWTg1YTZNMmEwX3VDWlFTVGZmTFdRIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMTg3MiJd~eyJhbGciOiJFUzM4NCIsInR5cCI6ImtiK2p3dCJ9.eyJub25jZSI6IkVmeTROTFJPX3ZvSkszdDIzcUNfQlEiLCJhdWQiOiJodHRwczovL3ZlcmlmaWVyLmV4YW1wbGUiLCJpYXQiOjE2OTcyODk5OTZ9.6G-1nVcrDKFzR6BdbcFHcbtassEb8NZ7ZavTYz3SJ-e4pXleXs0tNcCkUCwMI70gsuOY0AXzeDPbHjp5GKyLDVuNWgWCt3Wo2VSaCwUkyfLyvhkCsmkF9kvFhMIOhp1i

8.5 COSE Examples

These examples rely on CBOR Diagnostic Notation. Remember that all actual interchange always happens in the binary format.

Example 31: A COSE Sign 1 Protected Header for a Verifiable Credential
{                                   / Protected                     /
  1: -35,                           / Algorithm                     /
  3: application/vc+ld+json,        / Content type                  /
  4: h'177f12cb...1933d554',        / Key identifier                /
  15: {                             / CWT Claims                    /
    1: urn:example:123,             / Issuer                        /
    2: urn:example:456,             / Subject                       /
  },
}
Example 32: A COSE Sign 1 Protected Header for a Verifiable Presentation
{                                   / Protected                     /
  1: -35,                           / Algorithm                     /
  3: application/vp+ld+json,        / Content type                  /
  4: h'177f12cb...1933d554',        / Key identifier                /
  15: {                             / CWT Claims                    /
    1: urn:example:123,             / Issuer                        /
    2: urn:example:456,             / Subject                       /
  },
}
Example 33: A COSE Sign 1 with an attached payload
18(                                 / COSE Sign 1                   /
    [
      h'a4013822...3a343536',       / Protected Header              /
      {}                            / Unprotected Header            /
      h'0fbe22a0...3a009118',       / Attached payload              /
      h'09772c7f...5c4e736f'        / Signature                     /
    ]
)
Example 34: A COSE Sign 1 with a detached payload
18(                                 / COSE Sign 1                   /
    [
      h'a4013822...3a343536',       / Protected Header              /
      {}                            / Unprotected Header            /
      nil,                          / Detached payload              /
      h'09772c7f...5c4e736f'        / Signature                     /
    ]
)

The payload can be either a credential or presentation as described in Securing Mechanisms.

9. Verification Algorithms

This specification might be used with many different key discovery protocols. Therefore, discovery of verification keys is described in 4. Key Discovery, and is assumed to have succeeded prior to beginning the verification process.

As a general rule, verifiers SHOULD strive to minimize the processing of untrusted data. This includes minimizing any processing of the protected header, unprotected header, or payload as part of the key discovery procedures.

After verification has succeeded, additional validation checks SHOULD be performed as described in Section 10. Validation Algorithm

The outputs for the following algorithms are:

9.1 Algorithm for Verifying a Credential or Presentation Secured with JOSE

The inputs for this algorithm are:

Upon receipt of the verifiable credential or presentation secured as a JWT [RFC7519], the holder or verifier follows this algorithm:

  1. Follow the algorithm defined in Validating a JWT [RFC7519].
  2. If processing completes successfully:
    1. Set status to true
    2. Set mediaType to vc+ld+json or vp+json+ld
    3. Set document to the decoded JWS payload.
    4. Return
  3. If processing aborts for any reason or the JWT is rejected:
    1. Set status to false
    2. Set document to null
    3. Set mediaType to null
    4. Return

9.2 Algorithm for Verifying a Credential or Presentation Secured with SD-JWT

The inputs for this algorithm are:

Upon receipt of the verifiable credential or presentation secured with [SD-JWT], the holder or verifier follows this algorithm:

  1. Follow the algorithms defined in SD-JWT for verification of the SD-JWT.
  2. If processing completes successfully:
    1. Set status to true
    2. Set mediaType to vc+ld+json
    3. Convert the SD-JWT payload back into the JSON claim set by reversing the process in Selective Disclosure for JWTs (SD-JWT) [SD-JWT]. Set document to the JSON claim set. (For examples of the transition from JSON claim set to SD-JWT payload, please see SD-JWT examples).
    4. Return
  3. If processing aborts for any reason or the SD-JWT is rejected:
    1. Set status to false
    2. Set document to null
    3. Set mediaType to null
    4. Return

9.3 Algorithm for Verifying a Credential or Presentation Secured with COSE

The inputs for this algorithm are:

Upon receipt of the verifiable credential or presentation secured with [RFC9052], the holder or verifier follows this algorithm:

  1. Follow the algorithm defined in CBOR Object Signing and Encryption (COSE): Structures and Process [RFC9052] under the Signing and Verification Process for COSE_Sign1.
  2. If processing completes successfully:
    1. Set status to true
    2. Set mediaType to vc+ld+json or vp+ld+json
    3. Set document to the decoded COSE_Sign1 payload.
    4. Return
  3. If processing aborts for any reason:
    1. Set status to false
    2. Set document to null
    3. Set mediaType to null
    4. Return

10. Validation Algorithm

All claims expected for the typ MUST be present. All claims that are understood MUST be evaluated according the verifier's validation policies. All claims that are not understood MUST be ignored.

The verified document returned from verification MUST be a well-formed compact JSON-LD document, as described in Verifiable Credentials Data Model v2.0.

Schema extension mechanisms such as credentialSchema SHOULD be checked. If the extension mechanism type is not understood, this property MUST be ignored.

Status extension mechanisms such as credentialStatus SHOULD be checked. If the extension mechanism type is not understood, this property MUST be ignored.

Based on the validation policy of the verifier, the type of credentials, and the type of securing mechanism, additional validation checks MAY be applied. For example, dependencies between multiple credentials, ordering or timing information associated with multiple credentials, and/or multiple presentations could cause an otherwise valid credential or presentation to be considered invalid.

A. References

A.1 Normative references

[DID-CORE]
Decentralized Identifiers (DIDs) v1.0. Manu Sporny; Amy Guy; Markus Sabadello; Drummond Reed. W3C. 19 July 2022. W3C Recommendation. URL: https://www.w3.org/TR/did-core/
[IANA-STRUCTURED-SUFFIX]
Structured Syntax Suffixes. The Internet Assigned Numbers Authority. The Internet Assigned Numbers Authority. W3C Recommendation. URL: https://www.iana.org/assignments/media-type-structured-suffix/
[INFRA]
Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
[JOSE-REGISTRIES]
The JSON Object Signing and Encryption (JOSE) Registries. The Internet Assigned Numbers Authority. The Internet Assigned Numbers Authority. W3C Recommendation. URL: https://www.iana.org/assignments/jose
[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/
[MULTIPLE-SUFFIXES]
Media Types with Multiple Suffixes. Manu Sporny; Amy Guy. IETF. Internet-Draft. URL: https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC3986]
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc3986
[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/rfc/rfc6838
[RFC7159]
The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. IETF. March 2014. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7159
[RFC7515]
JSON Web Signature (JWS). M. Jones; J. Bradley; N. Sakimura. IETF. May 2015. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7515
[RFC7517]
JSON Web Key (JWK). M. Jones. IETF. May 2015. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7517
[RFC7518]
JSON Web Algorithms (JWA). M. Jones. IETF. May 2015. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7518
[RFC7519]
JSON Web Token (JWT). M. Jones; J. Bradley; N. Sakimura. IETF. May 2015. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7519
[RFC7638]
JSON Web Key (JWK) Thumbprint. M. Jones; N. Sakimura. IETF. September 2015. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7638
[RFC7800]
Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs). M. Jones; J. Bradley; H. Tschofenig. IETF. April 2016. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7800
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[RFC8392]
CBOR Web Token (CWT). M. Jones; E. Wahlstroem; S. Erdtman; H. Tschofenig. IETF. May 2018. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc8392
[RFC8747]
Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs). M. Jones; L. Seitz; G. Selander; S. Erdtman; H. Tschofenig. IETF. March 2020. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc8747
[RFC8949]
Concise Binary Object Representation (CBOR). C. Bormann; P. Hoffman. IETF. December 2020. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc8949
[RFC9052]
CBOR Object Signing and Encryption (COSE): Structures and Process. J. Schaad. IETF. August 2022. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc9052
[SD-JWT]
Selective Disclosure for JWTs (SD-JWT). Daniel Fett; Kristina Yasuda; Brian Campbell. IETF. Internet-Draft. URL: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt
[SD-JWT-VC]
SD-JWT-based Verifiable Credentials (SD-JWT VC). Oliver Terbu; Daniel Fett; Brian Campbell. IETF. Internet-Draft. URL: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-sd-jwt-vc
[URL]
URL Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://url.spec.whatwg.org/
[VC-DATA-MODEL-2.0]
Verifiable Credentials Data Model v2.0. Manu Sporny; Ted Thibodeau Jr; Ivan Herman; Michael Jones; Gabe Cohen. W3C. 13 May 2024. W3C Candidate Recommendation. URL: https://www.w3.org/TR/vc-data-model-2.0/
[VC-SPECS-DIR]
VC Specifications Directory. Manu Sporny. W3C. 1 February 2024. W3C Working Group Note. URL: https://www.w3.org/TR/vc-specs-dir/
[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/

A.2 Informative references

[RFC5785]
Defining Well-Known Uniform Resource Identifiers (URIs). M. Nottingham; E. Hammer-Lahav. IETF. April 2010. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc5785
[RFC7049]
Concise Binary Object Representation (CBOR). C. Bormann; P. Hoffman. IETF. October 2013. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7049
[WCAG21]
Web Content Accessibility Guidelines (WCAG) 2.1. Michael Cooper; Andrew Kirkpatrick; Joshue O'Connor; Alastair Campbell. W3C. 21 September 2023. W3C Recommendation. URL: https://www.w3.org/TR/WCAG21/