Securing Verifiable Credentials using JOSE and COSE

W3C Working Draft

More details about this document
This version:
https://www.w3.org/TR/2023/WD-vc-jose-cose-20230815/
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
Editors:
Orie Steele (Transmute)
Michael Jones (independent)
Michael Prorock (Mesur.io)
Feedback:
GitHub w3c/vc-jose-cose (pull requests, new issue, open issues)

Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

Abstract

This specification defines how to secure credentials and presentations conforming to the [VC-DATA-MODEL], with JSON Object Signing and Encryption (JOSE), and CBOR Object Signing and Encryption (COSE) [RFC9052]. This enables the Verifiable Credential data model [VC-DATA-MODEL]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/.

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

Publication as a Working Draft does not imply endorsement by W3C and its Members.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than 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 12 June 2023 W3C Process Document.

1. Introduction

This specification describes how to secure media types expressing Verifiable Credentials and Verifiable Presentations as described in the [VC-DATA-MODEL], using approaches described by the OAUTH, JOSE, and COSE working groups at IETF. This includes JWTs [RFC7519], JWS [RFC7515], SD-JWT [SD-JWT], and COSE [RFC9052], and provides an approach using well-defined content types [RFC6838] and structured suffixes [MULTIPLE-SUFFIXES] to distinguish the data types of documents conforming to [VC-DATA-MODEL] from the data types of secured documents conforming to [VC-DATA-MODEL], defined in this specification.

JSON Web Signatures (JWS) [RFC7515] provide a standardized mechanism for digitally signing JSON documents. It provides a means to ensure the integrity, authenticity, and non-repudiation of the information contained in a JSON document. JWS enables secure communication and trust between parties by adding a cryptographic signature to a payload. This signature is generated using a private key and can be verified using the corresponding public key. JWS enables content integrity, authentication and non repudiation, protecting data from unauthorized modifications. The versatility and wide adoption of JWS make it an essential component for verifying the authenticity and integrity of various application media types, including authentication, authorization, and secure data exchange. These properties make JWS especially well suited to securing the JSON-LD [VC-DATA-MODEL] and through this to provide a means of supporting the three party model (issuer, holder, verifier) for exchange of verifiable credentials and verifiable presentations.

JSON Web Token (JWT) [RFC7519] is a widely-used means of expressing claims, represented in JSON, to be transferred between two parties. Providing a representation of the [VC-DATA-MODEL] for JWT allows existing systems and libraries to participate in the ecosystem described in Section ecosystem overview. A JWT encodes a set of claims as a JSON object that is secured via a JSON Web Signature (JWS) [RFC7515] and/or JSON Web Encryption (JWE) [RFC7516]. For this specification, the use of JWE is out of scope.

Issue

The working group is discussing how we might comment on recent work, that does make use of encryption in OpenID for Verifiable Presentations.

CBOR Object Signing and Encryption (COSE) [RFC9052] is a specification that defines a framework for representing signed and encrypted data using (Concise Binary Object Representation) [RFC8949] data structures. COSE provides a standardized way to secure the integrity, authenticity, and confidentiality of CBOR-encoded 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 HMAC, RSA, ECDSA, or 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. Securing the VC Data Model

This section outlines how to secure documents conforming to the [VC-DATA-MODEL] using JOSE and COSE.

Documents conforming to the [VC-DATA-MODEL], and their associated media types, rely on JSON-LD, which is a flexible and 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 the [VC-DATA-MODEL] without any mappings or transformation, while at the same time supporting registered claims that are understood in the context of JOSE and COSE.

2.1 With JOSE

2.1.1 Securing JSON-LD Verifiable Credentials with JOSE

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

[rfc7515] MAY be used to secure this media type.

The typ parameter MUST be vc+ld+jwt

When present, the cty MUST be vc+ld+json

See Common JOSE Header Parameters for additional details regarding usage of typ and cty.

Example 1: Example Credential 
{
  "@context": ["https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential",
    "UniversityDegreeCredential"
  ],
  "issuer": "https://example.edu/issuers/14",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:123",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  }
}
---------------- Decoded Protected Header ----------------
{
  "alg": "ES384",
  "typ": "vc+ld+jwt",
  "iss": "https://example.edu/issuers/14",
  "iat": 1692109994
}
---------------- Decoded Protected Claimset ----------------
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": [
    "VerifiableCredential",
    "UniversityDegreeCredential"
  ],
  "issuer": "https://example.edu/issuers/14",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:123",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  }
}
---------------- Compact Encoded JSON Web Token ----------------
eyJhbGciOiJFUzM4NCIsInR5cCI6InZjK2xkK2p3dCIsImlzcyI6Imh0dHBzOi8vZXhhbXBsZS5
lZHUvaXNzdWVycy8xNCIsImlhdCI6MTY5MjEwOTk5NH0.eyJAY29udGV4dCI6WyJodHRwczovL3
d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZ
GVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vZXhhbXBsZS5lZHUvY3JlZGVudGlh
bHMvMzczMiIsInR5cGUiOlsiVmVyaWZpYWJsZUNyZWRlbnRpYWwiLCJVbml2ZXJzaXR5RGVncmV
lQ3JlZGVudGlhbCJdLCJpc3N1ZXIiOiJodHRwczovL2V4YW1wbGUuZWR1L2lzc3VlcnMvMTQiLC
Jpc3N1YW5jZURhdGUiOiIyMDEwLTAxLTAxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTdWJqZWN0I
jp7ImlkIjoiZGlkOmV4YW1wbGU6MTIzIiwiZGVncmVlIjp7InR5cGUiOiJCYWNoZWxvckRlZ3Jl
ZSIsIm5hbWUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIn19fQ.1lhGn5slDiEMmI6K
vaJQMtPO_wC6yF6REj7ANOtZ-ta63FU8_XCBNHNgRuaug45ipCbNHZkma0Dqfz0fcqPGVViZj5B
t5oU2iDdNSmE3iKxWz2MzdRaLH16VnJQEv6zc
graph LR 0("VerifiableCredential") 1{{"id"}} 2("http://example.edu/credentials/3732") 3(("type")) 4("UniversityDegreeCredential") 5("issuer") 6("https://example.edu/issuers/14") 7("issuanceDate") 8("2010-01-01T19:23:24Z") 9("credentialSubject") 10{{"id"}} 11("did:example:123") 12("degree") 13(("type")) 14("BachelorDegree") 15("name") 16("Bachelor of Science and Arts") 0 --- 1 1 --- 2 0 --- 3 3 --- 4 0 --- 5 5 --- 6 0 --- 7 7 --- 8 0 --- 9 9 --- 10 10 --- 11 9 --- 12 12 --- 13 13 --- 14 12 --- 15 15 --- 16

2.1.2 Securing JSON-LD Verifiable Presentations with JOSE

This section details how to secure verifiable presentations with the type application/vp+ld+json with JOSE.

[rfc7515] MAY be used to secure this media type.

The typ parameter MUST be vp+ld+jwt

When present, the cty parameter MUST be vp+ld+json

See Common JOSE Header Parameters for additional details regarding usage of typ and cty.

Example 2: The minimal unsecured verifiable presentation 
{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "type": ["VerifiablePresentation"]
}
---------------- Decoded Unprotected Header ----------------
{
  "alg": "none",
  "typ": "vp+ld+jwt"
}
---------------- Decoded Unprotected Claimset ----------------
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2"
  ],
  "type": [
    "VerifiablePresentation"
  ]
}
---------------- Compact Encoded JSON Web Token ----------------
eyJhbGciOiJub25lIiwidHlwIjoidnArbGQrand0In0.eyJAY29udGV4dCI6WyJodHRwczovL3d
3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiXSwidHlwZSI6WyJWZXJpZmlhYmxlUHJlc2VudG
F0aW9uIl19.
graph LR 17("VerifiablePresentation")
Example 3: The minimal secured verifiable presentation 
{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "type": ["VerifiablePresentation"]
}
---------------- Decoded Protected Header ----------------
{
  "alg": "ES384"
}
---------------- Decoded Protected Claimset ----------------
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2"
  ],
  "type": [
    "VerifiablePresentation"
  ]
}
---------------- Compact Encoded JSON Web Token ----------------
eyJhbGciOiJFUzM4NCJ9.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZG
VudGlhbHMvdjIiXSwidHlwZSI6WyJWZXJpZmlhYmxlUHJlc2VudGF0aW9uIl19.zCMAu29u0DTW
9f83hWEQodEWVuL8tLKxIbEQVn0CVFhQlcnFJpX_JmZMpjC9StmPRgILtD1DDusHeE-RK8HT4qw
ceCAp9f451hlN0EY97cfzX06wxHdvLd3pFAdO74ib
graph LR 18("VerifiablePresentation")
Example 4: A secured verifiable presentation with a holder identifier 
{
  "@context": ["https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": ["VerifiablePresentation"],
  "holder": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs"
}
---------------- Decoded Protected Header ----------------
{
  "alg": "ES384",
  "typ": "vp+ld+jwt",
  "iss": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:NzbLsXh8uDCcd-6MNwXF
4W_7noWXFZAfHkxZsRGC9Xs",
  "iat": 1692109994,
  "nonce": "n-0S6_WzA2Mj",
  "aud": "https://contoso.example"
}
---------------- Decoded Protected Claimset ----------------
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": [
    "VerifiablePresentation"
  ],
  "holder": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:NzbLsXh8uDCcd-6MN
wXF4W_7noWXFZAfHkxZsRGC9Xs"
}
---------------- Compact Encoded JSON Web Token ----------------
eyJhbGciOiJFUzM4NCIsInR5cCI6InZwK2xkK2p3dCIsImlzcyI6InVybjppZXRmOnBhcmFtczp
vYXV0aDpqd2stdGh1bWJwcmludDpzaGEtMjU2Ok56YkxzWGg4dURDY2QtNk1Od1hGNFdfN25vV1
hGWkFmSGt4WnNSR0M5WHMiLCJpYXQiOjE2OTIxMDk5OTQsIm5vbmNlIjoibi0wUzZfV3pBMk1qI
iwiYXVkIjoiaHR0cHM6Ly9jb250b3NvLmV4YW1wbGUifQ.eyJAY29udGV4dCI6WyJodHRwczovL
3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3Jl
ZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwidHlwZSI6WyJWZXJpZmlhYmxlUHJlc2VudGF0aW9uIl0
sImhvbGRlciI6InVybjppZXRmOnBhcmFtczpvYXV0aDpqd2stdGh1bWJwcmludDpzaGEtMjU2Ok
56YkxzWGg4dURDY2QtNk1Od1hGNFdfN25vV1hGWkFmSGt4WnNSR0M5WHMifQ.FTV1qGoP2uoCDw
Oz2x5XUus_gvMuBMUNN1Cg8GWSvJgTesaEXXxNd2czc1p4XBGteQbO7NEwZGMyl3dAtS6okLwL2
wBAqQyq4doEcq2uy9pWML2sbh5Y8NSlIZ4Chm1-
graph LR 19("VerifiablePresentation") 20("holder") 21("urn:ietf:params:oauth:jwk-thumbprint:sha-256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs") 19 --- 20 20 --- 21
Example 5: A secured verifiable presentation with a holder graph node 
{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "type": ["VerifiablePresentation"],
  "holder": {
    "id": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs",
    "type": "Organization",
    "name": "Contoso"
  }
}
---------------- Decoded Protected Header ----------------
{
  "alg": "ES384",
  "typ": "vp+ld+jwt",
  "iss": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:NzbLsXh8uDCcd-6MNwXF
4W_7noWXFZAfHkxZsRGC9Xs",
  "iat": 1692109994,
  "nonce": "n-0S6_WzA2Mj",
  "aud": "https://contoso.example"
}
---------------- Decoded Protected Claimset ----------------
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2"
  ],
  "type": [
    "VerifiablePresentation"
  ],
  "holder": {
    "id": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:NzbLsXh8uDCcd-6MNwX
F4W_7noWXFZAfHkxZsRGC9Xs",
    "type": "Organization",
    "name": "Contoso"
  }
}
---------------- Compact Encoded JSON Web Token ----------------
eyJhbGciOiJFUzM4NCIsInR5cCI6InZwK2xkK2p3dCIsImlzcyI6InVybjppZXRmOnBhcmFtczp
vYXV0aDpqd2stdGh1bWJwcmludDpzaGEtMjU2Ok56YkxzWGg4dURDY2QtNk1Od1hGNFdfN25vV1
hGWkFmSGt4WnNSR0M5WHMiLCJpYXQiOjE2OTIxMDk5OTQsIm5vbmNlIjoibi0wUzZfV3pBMk1qI
iwiYXVkIjoiaHR0cHM6Ly9jb250b3NvLmV4YW1wbGUifQ.eyJAY29udGV4dCI6WyJodHRwczovL
3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiXSwidHlwZSI6WyJWZXJpZmlhYmxlUHJlc2Vu
dGF0aW9uIl0sImhvbGRlciI6eyJpZCI6InVybjppZXRmOnBhcmFtczpvYXV0aDpqd2stdGh1bWJ
wcmludDpzaGEtMjU2Ok56YkxzWGg4dURDY2QtNk1Od1hGNFdfN25vV1hGWkFmSGt4WnNSR0M5WH
MiLCJ0eXBlIjoiT3JnYW5pemF0aW9uIiwibmFtZSI6IkNvbnRvc28ifX0.FkIcz5JO2nwZsUAwM
pi00j1P6dVen5ANj0_ov0XiRbc9eXqHTbFqKV0fzFZC-PxSqGABIVGRoSmfxJGPSkwgfc3n2l4i
FHiLSXVAf3pApmcGXDkZuer3DIV42I3Q9md8
graph LR 22("VerifiablePresentation") 23("holder") 24{{"id"}} 25("urn:ietf:params:oauth:jwk-thumbprint:sha-256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs") 26(("type")) 27("Organization") 28("name") 29("Contoso") 22 --- 23 23 --- 24 24 --- 25 23 --- 26 26 --- 27 23 --- 28 28 --- 29

2.2 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 MUST be identified through use of content types as outlined in this section.

2.2.1 Securing JSON-LD VCs with COSE

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

[rfc9052] MAY be used to secure this media type.

When using this approach, the type (TBD) MUST be vc+ld+json+cose

Issue

See draft-jones-cose-typ-header-parameter, regarding progress towards explicit typing for COSE.

When using this approach, the content type (3) MUST be application/vc+ld+json

See Common COSE Header Parameters for additional details.

See Concise Binary Object Representation (CBOR) Tags for additional details.

Issue 67: typ for COSE

There is no registered tag for typ in COSE.

This prevents following the guidance from the JWT BCP

3. Conformance

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

The key words MAY, MUST, MUST NOT, and RECOMMENDED 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.

3.1 Key Discovery

Issue

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

Issue 117: how is `kid` to be `useful to distinguish the specific key used`?

Originally posted by @TallTed in #111 (comment)

line 377 says (and another line says the same) --

If <code>kid</code> is also present, it is expected to be useful to distinguish the specific key used.

-- in response to which I ask --

how is kid to be useful to distinguish the specific key used? This cries out for an example, or a fair amount of additional prose.

Issue 106: Explain relationship between controller documents and JOSE headers
          Just read that section, and I have to say that it's not intuitive at all. I think it would be worth either: adding an example that refers to this controller document, pointing to the spec you mentioned, or explicitly stating the relationship between controller docs and  `iss` & `kid`.

Originally posted by @andresuribe87 in #104 (comment)

Issue 31: About the optionality of the "kid" field in JWT-formatted VCs/VPs discuss

https://www.w3.org/TR/vc-data-model/#jwt-encoding shows:

kid MAY be used if there are multiple keys associated with the issuer of the JWT. The key discovery is out of the scope of this specification. For example, the kid can refer to a key in a DID document, or can be the identifier of a key inside a JWKS.

I'd like some clarification on the optionality of the "kid" field. My guess is that VCs/VPs are trying to be generic regarding issuers/holders, allowing for URIs, which precludes the possibility of giving any more details about how the "kid" field should be used. Is that right?

I'm coming from a DID-centric ecosystem, and in that scenario it seems that there's no reason not to set the "kid" field on a JWT-formatted VC/VP to the DID fragment URL of the specific key used to sign. From w3c/vc-data-model#914 I understand that it would still be necessary to tie the "kid" to the "iss" field, but that seems fine.

As far as I can tell, if the "kid" field is missing, and assuming we're working with DIDs here, the process to resolve the signing key has to be:

  • Identify the VC issuer / holder -- the "iss" field of the JWT. This should be a DID. (Question: Could this validly include query params such as versionTime?)
  • Resolve the DID document for that DID.
  • For each key with purpose "authentication", attempt to verify the VC/VP's signature using that key.
  • If one of the keys verifies the signature, accept the VP/VC's signature as valid. Otherwise reject it as invalid.

To me, this seems sloppy, involving unnecessary complexity and computation, and making detecting errors in implementations harder. It also wouldn't scale if for whatever reason a DID had very many keys (inefficient at best, possible DoS at worst). Maybe I'm missing something here. Can anyone comment on this? Thanks.

Issue 30: Accept or Dismiss the guidance provided by DIF on `kid` / `iss` discuss

See https://github.com/decentralized-identity/did-jose-extensions/blob/master/options.md

^ this guidance is ancient, I believe we can do better.

cc @tplooker @selfissued @Sakurann @dwaite

Issue 15: Describe why core data model members are translated to JWT claims pending-close

Can we add an explanation why do these members need to be translated to the equivalents of the JWT claims?
iss, nbf, all of them are optional in RFC 7519 itself. They only become required when the JWT is used for a specific purpose, and the only place I can think of right now is an ID Token.

See: #11 (comment)

Issue 117: how is `kid` to be `useful to distinguish the specific key used`?

Originally posted by @TallTed in #111 (comment)

line 377 says (and another line says the same) --

If <code>kid</code> is also present, it is expected to be useful to distinguish the specific key used.

-- in response to which I ask --

how is kid to be useful to distinguish the specific key used? This cries out for an example, or a fair amount of additional prose.

Issue 117: how is `kid` to be `useful to distinguish the specific key used`?

Originally posted by @TallTed in #111 (comment)

line 377 says (and another line says the same) --

If <code>kid</code> is also present, it is expected to be useful to distinguish the specific key used.

-- in response to which I ask --

how is kid to be useful to distinguish the specific key used? This cries out for an example, or a fair amount of additional prose.

In order 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.

3.2 Registered Claim Names

When found in the Protected Header, or the Protected Claimset, members present in IANA Assignments for JSON Web Token (JWT) and IANA Assignments for JSON Object Signing and Encryption (JOSE) are to be interpreted according to the associated specifications referenced by IANA.

Registered claims that are present in either the Protected Header or the Claimset can be used to help verifiers discover verification keys.

3.2.1 kid

If kid is present in the Protected Header, a verifier can use this parameter to obtain a JSON Web Key to use in the verification process.

3.2.2 iss

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

If kid is also present in the Protected Header, it is expected to be useful to distinguish the specific key used.

Issue 31: About the optionality of the "kid" field in JWT-formatted VCs/VPs discuss

There are a few issues related to clarification of optionality and behavior of registered claims.

3.2.3 cnf

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

If kid is also present in the Protected Header, it is expected to be useful to distinguish the specific key used.

3.3 Well Known URIs

Issue

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.

3.3.1 OpenID Connect

OpenID Connect uses Well-Known Uniform Resource Identifiers (URIs) to enable issuer key discovery.

  1. The verifier (or relying party) decodes the JWT claimset, and obtains the iss claim.

  2. The iss value is converted to the well-known OpenID Connect Configuration Endpoint URL by applying the following URI template:

    Example 6 
    https://{iss}/.well-known/openid-configuration

  3. The OIDC Configuration Endpoint URL is dereferenced to a JSON document which contains issuer configuration details, one of which is the jwks_uri. This URL might also be well-known, for example:

    Example 7 
    https://{iss}/.well-known/jwks

  4. The OIDC jwks_uri is dereferenced to a JSON Web Key Set.

    The content type of the key set could be application/jwk-set+json or application/json.

    Here is an example of a key set used by an issuer:

    Example 8 
    {
  "keys": [
    {
      "alg": "RS256",
      "kty": "RSA",
      "use": "sig",
      "n": "wW9TkSbcn5FV3iUJ-812sqTvwTGCFrDm6vD2U-g23gn6rrBdFZQbf2bgEnSkolph6CanOYTQ1lKVhKjHLd6Q4MDVGidbVBhESxib2YIzJVUS-0oQgizkBEJxyHI4Zl3xX_sdA_yegLUi-Ykt_gaMPSw_vpxe-pBxu-jd14i-jDfwoPJUdF8ZJGS9orCPRiHCYLDgOscC9XibH9rUbTvG8q4bAPx9Ox6malx4OLvU3pXVjew6LG3iBi2YhpCWe6voMvZJYXqC1n5Mk_KOdGcCFtDgu3I56SGSfsF7-tI7qG1ZO8RMuzqH0LkJVirujYzXrnMZ7WgbMPXmHU8i4z04zw",
      "e": "AQAB",
      "kid": "NTBGNTJEMDc3RUE3RUVEOTM4NDcyOEFDNzEyOTY5NDNGOUQ4OEU5OA",
      "x5t": "NTBGNTJEMDc3RUE3RUVEOTM4NDcyOEFDNzEyOTY5NDNGOUQ4OEU5OA",
      "x5c": [
        "MIIDCzCCAfOgAwIBAgIJANPng0XRWwsdMA0GCSqGSIb3DQEBBQUAMBwxGjAYBgNVBAMMEWNvbnRvc28uYXV0aDAuY29tMB4XDTE0MDcxMTE2NTQyN1oXDTI4MDMxOTE2NTQyN1owHDEaMBgGA1UEAwwRY29udG9zby5hdXRoMC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBb1ORJtyfkVXeJQn7zXaypO/BMYIWsObq8PZT6DbeCfqusF0VlBt/ZuASdKSiWmHoJqc5hNDWUpWEqMct3pDgwNUaJ1tUGERLGJvZgjMlVRL7ShCCLOQEQnHIcjhmXfFf+x0D/J6AtSL5iS3+Bow9LD++nF76kHG76N3XiL6MN/Cg8lR0XxkkZL2isI9GIcJgsOA6xwL1eJsf2tRtO8byrhsA/H07HqZqXHg4u9TeldWN7DosbeIGLZiGkJZ7q+gy9klheoLWfkyT8o50ZwIW0OC7cjnpIZJ+wXv60juobVk7xEy7OofQuQlWKu6NjNeucxntaBsw9eYdTyLjPTjPAgMBAAGjUDBOMB0GA1UdDgQWBBTLarHdkNa5CzPyiKJU51t8JWn9WTAfBgNVHSMEGDAWgBTLarHdkNa5CzPyiKJU51t8JWn9WTAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQA2FOjm+Bpbqk59rQBC0X6ops1wBcXH8clnXfG1G9qeRwLEwSef5HPz4TTh1f2lcf4Pcq2vF0HbVNJFnLVV+PjR9ACkto+v1n84i/U4BBezZyYuX2ZpEbv7hV/PWxg8tcVrtyPaj60UaA/pUA86CfYy+LckY4NRKmD7ZrcCzjxW2hFGNanfm2FEryxXA3RMNf6IiW7tbJ9ZGTEfA/DhVnZgh/e82KVX7EZnkB4MjCQrwj9QsWSMBtBiYp0/vRi9cxDFHlUwnYAUeZdHWTW+Rp2JX7Qwf0YycxgyjkGAUEZc4WpdNiQlwYf5G5epfOtHGiwiJS+u/nSYvqCFt57+g3R+"
      ]
    },
    {
      "alg": "RS256",
      "kty": "RSA",
      "use": "sig",
      "n": "ylgVZbNR4nlsU_AbU8Zd7ZhVfmYuwq-RB1_YQWHY362pAed-qgSXV1QmKwCukQ2WDsPHWgpPuEf3O_acmJcCiSxhctpBr5WKkji5o50YX2FqC3xymGkYW5NilvFznKaKU45ulBVByrcb3Vt8BqqBAhaD4YywZZKo7mMudcq_M__f0_tB4fHsHHe7ehWobWtzAW7_NRP0_FjB4Kw4PiqJnChPvfbuxTCEUcIYrshRwD6GF4D_oLdeR44dwx4wtEgvPOtkQ5XIGrhQC_sgWcb2jh7YXauVUjuPezP-VkK7Wm9mZRe758q43SWxwT3afo5BLa3_YLWazqcpWRXn9QEDWw",
      "e": "AQAB",
      "kid": "aMIKy_brQk3nLd0PKd9ln",
      "x5t": "-xcTyx47q3ddycG7LtE6QCcETbs",
      "x5c": [
        "MIIC/TCCAeWgAwIBAgIJH62yWyX7VxxQMA0GCSqGSIb3DQEBCwUAMBwxGjAYBgNVBAMTEWNvbnRvc28uYXV0aDAuY29tMB4XDTIwMDMxMTE5Mjk0N1oXDTMzMTExODE5Mjk0N1owHDEaMBgGA1UEAxMRY29udG9zby5hdXRoMC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKWBVls1HieWxT8BtTxl3tmFV+Zi7Cr5EHX9hBYdjfrakB536qBJdXVCYrAK6RDZYOw8daCk+4R/c79pyYlwKJLGFy2kGvlYqSOLmjnRhfYWoLfHKYaRhbk2KW8XOcpopTjm6UFUHKtxvdW3wGqoECFoPhjLBlkqjuYy51yr8z/9/T+0Hh8ewcd7t6Fahta3MBbv81E/T8WMHgrDg+KomcKE+99u7FMIRRwhiuyFHAPoYXgP+gt15Hjh3DHjC0SC8862RDlcgauFAL+yBZxvaOHthdq5VSO497M/5WQrtab2ZlF7vnyrjdJbHBPdp+jkEtrf9gtZrOpylZFef1AQNbAgMBAAGjQjBAMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFPVdE4SPvuhlODV0GOcPE4QZ7xNuMA4GA1UdDwEB/wQEAwIChDANBgkqhkiG9w0BAQsFAAOCAQEAu2nhfiJk/Sp49LEsR1bliuVMP9nycbSz0zdp2ToAy0DZffTd0FKk/wyFtmbb0UFTD2aOg/WZJLDc+3dYjWQ15SSLDRh6LV45OHU8Dkrc2qLjiRdoh2RI+iQFakDn2OgPNgquL+3EEIpbBDA/uVoOYCbkqJNaNM/egN/s2vZ6Iq7O+BprWX/eM25xw8PMi+MU4K2sJpkcDRwoK9Wy8eeSSRIGYnpKO42g/3QI9+BRa5uD+9shG6n7xgzAPGeldUXajCThomwO8vInp6VqY8k3IeLEYoboJj5KMfJgOWUkmaoh6ZBJHnCogvSXI35jbxCxmHAbK+KdTka/Yg2MadFZdA=="
      ]
    }
  ]
}

  5. The verifier (or relying party) uses kid from the protected header of the JWT to identify the public key, controlled by the issuer, and uses it to verify the token.

    The verifier (or relying party) verifies the signature on the JWT. After verification, the claims the issuer has made about the subject can be reviewed or processed, because the integrity of the claims has been protected by a digital signature verification.

4. JSON Web Token Header Parameters

The normative statements in Registered Header Parameter Names apply to securing credentials and presentations.

The normative statements in JOSE Header apply to securing credentials and presentations.

The data model for the protected header is JSON (application/json), not JSON-LD (application/ld+json).

The normative statements in Replicating Claims as Header Parameters apply to securing claims about a credential subject.

When replicating claims from the claimset to the header, it is RECOMMENDED to use [RFC7519], IANA Assignments for Header Parameters, and IANA Assignments for JSON Web Token (JWT) to identify any reserved claims that might be confused with members of the [[VC-DATA-MODEL]. This includes but is not limited to: iss, kid, alg, iat, exp and cnf.

The registered claim names vc and vp MUST NOT be present as header parameters.

When present, members of the header are to be interpreted and processed according to IANA Assignments for JSON Web Token (JWT) and IANA Assignments for JSON Object Signing and Encryption (JOSE).

Additional members may be present, if they are not understood, they MUST be ignored.

5. Securing Verifiable Credentials

The Verifiable Credentials Data Model v1.1 describes the approach taken by JSON Web Tokens to secure claimsets as applying an external proof.

The normative statements in Securing Verifiable Credentials apply to securing application/vc+ld+json and application/vp+ld+json as application/vc+ld+jwt and application/vp+ld+jwt.

For clarity, these requirements are repeated here:

The type VerifiableCredential and VerifiablePresentation are RDF Classes.

The presence of the word "Verifiable" does not convey a cryptographic verification capability exists.

The presence of the JSON proof member does not convey a cryptographic verification capability exists.

The presence of the JSON proof member is optional in both VerifiableCredential and VerifiablePresentation.

The presence of the JSON proof member is optional in both application/vc+ld+json and application/vp+ld+json.

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 the [VC-DATA-MODEL] with JSON Web Tokens.

When content types from the [VC-DATA-MODEL] are secured using JSON Web Tokens, the header parameter "alg": "none", MUST be used to communicate that a claimset (a Verifiable Credential or a Verifiable Presentation) has no integrity protection.

When a JSON Web Token claimset (a Verifiable Credential or a Verifiable Presentation) contains proof, and the JSON Web Token header contains "alg": "none", the claimset MUST be considered to have no integrity protection.

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

Issuers, Holders and Verifiers MUST ignore all claimsets that have no integrity protection.

6. IANA Considerations

6.1 application/vc+ld+jwt

This specification registers the application/vc+ld+json+jwt Media Type for identifying a Verifiable Credential that has been secured using a JWT.

Type name: application
Subtype name: vc+ld+jwt
Required parameters: None
Encoding considerations: application/vc+ld+jwt values are encoded as a series of base64url encoded values (some of which may be the empty string) each separated from the next by a single period ('.') character.
Security considerations:

As defined in this specification. See also the security considerations in [RFC7519].
Contact: W3C Verifiable Credentials Working Group public-vc-wg@w3.org

6.2 application/vp+ld+jwt

This specification registers the application/vp+ld+json+jwt Media Type for identifying a Verifiable Presentation that has been secured using a JWT.

Type name: application
Subtype name: vp+ld+jwt
Required parameters: None
Encoding considerations: application/vp+ld+jwt values are encoded as a series of base64url encoded values (some of which may be the empty string) each separated from the next by a single period ('.') character.
Security considerations:

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

Be advised, per the [VC-DATA-MODEL], verifiable presentations are not required to be secured.

This "typ" value might be paired with "alg: none", in headers.

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

6.3 application/vc+ld+sd-jwt

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

Type name: application
Subtype name: vc+ld+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

7. JSON Web Token Claims

This section retains deprecated registered claim names that were previously submitted to the Internet Engineering Steering Group (IESG) for review, approval, and registration with IANA in the "JSON Web Token Claims Registry".

Issue 119: Deprecate `vc` & `vp` ?

These are registered claims at:

As it says, the change controller is IESG, but it references v1.0 of the data model, specifically:

In v2, we removed these from the core data model, and we removed them from this specification.

Should we tell the IESG to update the registry in any way?

7.1 vc

Claim Name: "vc"
Claim Description: Verifiable Credential
Change Controller: W3C
Specification Document(s): Section 6.3.1.2: JSON Web Token Extensions of Verifiable Credentials Data Model 1.0

7.2 vp

Claim Name: "vp"
Claim Description: Verifiable Presentation
Change Controller: W3C
Specification Document(s): Section 6.3.1.2: JSON Web Token Extensions of Verifiable Credentials Data Model 1.0

8. Other Considerations

8.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 the [VC-DATA-MODEL].

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], 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 VC-JWT.

8.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 JWTs.

When implementing VC-JWTs, 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.

8.3 Accessibility

This section is non-normative.

When implementing the VC-JWT 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 the [VC-DATA-MODEL].

8.4 Internationalization

This section is non-normative.

Implementers should take into account several internationalization considerations when publishing data described in this specification. Disregarding internationalization hampers the production and consumption of data across diverse languages and societies, thereby restricting the applicability and significantly reducing the value of the specification as a standard.

Implementers are advised to note and abide by all internationalization considerations called out in the [VC-DATA-MODEL], see also i18n, URL Standard

9. Appendix

This section is non-normative.

9.1 Controllers

Example 9: A verifiable credential controller document 
{
  "@context": ["https://www.w3.org/ns/did/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-authenticaton",
    "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-authenticaton"],
  "assertionMethod": ["#credential-issuance"],
  "keyAgreement": ["#key-agreement"]
}

9.2 Credentials

Example 10: A revocable credential withmultiple subjects 
{
  "@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"
  }]
}
---------------- Decoded Protected Header ----------------
{
  "alg": "ES384",
  "typ": "vc+ld+jwt",
  "iss": "https://contoso.example",
  "iat": 1692109994
}
---------------- Decoded Protected Claimset ----------------
{
  "@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"
    }
  ]
}
---------------- Compact Encoded JSON Web Token ----------------
eyJhbGciOiJFUzM4NCIsInR5cCI6InZjK2xkK2p3dCIsImlzcyI6Imh0dHBzOi8vY29udG9zby5
leGFtcGxlIiwiaWF0IjoxNjkyMTA5OTk0fQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5
vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbH
MvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwczovL2NvbnRvc28uZXhhbXBsZS9jcmVkZW50aWFsc
y8yMzg5NDY3MjM5NCIsInR5cGUiOlsiVmVyaWZpYWJsZUNyZWRlbnRpYWwiLCJLOVVuaXRDcmVk
ZW50aWFsIl0sImlzc3VlciI6eyJpZCI6Imh0dHBzOi8vY29udG9zby5leGFtcGxlIn0sInZhbGl
kRnJvbSI6IjIwMTUtMDQtMTZUMDU6MTE6MzIuNDMyWiIsImNyZWRlbnRpYWxTdGF0dXMiOnsiaW
QiOiJodHRwczovL2NvbnRvc28uZXhhbXBsZS9jcmVkZW50aWFscy9zdGF0dXMvNCMyNzM3NjIiL
CJ0eXBlIjoiU3RhdHVzTGlzdDIwMjFFbnRyeSIsInN0YXR1c1B1cnBvc2UiOiJyZXZvY2F0aW9u
Iiwic3RhdHVzTGlzdEluZGV4IjoiMjczNzYyIiwic3RhdHVzTGlzdENyZWRlbnRpYWwiOiJodHR
wczovL2NvbnRvc28uZXhhbXBsZS9jcmVkZW50aWFscy9zdGF0dXMvNCJ9LCJjcmVkZW50aWFsU3
ViamVjdCI6W3siaWQiOiJkaWQ6ZXhhbXBsZToxMzEyMzg3NjQxIiwidHlwZSI6IlBlcnNvbiJ9L
HsiaWQiOiJkaWQ6ZXhhbXBsZTo2Mzg4ODIzMSIsInR5cGUiOiJEb2cifV19.lREiEjWhIXzab4Q
QNf-9hf5e5XELHg9yf6xEGvNqkWSc0IkPB-6fiEc5_337N3A1JxNJDnTYy-fCwYFK6njNZ-sX3O
5GdtHqOyT2iP6dTC01uG4XXTIERUeM6ALHCBPP
graph LR 30("VerifiableCredential") 31{{"id"}} 32("https://contoso.example/credentials/23894672394") 33(("type")) 34("K9UnitCredential") 35("issuer") 36{{"id"}} 37("https://contoso.example") 38("validFrom") 39("2015-04-16T05:11:32.432Z") 40("credentialStatus") 41{{"id"}} 42("https://contoso.example/credentials/status/4#273762") 43(("type")) 44("StatusList2021Entry") 45("statusPurpose") 46("revocation") 47("statusListIndex") 48("273762") 49("statusListCredential") 50("https://contoso.example/credentials/status/4") 51("credentialSubject") 52{{"id"}} 53("did:example:1312387641") 54(("type")) 55("Person") 56("credentialSubject") 57{{"id"}} 58("did:example:63888231") 59(("type")) 60("Dog") 30 --- 31 31 --- 32 30 --- 33 33 --- 34 30 --- 35 35 --- 36 36 --- 37 30 --- 38 38 --- 39 30 --- 40 40 --- 41 41 --- 42 40 --- 43 43 --- 44 40 --- 45 45 --- 46 40 --- 47 47 --- 48 40 --- 49 49 --- 50 30 --- 51 51 --- 52 52 --- 53 51 --- 54 54 --- 55 30 --- 56 56 --- 57 57 --- 58 56 --- 59 59 --- 60
Example 11: A credential with a schema 
{
  "@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"
  }
}
---------------- Decoded Protected Header ----------------
{
  "alg": "ES384",
  "typ": "vc+ld+jwt",
  "iss": "did:web:contoso.example",
  "iat": 1692109994
}
---------------- Decoded Protected Claimset ----------------
{
  "@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"
  }
}
---------------- Compact Encoded JSON Web Token ----------------
eyJhbGciOiJFUzM4NCIsInR5cCI6InZjK2xkK2p3dCIsImlzcyI6ImRpZDp3ZWI6Y29udG9zby5
leGFtcGxlIiwiaWF0IjoxNjkyMTA5OTk0fQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5
vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbH
MvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwczovL2NvbnRvc28uZXhhbXBsZS9jcmVkZW50aWFsc
y8zNTMyNzI1NSIsInR5cGUiOlsiVmVyaWZpYWJsZUNyZWRlbnRpYWwiLCJLWUNFeGFtcGxlIl0s
Imlzc3VlciI6ImRpZDp3ZWI6Y29udG9zby5leGFtcGxlIiwidmFsaWRGcm9tIjoiMjAxOS0wNS0
yNVQwMzoxMDoxNi45OTJaIiwidmFsaWRVbnRpbCI6IjIwMjctMDUtMjVUMDM6MTA6MTYuOTkyWi
IsImNyZWRlbnRpYWxTY2hlbWEiOnsiaWQiOiJodHRwczovL2NvbnRvc28uZXhhbXBsZS9iYWZ5Y
mVpZ2R5ci4uLmxxYWJmM29jbGd0cXk1NWZiemRpIiwidHlwZSI6Ikpzb25TY2hlbWEifSwiY3Jl
ZGVudGlhbFN1YmplY3QiOnsiaWQiOiJkaWQ6ZXhhbXBsZToxMjMxNTg4IiwidHlwZSI6IlBlcnN
vbiJ9fQ.dLJGBcilb5f2mmRu-VUPmmqoEdl1fdO9BT0MCuzHm3BXbmcbaE43RltIFkxSr5TOh8z
66pfU7wQ_Xiwg_ISFPzni53O1b7MvG37ToYCnN45CbxKiHGqHM3RwgOpmF8Pm
graph LR 61("VerifiableCredential") 62{{"id"}} 63("https://contoso.example/credentials/35327255") 64(("type")) 65("KYCExample") 66("issuer") 67("did:web:contoso.example") 68("validFrom") 69("2019-05-25T03:10:16.992Z") 70("validUntil") 71("2027-05-25T03:10:16.992Z") 72("credentialSchema") 73{{"id"}} 74("https://contoso.example/bafybeigdyr...lqabf3oclgtqy55fbzdi") 75(("type")) 76("JsonSchema") 77("credentialSubject") 78{{"id"}} 79("did:example:1231588") 80(("type")) 81("Person") 61 --- 62 62 --- 63 61 --- 64 64 --- 65 61 --- 66 66 --- 67 61 --- 68 68 --- 69 61 --- 70 70 --- 71 61 --- 72 72 --- 73 73 --- 74 72 --- 75 75 --- 76 61 --- 77 77 --- 78 78 --- 79 77 --- 80 80 --- 81

9.3 Presentations

Example 12: Credential 
{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "type": ["VerifiablePresentation"],
  "holder": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:_Fpfe27AuGmEljZE9s2lw2UH-qrZLRFNrWbJrWIe4SI",
  "verifiableCredential": [{
      "@context": [
        "https://www.w3.org/ns/credentials/v2"
      ],
      "type": [
        "VerifiableCredential"
      ],
      "issuer": "https://issuer.example/issuers/68",
      "validFrom": "2023-06-07T21:14:14.148Z",
      "credentialSubject": {
        "id": "https://subject.vendor.example"
      }
    },
    "https://vendor.example/credentials/42", "did:example:123",
    "urn:uuid:01ec9426-c175-4e39-a006-d30050e28214",
    "urn:ietf:params:oauth:jwk-thumbprint:sha-256:_Fpfe27AuGmEljZE9s2lw2UH-qrZLRFNrWbJrWIe4SI",
    "data:application/vc+ld+json;base64,eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiXSwidHlwZSI6WyJWZXJpZmlhYmxlQ3JlZGVudGlhbCJdLCJpc3N1ZXIiOiJkaWQ6andrOmV5SnJhV1FpT2lKMWNtNDZhV1YwWmpwd1lYSmhiWE02YjJGMWRHZzZhbmRyTFhSb2RXMWljSEpwYm5RNmMyaGhMVEkxTmpwdlFtUm1kbVpET1hoNk1GOUJVWFpSTjNZMU1YbERXbDl6ZUdwNU56VkNUSEpJZWsxT1Jqa3lPV1U0SWl3aWEzUjVJam9pVDB0UUlpd2lZM0oySWpvaVJXUXlOVFV4T1NJc0ltRnNaeUk2SWtWa1JGTkJJaXdpZUNJNklqTmljbU5zYjBJNGFEUk5XbFZJYms5UVVHbGtTbXd0U2pkdVVsRkpXSFJUYUZwM1oyNW1jbHAxVDI4aWZRIiwidmFsaWRGcm9tIjoiMjAyMy0wNi0wN1QyMToxNDoxNC4xNDhaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiaWQiOiJodHRwczovL3N1YmplY3QudmVuZG9yLmV4YW1wbGUifX0=",
    "data:application/vc+ld+jwt;base64,ZXlKaGJHY2lPaUpGWkVSVFFTSXNJbWx6Y3lJNkltUnBaRHBxZDJzNlpYbEtjbUZYVVdsUGFVb3hZMjAwTm1GWFZqQmFhbkIzV1ZoS2FHSllUVFppTWtZeFpFZG5ObUZ1WkhKTVdGSnZaRmN4YVdOSVNuQmlibEUyWXpKb2FFeFVTVEZPYW5CMlVXMVNiV1J0V2tSUFdHZzJUVVk1UWxWWVdsSk9NMWt4VFZoc1JGZHNPWHBsUjNBMVRucFdRMVJJU2tsbGF6RlBVbXByZVU5WFZUUkphWGRwWVROU05VbHFiMmxVTUhSUlNXbDNhVmt6U2pKSmFtOXBVbGRSZVU1VVZYaFBVMGx6U1cxR2MxcDVTVFpKYTFaclVrWk9Ra2xwZDJsbFEwazJTV3BPYVdOdFRuTmlNRWswWVVSU1RsZHNWa2xpYXpsUlZVZHNhMU50ZDNSVGFtUjFWV3hHU2xkSVVsUmhSbkF6V2pJMWJXTnNjREZVTWpocFpsRWlMQ0pyYVdRaU9pSWpNQ0lzSW5SNWNDSTZJblpqSzJ4a0sycDNkQ0lzSW1saGRDSTZNVFk0TmpJMU1UVTNOSDAuZXlKQVkyOXVkR1Y0ZENJNld5Sm9kSFJ3Y3pvdkwzZDNkeTUzTXk1dmNtY3Zibk12WTNKbFpHVnVkR2xoYkhNdmRqSWlYU3dpZEhsd1pTSTZXeUpXWlhKcFptbGhZbXhsUTNKbFpHVnVkR2xoYkNKZExDSnBjM04xWlhJaU9pSmthV1E2YW5kck9tVjVTbkpoVjFGcFQybEtNV050TkRaaFYxWXdXbXB3ZDFsWVNtaGlXRTAyWWpKR01XUkhaelpoYm1SeVRGaFNiMlJYTVdsalNFcHdZbTVSTm1NeWFHaE1WRWt4VG1wd2RsRnRVbTFrYlZwRVQxaG9OazFHT1VKVldGcFNUak5aTVUxWWJFUlhiRGw2WlVkd05VNTZWa05VU0VwSlpXc3hUMUpxYTNsUFYxVTBTV2wzYVdFelVqVkphbTlwVkRCMFVVbHBkMmxaTTBveVNXcHZhVkpYVVhsT1ZGVjRUMU5KYzBsdFJuTmFlVWsyU1d0V2ExSkdUa0pKYVhkcFpVTkpOa2xxVG1samJVNXpZakJKTkdGRVVrNVhiRlpKWW1zNVVWVkhiR3RUYlhkMFUycGtkVlZzUmtwWFNGSlVZVVp3TTFveU5XMWpiSEF4VkRJNGFXWlJJaXdpZG1Gc2FXUkdjbTl0SWpvaU1qQXlNeTB3Tmkwd04xUXlNVG94TkRveE5DNHhORGhhSWl3aVkzSmxaR1Z1ZEdsaGJGTjFZbXBsWTNRaU9uc2lhV1FpT2lKb2RIUndjem92TDNOMVltcGxZM1F1ZG1WdVpHOXlMbVY0WVcxd2JHVWlmWDAubmczZlpDQXJyNUYwb1hOS1J1UlFNUXYtdnh4YlozUWJKVkJpcU1QUlVnSEFiSDVkMXptYjhLeUNkNnlVS3IxbmlsZmZiZ2pGUmRpRjFsWUdNRGNhQ0E="
  ]
}

9.4 Data URIs

Example 13: JSON-LD Credential 
data:application/vc+ld+json;base64,eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiXSwidHlwZSI6WyJWZXJpZmlhYmxlQ3JlZGVudGlhbCJdLCJpc3N1ZXIiOiJkaWQ6andrOmV5SnJhV1FpT2lKMWNtNDZhV1YwWmpwd1lYSmhiWE02YjJGMWRHZzZhbmRyTFhSb2RXMWljSEpwYm5RNmMyaGhMVEkxTmpwdlFtUm1kbVpET1hoNk1GOUJVWFpSTjNZMU1YbERXbDl6ZUdwNU56VkNUSEpJZWsxT1Jqa3lPV1U0SWl3aWEzUjVJam9pVDB0UUlpd2lZM0oySWpvaVJXUXlOVFV4T1NJc0ltRnNaeUk2SWtWa1JGTkJJaXdpZUNJNklqTmljbU5zYjBJNGFEUk5XbFZJYms5UVVHbGtTbXd0U2pkdVVsRkpXSFJUYUZwM1oyNW1jbHAxVDI4aWZRIiwidmFsaWRGcm9tIjoiMjAyMy0wNi0wN1QyMToxNDoxNC4xNDhaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiaWQiOiJodHRwczovL3N1YmplY3QudmVuZG9yLmV4YW1wbGUifX0=
Example 14: JWT Credential 
data:application/vc+ld+jwt;base64,ZXlKaGJHY2lPaUpGWkVSVFFTSXNJbWx6Y3lJNkltUnBaRHBxZDJzNlpYbEtjbUZYVVdsUGFVb3hZMjAwTm1GWFZqQmFhbkIzV1ZoS2FHSllUVFppTWtZeFpFZG5ObUZ1WkhKTVdGSnZaRmN4YVdOSVNuQmlibEUyWXpKb2FFeFVTVEZPYW5CMlVXMVNiV1J0V2tSUFdHZzJUVVk1UWxWWVdsSk9NMWt4VFZoc1JGZHNPWHBsUjNBMVRucFdRMVJJU2tsbGF6RlBVbXByZVU5WFZUUkphWGRwWVROU05VbHFiMmxVTUhSUlNXbDNhVmt6U2pKSmFtOXBVbGRSZVU1VVZYaFBVMGx6U1cxR2MxcDVTVFpKYTFaclVrWk9Ra2xwZDJsbFEwazJTV3BPYVdOdFRuTmlNRWswWVVSU1RsZHNWa2xpYXpsUlZVZHNhMU50ZDNSVGFtUjFWV3hHU2xkSVVsUmhSbkF6V2pJMWJXTnNjREZVTWpocFpsRWlMQ0pyYVdRaU9pSWpNQ0lzSW5SNWNDSTZJblpqSzJ4a0sycDNkQ0lzSW1saGRDSTZNVFk0TmpJMU1UVTNOSDAuZXlKQVkyOXVkR1Y0ZENJNld5Sm9kSFJ3Y3pvdkwzZDNkeTUzTXk1dmNtY3Zibk12WTNKbFpHVnVkR2xoYkhNdmRqSWlYU3dpZEhsd1pTSTZXeUpXWlhKcFptbGhZbXhsUTNKbFpHVnVkR2xoYkNKZExDSnBjM04xWlhJaU9pSmthV1E2YW5kck9tVjVTbkpoVjFGcFQybEtNV050TkRaaFYxWXdXbXB3ZDFsWVNtaGlXRTAyWWpKR01XUkhaelpoYm1SeVRGaFNiMlJYTVdsalNFcHdZbTVSTm1NeWFHaE1WRWt4VG1wd2RsRnRVbTFrYlZwRVQxaG9OazFHT1VKVldGcFNUak5aTVUxWWJFUlhiRGw2WlVkd05VNTZWa05VU0VwSlpXc3hUMUpxYTNsUFYxVTBTV2wzYVdFelVqVkphbTlwVkRCMFVVbHBkMmxaTTBveVNXcHZhVkpYVVhsT1ZGVjRUMU5KYzBsdFJuTmFlVWsyU1d0V2ExSkdUa0pKYVhkcFpVTkpOa2xxVG1samJVNXpZakJKTkdGRVVrNVhiRlpKWW1zNVVWVkhiR3RUYlhkMFUycGtkVlZzUmtwWFNGSlVZVVp3TTFveU5XMWpiSEF4VkRJNGFXWlJJaXdpZG1Gc2FXUkdjbTl0SWpvaU1qQXlNeTB3Tmkwd04xUXlNVG94TkRveE5DNHhORGhhSWl3aVkzSmxaR1Z1ZEdsaGJGTjFZbXBsWTNRaU9uc2lhV1FpT2lKb2RIUndjem92TDNOMVltcGxZM1F1ZG1WdVpHOXlMbVY0WVcxd2JHVWlmWDAubmczZlpDQXJyNUYwb1hOS1J1UlFNUXYtdnh4YlozUWJKVkJpcU1QUlVnSEFiSDVkMXptYjhLeUNkNnlVS3IxbmlsZmZiZ2pGUmRpRjFsWUdNRGNhQ0E=
Example 15: JSON-LD Verifiable Presentation 
data:application/vp+ld+json;base64,eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiXSwidHlwZSI6WyJWZXJpZmlhYmxlQ3JlZGVudGlhbCJdLCJpc3N1ZXIiOiJkaWQ6andrOmV5SnJhV1FpT2lKMWNtNDZhV1YwWmpwd1lYSmhiWE02YjJGMWRHZzZhbmRyTFhSb2RXMWljSEpwYm5RNmMyaGhMVEkxTmpwdlFtUm1kbVpET1hoNk1GOUJVWFpSTjNZMU1YbERXbDl6ZUdwNU56VkNUSEpJZWsxT1Jqa3lPV1U0SWl3aWEzUjVJam9pVDB0UUlpd2lZM0oySWpvaVJXUXlOVFV4T1NJc0ltRnNaeUk2SWtWa1JGTkJJaXdpZUNJNklqTmljbU5zYjBJNGFEUk5XbFZJYms5UVVHbGtTbXd0U2pkdVVsRkpXSFJUYUZwM1oyNW1jbHAxVDI4aWZRIiwidmFsaWRGcm9tIjoiMjAyMy0wNi0wN1QyMToxNDoxNC4xNDhaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiaWQiOiJodHRwczovL3N1YmplY3QudmVuZG9yLmV4YW1wbGUifX0=
Example 16: JWT Presentation 
data:application/vp+ld+jwt;base64,ZXlKaGJHY2lPaUpGWkVSVFFTSXNJbWx6Y3lJNkltUnBaRHBxZDJzNlpYbEtjbUZYVVdsUGFVb3hZMjAwTm1GWFZqQmFhbkIzV1ZoS2FHSllUVFppTWtZeFpFZG5ObUZ1WkhKTVdGSnZaRmN4YVdOSVNuQmlibEUyWXpKb2FFeFVTVEZPYW5CMlVXMVNiV1J0V2tSUFdHZzJUVVk1UWxWWVdsSk9NMWt4VFZoc1JGZHNPWHBsUjNBMVRucFdRMVJJU2tsbGF6RlBVbXByZVU5WFZUUkphWGRwWVROU05VbHFiMmxVTUhSUlNXbDNhVmt6U2pKSmFtOXBVbGRSZVU1VVZYaFBVMGx6U1cxR2MxcDVTVFpKYTFaclVrWk9Ra2xwZDJsbFEwazJTV3BPYVdOdFRuTmlNRWswWVVSU1RsZHNWa2xpYXpsUlZVZHNhMU50ZDNSVGFtUjFWV3hHU2xkSVVsUmhSbkF6V2pJMWJXTnNjREZVTWpocFpsRWlMQ0pyYVdRaU9pSWpNQ0lzSW5SNWNDSTZJblpqSzJ4a0sycDNkQ0lzSW1saGRDSTZNVFk0TmpJMU1UVTNOSDAuZXlKQVkyOXVkR1Y0ZENJNld5Sm9kSFJ3Y3pvdkwzZDNkeTUzTXk1dmNtY3Zibk12WTNKbFpHVnVkR2xoYkhNdmRqSWlYU3dpZEhsd1pTSTZXeUpXWlhKcFptbGhZbXhsUTNKbFpHVnVkR2xoYkNKZExDSnBjM04xWlhJaU9pSmthV1E2YW5kck9tVjVTbkpoVjFGcFQybEtNV050TkRaaFYxWXdXbXB3ZDFsWVNtaGlXRTAyWWpKR01XUkhaelpoYm1SeVRGaFNiMlJYTVdsalNFcHdZbTVSTm1NeWFHaE1WRWt4VG1wd2RsRnRVbTFrYlZwRVQxaG9OazFHT1VKVldGcFNUak5aTVUxWWJFUlhiRGw2WlVkd05VNTZWa05VU0VwSlpXc3hUMUpxYTNsUFYxVTBTV2wzYVdFelVqVkphbTlwVkRCMFVVbHBkMmxaTTBveVNXcHZhVkpYVVhsT1ZGVjRUMU5KYzBsdFJuTmFlVWsyU1d0V2ExSkdUa0pKYVhkcFpVTkpOa2xxVG1samJVNXpZakJKTkdGRVVrNVhiRlpKWW1zNVVWVkhiR3RUYlhkMFUycGtkVlZzUmtwWFNGSlVZVVp3TTFveU5XMWpiSEF4VkRJNGFXWlJJaXdpZG1Gc2FXUkdjbTl0SWpvaU1qQXlNeTB3Tmkwd04xUXlNVG94TkRveE5DNHhORGhhSWl3aVkzSmxaR1Z1ZEdsaGJGTjFZbXBsWTNRaU9uc2lhV1FpT2lKb2RIUndjem92TDNOMVltcGxZM1F1ZG1WdVpHOXlMbVY0WVcxd2JHVWlmWDAubmczZlpDQXJyNUYwb1hOS1J1UlFNUXYtdnh4YlozUWJKVkJpcU1QUlVnSEFiSDVkMXptYjhLeUNkNnlVS3IxbmlsZmZiZ2pGUmRpRjFsWUdNRGNhQ0E=
Example 17: Nested Unsecured JSON-LD Verifiable Presentation 
data:application/vp+ld+json;base64,eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiXSwidHlwZSI6WyJWZXJpZmlhYmxlUHJlc2VudGF0aW9uIl0sInZlcmlmaWFibGVDcmVkZW50aWFsIjpbImRhdGE6YXBwbGljYXRpb24vdmMrbGQranNvbjtiYXNlNjQsZXlKQVkyOXVkR1Y0ZENJNld5Sm9kSFJ3Y3pvdkwzZDNkeTUzTXk1dmNtY3Zibk12WTNKbFpHVnVkR2xoYkhNdmRqSWlYU3dpZEhsd1pTSTZXeUpXWlhKcFptbGhZbXhsUTNKbFpHVnVkR2xoYkNKZExDSnBjM04xWlhJaU9pSm9kSFJ3Y3pvdkwybHpjM1ZsY2k1MlpXNWtiM0l1WlhoaGJYQnNaU0lzSW5aaGJHbGtSbkp2YlNJNklqSXdNak10TURZdE1EZFVNakU2TVRRNk1UUXVNVFE0V2lJc0ltTnlaV1JsYm5ScFlXeFRkV0pxWldOMElqcDdJbWxrSWpvaWFIUjBjSE02THk5emRXSnFaV04wTG5abGJtUnZjaTVsZUdGdGNHeGxJbjE5Il19
Example 18: Nested Unsecured JWT 
data:application/vp+ld+jwt;base64,ZXlKaGJHY2lPaUp1YjI1bElpd2lkSGx3SWpvaWRuQXJiR1FyYW5kMEluMC5leUpBWTI5dWRHVjRkQ0k2V3lKb2RIUndjem92TDNkM2R5NTNNeTV2Y21jdmJuTXZZM0psWkdWdWRHbGhiSE12ZGpJaVhTd2lkSGx3WlNJNld5SldaWEpwWm1saFlteGxVSEpsYzJWdWRHRjBhVzl1SWwwc0luWmxjbWxtYVdGaWJHVkRjbVZrWlc1MGFXRnNJanBiSW1SaGRHRTZZWEJ3YkdsallYUnBiMjR2ZG1NcmJHUXJhbmQwTzJKaGMyVTJOQ3hhV0d4TFlVZEtTRmt5YkZCaFZYQXhXV3BKTVdKRmJIQmtNbXhyVTBkNE0xTlhjSFpoVjFKMFZGaEthVkl4Um5sWlZ6VnJUVVZzZFUxRE5XeGxWWEJDVjFSSk5XUlhVa2hXYWxKclVUQnJNbFl6YkV0aU1sSkpWVzVrYW1WdE9USlVSRTVyVFRKU05VNVVUazVsVkZZeVdUSXhhbVJ0U25WVVdGcGFUVEJ3YzFkclpGZGtWMUpJWWtkb2FWTkZNVEphUjNCS1lWWm9WR1F5Ykd0VFIzZ3pWMnhPU2s1c1pEVlRiR1JoVjBWd2QxZHRNWE5oUm14MFpVZDRVazB3Y0hOWGEyUlhaRmRTU0dKSGFHbFJNSEJyVkVWT1MyTkhUWHBVYWtaaFYwVnNjRlF5YkV0aU1sSkpWVzVrYW1WdE9USlVSRXB6WlcxTmVsWnRlR3BoVkZWNVYyeGpNV0V5U1hwVFdGWmhWMGRvYjFsc2FFTmpNWEJVVTFoT1NtSnNjRzlaYTJSellURktkVk51V21sVk1Hc3lVMWR3U21Rd01YRlVXRkpPVWtac01GUlZVbXRXVlRGeFVsUmFUbFpHUlRKVVZsSlNaRlV4VlZWVVVsaGhWV3g2VTFjeFQyVldjRmhWYlhocFlteEtkMWRXWkRSV1IxSllVMjVHWVZZd05IZFRWM0IzVGpCc2RHSkhkRXBoYlRsd1dWVm9VMDFIVGtsVVZGcE5aVlJzTmxwR1pFdGpWbkJZVkdwQ1RXSnNjSE5aYlRGVFpHMU9jRTVYZUd4U01Gb3dXVEJrTkdKRmJIVk5WR3QxSWwxOS4=

9.5 Detached Proofs

Example 19: Verifiable Credential 
{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "type": [
    "VerifiableCredential"
  ],
  "issuer": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:_Fpfe27AuGmEljZE9s2lw2UH-qrZLRFNrWbJrWIe4SI",
  "validFrom": "2023-06-07T21:14:14.148Z",
  "credentialSubject": {
    "id": "https://subject.vendor.example"
  }
}
Example 20: Detached Verifiable Credential Proof 
eyJhbGciOiJFUzM4NCIsInR5cCI6InZjK2xkK2p3dCIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..Z-s5JgWQK91e1bzk-87ofJcRqGrw7wGehepSYH3U18u9-BNi9QOcgHWMFAN72HGNNhmn9xyT7UF59om7Wbb_IQTPAlzjMdPbzfq3bRffutP-Swg_Sz2R1VwpufVJ5Ult
Example 21: Verifiable Presentation 
{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "type": [
    "VerifiablePresentation"
  ],
  "holder": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:_Fpfe27AuGmEljZE9s2lw2UH-qrZLRFNrWbJrWIe4SI"
}
Example 22: Detached Presentation Proof 
eyJhbGciOiJFUzM4NCIsInR5cCI6InZwK2xkK2p3dCIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TsKRjY56LWTPPXWKLYfDs-NKmZZHIcrZ2pndwEDtO5DaGiDW3OtABr-esL9y6CdZTxwshoqZCs_RnPRx17-uO8k_SBugAQwnzN8bnulkSN4gXaST0kxk23X4bVmw6sBD
Issue

TODO add COSE Sign1 detached payload examples

9.6 Selective Disclosure

The following examples are taken from Selective Disclosure for JWTs (SD-JWT).

Issue

These example are from a work in progress draft.

An issuer might start with a vc+ld+json claimset, for example:

Example 23 
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/vaccination/v1"
  ],
  "type": [
    "VerifiableCredential",
    "VaccinationCertificate"
  ],
  "issuer": "https://example.com/issuer",
  "issuanceDate": "2023-02-09T11:01:59Z",
  "expirationDate": "2028-02-08T11:01:59Z",
  "name": "COVID-19 Vaccination Certificate",
  "description": "COVID-19 Vaccination Certificate",
  "credentialSubject": {
    "vaccine": {
      "type": "Vaccine",
      "atcCode": "J07BX03",
      "medicinalProductName": "COVID-19 Vaccine Moderna",
      "marketingAuthorizationHolder": "Moderna Biotech"
    },
    "nextVaccinationDate": "2021-08-16T13:40:12Z",
    "countryOfVaccination": "GE",
    "dateOfVaccination": "2021-06-23T13:40:12Z",
    "order": "3/3",
    "recipient": {
      "type": "VaccineRecipient",
      "gender": "Female",
      "birthDate": "1961-08-17",
      "givenName": "Marion",
      "familyName": "Mustermann"
    },
    "type": "VaccinationEvent",
    "administeringCentre": "Praxis Sommergarten",
    "batchNumber": "1626382736",
    "healthProfessional": "883110000015376"
  }
}

The issuer converts this claimset into the SD-JWT payload, and encodes the token, for example:

Example 24 
eyJhbGciOiAiRVMyNTYifQ.eyJpc3MiOiAiaHR0cHM6Ly9leGFtcGxlLmNvbS9pc3N1Z
XIiLCAiaWF0IjogMTY4MzAwMDAwMCwgImV4cCI6IDE4ODMwMDAwMDAsICJAY29udGV4d
CI6IFsiaHR0cHM6Ly93d3cudzMub3JnLzIwMTgvY3JlZGVudGlhbHMvdjEiLCAiaHR0c
HM6Ly93M2lkLm9yZy92YWNjaW5hdGlvbi92MSJdLCAidHlwZSI6IFsiVmVyaWZpYWJsZ
UNyZWRlbnRpYWwiLCAiVmFjY2luYXRpb25DZXJ0aWZpY2F0ZSJdLCAiaXNzdWVyIjogI
mh0dHBzOi8vZXhhbXBsZS5jb20vaXNzdWVyIiwgImlzc3VhbmNlRGF0ZSI6ICIyMDIzL
TAyLTA5VDExOjAxOjU5WiIsICJleHBpcmF0aW9uRGF0ZSI6ICIyMDI4LTAyLTA4VDExO
jAxOjU5WiIsICJuYW1lIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRlI
iwgImRlc2NyaXB0aW9uIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRlI
iwgImNyZWRlbnRpYWxTdWJqZWN0IjogeyJfc2QiOiBbIjFWX0stOGxEUThpRlhCRlhiW
lk5ZWhxUjRIYWJXQ2k1VDB5Ykl6WlBld3ciLCAiSnpqTGd0UDI5ZFAtQjN0ZDEyUDY3N
GdGbUsyenk4MUhNdEJnZjZDSk5XZyIsICJSMmZHYmZBMDdaX1lsa3FtTlp5bWExeHl5e
DFYc3RJaVM2QjFZYmwySlo0IiwgIlRDbXpybDdLMmdldl9kdTdwY01JeXpSTEhwLVllZ
y1GbF9jeHRyVXZQeGciLCAiVjdrSkJMSzc4VG1WRE9tcmZKN1p1VVBIdUtfMmNjN3laU
mE0cVYxdHh3TSIsICJiMGVVc3ZHUC1PRERkRm9ZNE5semxYYzN0RHNsV0p0Q0pGNzVOd
zhPal9nIiwgInpKS19lU01YandNOGRYbU1aTG5JOEZHTTA4ekozX3ViR2VFTUotNVRCe
TAiXSwgInZhY2NpbmUiOiB7Il9zZCI6IFsiMWNGNWhMd2toTU5JYXFmV0pyWEk3Tk1XZ
WRMLTlmNlkyUEE1MnlQalNaSSIsICJIaXk2V1d1ZUxENWJuMTYyOTh0UHY3R1hobWxkT
URPVG5CaS1DWmJwaE5vIiwgIkxiMDI3cTY5MWpYWGwtakM3M3ZpOGViT2o5c214M0MtX
29nN2dBNFRCUUUiXSwgInR5cGUiOiAiVmFjY2luZSJ9LCAicmVjaXBpZW50IjogeyJfc
2QiOiBbIjFsU1FCTlkyNHEwVGg2T0d6dGhxLTctNGw2Y0FheHJZWE9HWnBlV19sbkEiL
CAiM256THE4MU0yb04wNndkdjFzaEh2T0VKVnhaNUtMbWREa0hFREpBQldFSSIsICJQb
jFzV2kwNkc0TEpybm4tX1JUMFJiTV9IVGR4blBKUXVYMmZ6V3ZfSk9VIiwgImxGOXV6Z
HN3N0hwbEdMYzcxNFRyNFdPN01HSnphN3R0N1FGbGVDWDRJdHciXSwgInR5cGUiOiAiV
mFjY2luZVJlY2lwaWVudCJ9LCAidHlwZSI6ICJWYWNjaW5hdGlvbkV2ZW50In0sICJfc
2RfYWxnIjogInNoYS0yNTYifQ.5jJEqiRViN_DJ4VMxHQIN4KK-Cdfn30nY3nRe5jGxS
5Pths5G7mF1GWy9TawYuyFwCze7qiCIx_MhJ68Uu5zeQ~WyIyR0xDNDJzS1F2ZUNmR2Z
yeU5STjl3IiwgImF0Y0NvZGUiLCAiSjA3QlgwMyJd~WyJlbHVWNU9nM2dTTklJOEVZbn
N4QV9BIiwgIm1lZGljaW5hbFByb2R1Y3ROYW1lIiwgIkNPVklELTE5IFZhY2NpbmUgTW
9kZXJuYSJd~WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgIm1hcmtldGluZ0F1dGhvc
ml6YXRpb25Ib2xkZXIiLCAiTW9kZXJuYSBCaW90ZWNoIl0~WyJlSThaV205UW5LUHBOU
GVOZW5IZGhRIiwgIm5leHRWYWNjaW5hdGlvbkRhdGUiLCAiMjAyMS0wOC0xNlQxMzo0M
DoxMloiXQ~WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImNvdW50cnlPZlZhY2Npbm
F0aW9uIiwgIkdFIl0~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRhdGVPZlZhY2
NpbmF0aW9uIiwgIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0~WyJQYzMzSk0yTGNoY1VfbE
hnZ3ZfdWZRIiwgIm9yZGVyIiwgIjMvMyJd~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBI
iwgImdlbmRlciIsICJGZW1hbGUiXQ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIm
JpcnRoRGF0ZSIsICIxOTYxLTA4LTE3Il0~WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIi
wgImdpdmVuTmFtZSIsICJNYXJpb24iXQ~WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53Iiw
gImZhbWlseU5hbWUiLCAiTXVzdGVybWFubiJd~WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS
13IiwgImFkbWluaXN0ZXJpbmdDZW50cmUiLCAiUHJheGlzIFNvbW1lcmdhcnRlbiJd~W
yJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImJhdGNoTnVtYmVyIiwgIjE2MjYzODI3M
zYiXQ~WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImhlYWx0aFByb2Zlc3Npb25hbC
IsICI4ODMxMTAwMDAwMTUzNzYiXQ~

Notice that, in the case of sd-jwt, the decoded payload is different from the input claimset:

Example 25 
{
  "iss": "https://example.com/issuer",
  "iat": 1683000000,
  "exp": 1883000000,
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/vaccination/v1"
  ],
  "type": [
    "VerifiableCredential",
    "VaccinationCertificate"
  ],
  "issuer": "https://example.com/issuer",
  "issuanceDate": "2023-02-09T11:01:59Z",
  "expirationDate": "2028-02-08T11:01:59Z",
  "name": "COVID-19 Vaccination Certificate",
  "description": "COVID-19 Vaccination Certificate",
  "credentialSubject": {
    "_sd": [
      "1V_K-8lDQ8iFXBFXbZY9ehqR4HabWCi5T0ybIzZPeww",
      "JzjLgtP29dP-B3td12P674gFmK2zy81HMtBgf6CJNWg",
      "R2fGbfA07Z_YlkqmNZyma1xyyx1XstIiS6B1Ybl2JZ4",
      "TCmzrl7K2gev_du7pcMIyzRLHp-Yeg-Fl_cxtrUvPxg",
      "V7kJBLK78TmVDOmrfJ7ZuUPHuK_2cc7yZRa4qV1txwM",
      "b0eUsvGP-ODDdFoY4NlzlXc3tDslWJtCJF75Nw8Oj_g",
      "zJK_eSMXjwM8dXmMZLnI8FGM08zJ3_ubGeEMJ-5TBy0"
    ],
    "vaccine": {
      "_sd": [
        "1cF5hLwkhMNIaqfWJrXI7NMWedL-9f6Y2PA52yPjSZI",
        "Hiy6WWueLD5bn16298tPv7GXhmldMDOTnBi-CZbphNo",
        "Lb027q691jXXl-jC73vi8ebOj9smx3C-_og7gA4TBQE"
      ],
      "type": "Vaccine"
    },
    "recipient": {
      "_sd": [
        "1lSQBNY24q0Th6OGzthq-7-4l6cAaxrYXOGZpeW_lnA",
        "3nzLq81M2oN06wdv1shHvOEJVxZ5KLmdDkHEDJABWEI",
        "Pn1sWi06G4LJrnn-_RT0RbM_HTdxnPJQuX2fzWv_JOU",
        "lF9uzdsw7HplGLc714Tr4WO7MGJza7tt7QFleCX4Itw"
      ],
      "type": "VaccineRecipient"
    },
    "type": "VaccinationEvent"
  },
  "_sd_alg": "sha-256"
}
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/vaccination/v1"
  ],
  "type": [
    "VerifiableCredential",
    "VaccinationCertificate"
  ],
  "issuer": "https://example.com/issuer",
  "issuanceDate": "2023-02-09T11:01:59Z",
  "expirationDate": "2028-02-08T11:01:59Z",
  "name": "COVID-19 Vaccination Certificate",
  "description": "COVID-19 Vaccination Certificate",
  "credentialSubject": {
    "vaccine": {
      "type": "Vaccine",
      "medicinalProductName": "COVID-19 Vaccine Moderna",
      "atcCode": "J07BX03"
    },
    "recipient": {
      "type": "VaccineRecipient"
    },
    "type": "VaccinationEvent",
    "order": "3/3",
    "dateOfVaccination": "2021-06-23T13:40:12Z"
  },
  "_sd_alg": "sha-256",
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
      "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
    }
  }
}

See Selective Disclosure for JWTs (SD-JWT) for a detailed explanation of each disclosable claim, and the mandatory to disclose claims.

The holder, converts the issued sd-jwt to its presentation form, redacting any fields they don't wish to disclose to the verifier, for example:

Example 26 
eyJhbGciOiAiRVMyNTYifQ.eyJpc3MiOiAiaHR0cHM6Ly9leGFtcGxlLmNvbS9pc3N1Z
XIiLCAiaWF0IjogMTY4MzAwMDAwMCwgImV4cCI6IDE4ODMwMDAwMDAsICJAY29udGV4d
CI6IFsiaHR0cHM6Ly93d3cudzMub3JnLzIwMTgvY3JlZGVudGlhbHMvdjEiLCAiaHR0c
HM6Ly93M2lkLm9yZy92YWNjaW5hdGlvbi92MSJdLCAidHlwZSI6IFsiVmVyaWZpYWJsZ
UNyZWRlbnRpYWwiLCAiVmFjY2luYXRpb25DZXJ0aWZpY2F0ZSJdLCAiaXNzdWVyIjogI
mh0dHBzOi8vZXhhbXBsZS5jb20vaXNzdWVyIiwgImlzc3VhbmNlRGF0ZSI6ICIyMDIzL
TAyLTA5VDExOjAxOjU5WiIsICJleHBpcmF0aW9uRGF0ZSI6ICIyMDI4LTAyLTA4VDExO
jAxOjU5WiIsICJuYW1lIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRlI
iwgImRlc2NyaXB0aW9uIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRlI
iwgImNyZWRlbnRpYWxTdWJqZWN0IjogeyJfc2QiOiBbIjFWX0stOGxEUThpRlhCRlhiW
lk5ZWhxUjRIYWJXQ2k1VDB5Ykl6WlBld3ciLCAiSnpqTGd0UDI5ZFAtQjN0ZDEyUDY3N
GdGbUsyenk4MUhNdEJnZjZDSk5XZyIsICJSMmZHYmZBMDdaX1lsa3FtTlp5bWExeHl5e
DFYc3RJaVM2QjFZYmwySlo0IiwgIlRDbXpybDdLMmdldl9kdTdwY01JeXpSTEhwLVllZ
y1GbF9jeHRyVXZQeGciLCAiVjdrSkJMSzc4VG1WRE9tcmZKN1p1VVBIdUtfMmNjN3laU
mE0cVYxdHh3TSIsICJiMGVVc3ZHUC1PRERkRm9ZNE5semxYYzN0RHNsV0p0Q0pGNzVOd
zhPal9nIiwgInpKS19lU01YandNOGRYbU1aTG5JOEZHTTA4ekozX3ViR2VFTUotNVRCe
TAiXSwgInZhY2NpbmUiOiB7Il9zZCI6IFsiMWNGNWhMd2toTU5JYXFmV0pyWEk3Tk1XZ
WRMLTlmNlkyUEE1MnlQalNaSSIsICJIaXk2V1d1ZUxENWJuMTYyOTh0UHY3R1hobWxkT
URPVG5CaS1DWmJwaE5vIiwgIkxiMDI3cTY5MWpYWGwtakM3M3ZpOGViT2o5c214M0MtX
29nN2dBNFRCUUUiXSwgInR5cGUiOiAiVmFjY2luZSJ9LCAicmVjaXBpZW50IjogeyJfc
2QiOiBbIjFsU1FCTlkyNHEwVGg2T0d6dGhxLTctNGw2Y0FheHJZWE9HWnBlV19sbkEiL
CAiM256THE4MU0yb04wNndkdjFzaEh2T0VKVnhaNUtMbWREa0hFREpBQldFSSIsICJQb
jFzV2kwNkc0TEpybm4tX1JUMFJiTV9IVGR4blBKUXVYMmZ6V3ZfSk9VIiwgImxGOXV6Z
HN3N0hwbEdMYzcxNFRyNFdPN01HSnphN3R0N1FGbGVDWDRJdHciXSwgInR5cGUiOiAiV
mFjY2luZVJlY2lwaWVudCJ9LCAidHlwZSI6ICJWYWNjaW5hdGlvbkV2ZW50In0sICJfc
2RfYWxnIjogInNoYS0yNTYifQ.5jJEqiRViN_DJ4VMxHQIN4KK-Cdfn30nY3nRe5jGxS
5Pths5G7mF1GWy9TawYuyFwCze7qiCIx_MhJ68Uu5zeQ~WyJQYzMzSk0yTGNoY1VfbEh
nZ3ZfdWZRIiwgIm9yZGVyIiwgIjMvMyJd~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIi
wgImRhdGVPZlZhY2NpbmF0aW9uIiwgIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0~WyIyR0
xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImF0Y0NvZGUiLCAiSjA3QlgwMyJd~WyJlbHVWN
U9nM2dTTklJOEVZbnN4QV9BIiwgIm1lZGljaW5hbFByb2R1Y3ROYW1lIiwgIkNPVklEL
TE5IFZhY2NpbmUgTW9kZXJuYSJd~

After validation, the Verifier will have the following data for further processing:

Note

A benefit of using vc+ld+jwt and vc+ld+sd-jwt is that they both produce vc+ld+json which can be further processed as RDF by a verifier.

Issue

The working group is still discussing the relevance of the JWT BCP, and distinguishing vc+ld+sd-jwt from vc+sd-jwt via type.

Example 27 
{
  "iss": "https://example.com/issuer",
  "iat": 1683000000,
  "exp": 1883000000,
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/vaccination/v1"
  ],
  "type": [
    "VerifiableCredential",
    "VaccinationCertificate"
  ],
  "issuer": "https://example.com/issuer",
  "issuanceDate": "2023-02-09T11:01:59Z",
  "expirationDate": "2028-02-08T11:01:59Z",
  "name": "COVID-19 Vaccination Certificate",
  "description": "COVID-19 Vaccination Certificate",
  "credentialSubject": {
    "vaccine": {
      "type": "Vaccine",
      "atcCode": "J07BX03",
      "medicinalProductName": "COVID-19 Vaccine Moderna"
    },
    "recipient": {
      "type": "VaccineRecipient"
    },
    "type": "VaccinationEvent",
    "order": "3/3",
    "dateOfVaccination": "2021-06-23T13:40:12Z"
  },
  "_sd_alg": "sha-256"
}

A. References

A.1 Normative references

[json-ld11]
JSON-LD 1.1. Gregg Kellogg; Pierre-Antoine Champin; Dave Longley. W3C. 16 July 2020. W3C Recommendation. URL: https://www.w3.org/TR/json-ld11/
[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
[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
[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
[RFC7519]
JSON Web Token (JWT). M. Jones; J. Bradley; N. Sakimura. IETF. May 2015. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7519
[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
[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-05
[VC-DATA-MODEL]
Verifiable Credentials Data Model v1.1. Manu Sporny; Grant Noble; Dave Longley; Daniel Burnett; Brent Zundel; Kyle Den Hartog. W3C. 3 March 2022. W3C Recommendation. URL: https://www.w3.org/TR/vc-data-model/

A.2 Informative references

[RFC7516]
JSON Web Encryption (JWE). M. Jones; J. Hildebrand. IETF. May 2015. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7516
[WCAG21]
Web Content Accessibility Guidelines (WCAG) 2.1. Andrew Kirkpatrick; Joshue O'Connor; Alastair Campbell; Michael Cooper. W3C. 5 June 2018. W3C Recommendation. URL: https://www.w3.org/TR/WCAG21/