Securing Verifiable Credentials using JOSE and COSE

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.

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`? has-pr before-CR

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 has-pr before-CR

          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 has-pr before-CR

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 has-pr before-CR

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)

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.

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.

These parameters and claims can be used to help verifiers discover verification keys.

If kid is present in the JOSE 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.

If iss is present in the JOSE Header or the JWT Claims , 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 expected to be useful to distinguish the specific key used.

Issue 31: About the optionality of the "kid" field in JWT-formatted VCs/VPs has-pr before-CR

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

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

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.

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-based Verifiable Credentials (SD-JWT VC).

This section is non-normative.

Issue 160: Controller Documents vs DID Documents

The Working Group is currently attempting to determine the best path forward to ensure alignment between data integrity controller documents, vc-jose-cose controller documents, and did documents. The working group is still discussing how to align these definitions.

A few of the options that are currently being explored include:

Define controller documents in the Verifiable Credentials Data Model v2.0 specification and refer to that definition from vc-data-integrity and vc-jose-cose.
Define controller documents in a new TR track work item published by the VCWG and then narrow/profile that definition in vc-data-integrity and vc-jose-cose.
Duplicate controller document text in vc-data-integrity and vc-jose-cose.
Refer to DID Core for the definition of controller documents (not an option because URLs are not DIDs)

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.

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 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 6: Example verification method structure

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://www.w3.org/ns/credentials/v2"
  ]
  "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.

Verification material SHOULD 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 or COSE key 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 publicKeyMultibase at the same time is prohibited.

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

Example 7: Verification methods using publicKeyJwk

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://www.w3.org/ns/credentials/v2"
  ]
  "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)
    }
  }],
  ...
}

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

When specifing 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 Example 7 for an example of a public key with a compound key identifier.
secretKeyJwk: The secretKeyJwk property is OPTIONAL. If present, its value MUST be a map representing a JSON Web Key that conforms to [RFC7517].

An example of an object that conforms to this data model is provided below:

Example 8: JSON Web Key encoding of an 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. Although alg is optional, it is RECOMMENDED to be included to avoid security issues arising from using the same key with multiple algorithms. The crv property identifies the particular curve type of the public key. The 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. Finally, the x property specifies the point on the Ed25519 curve that is associated with the public key.

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

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

Example 9: 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).

Verification methods can be referenced from properties associated with various verification relationships as described in 5.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 10: Referencing verification methods

    {
...

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

...
    }

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. In order to maximize global interoperability, any such properties used SHOULD be registered in the Data Integrity Specification Registries [TBD: DIS-REGISTRIES].

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 11: 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.

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 12: 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",
  ...
}

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

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

This section is non-normative.

Example 13: 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"]
}

Example 14: A revocable credential with multiple subjects

application/vc+ld+json
text/vnd.mermaid
application/vc+ld+json+sd-jwt

{
  "@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"
  }]
}

graph LR

22("VerifiableCredential")
23{{"id"}}
24("https://contoso.example/credentials/23894672394")
25(("type"))
26("K9UnitCredential")
27("issuer")
28{{"id"}}
29("https://contoso.example")
30("validFrom")
31("2015-04-16T05:11:32.432Z")
32("credentialStatus")
33{{"id"}}
34("https://contoso.example/credentials/status/4#273762")
35(("type"))
36("StatusList2021Entry")
37("statusPurpose")
38("revocation")
39("statusListIndex")
40("273762")
41("statusListCredential")
42("https://contoso.example/credentials/status/4")
43("credentialSubject")
44{{"id"}}
45("did:example:1312387641")
46(("type"))
47("Person")
48("credentialSubject")
49{{"id"}}
50("did:example:63888231")
51(("type"))
52("Dog")

22 --- 23
23 --- 24
22 --- 25
25 --- 26
22 --- 27
27 --- 28
28 --- 29
22 --- 30
30 --- 31
22 --- 32
32 --- 33
33 --- 34
32 --- 35
35 --- 36
32 --- 37
37 --- 38
32 --- 39
39 --- 40
32 --- 41
41 --- 42
22 --- 43
43 --- 44
44 --- 45
43 --- 46
46 --- 47
22 --- 48
48 --- 49
49 --- 50
48 --- 51
51 --- 52

---------------- Issuer Claims ----------------
"@context":
  - https://www.w3.org/ns/credentials/v2
  - https://www.w3.org/ns/credentials/examples/v2
!sd id: https://contoso.example/credentials/23894672394
!sd type:
  - VerifiableCredential
  - K9UnitCredential
issuer:
  !sd id: https://contoso.example
validFrom: 2015-04-16T05:11:32.432Z
credentialStatus:
  !sd id: https://contoso.example/credentials/status/4#273762
  !sd type: StatusList2021Entry
  statusPurpose: revocation
  statusListIndex: "273762"
  statusListCredential: https://contoso.example/credentials/status/4
credentialSubject:
  - !sd id: did:example:1312387641
    !sd type: Person
  - !sd id: did:example:63888231
    !sd type: Dog
---------------- Holder Disclosure ----------------
id: False
type: True
issuer:
  id: True
credentialStatus:
  id: True
---------------- Decoded Protected Header ----------------
{
  "alg": "ES256",
  "typ": "vc+ld+json+sd-jwt",
  "cty": "vc+ld+json"
}
---------------- Decoded Protected Claimset ----------------
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "issuer": {
    "id": "https://contoso.example"
  },
  "validFrom": "2015-04-16T05:11:32.432Z",
  "credentialStatus": {
    "statusPurpose": "revocation",
    "statusListIndex": "273762",
    "statusListCredential": "https://contoso.example/credentials/status/4",
    "id": "https://contoso.example/credentials/status/4#273762"
  },
  "credentialSubject": [
    {},
    {}
  ],
  "iss": "did:web:issuer.example",
  "iat": 1696618914,
  "exp": 1728241314,
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "alg": "ES256",
      "x": "ieZd9R1lOcMn08RYiZNFmYEy87RHPjxYZqBkOH4UVBY",
      "y": "lpnnzT-TIv3vdBEOyCLcTfejPELRJYUFp34dgx_9nw0"
    }
  },
  "type": [
    "VerifiableCredential",
    "K9UnitCredential"
  ]
}
---------------- Compact Encoded Selective Disclosure JSON Web Token ----------------
eyJhbGciOiJFUzI1NiIsInR5cCI6InZjK2xkK2pzb24rc2Qtand0IiwiY3R5IjoidmMrbGQranNvbiJ9.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjp7Il9zZCI6WyJBSUR4RjhCbFpmczB2XzlfWkk1S2w4SWpzM3pRaFVfT0Z3T0RUdWZacXprIl19LCJ2YWxpZEZyb20iOiIyMDE1LTA0LTE2VDA1OjExOjMyLjQzMloiLCJjcmVkZW50aWFsU3RhdHVzIjp7InN0YXR1c1B1cnBvc2UiOiJyZXZvY2F0aW9uIiwic3RhdHVzTGlzdEluZGV4IjoiMjczNzYyIiwic3RhdHVzTGlzdENyZWRlbnRpYWwiOiJodHRwczovL2NvbnRvc28uZXhhbXBsZS9jcmVkZW50aWFscy9zdGF0dXMvNCIsIl9zZCI6WyIxRjNuMFJPRThObFBzNXQwZUxNQUhadWszQWU4eEhfRFJPS3hjdHZTWVNzIiwiQmlad2phTlAtdG9yMEpJSUVZOTFWanVMYURuYWVBSjFHVzlRMkxxelhmOCJdfSwiY3JlZGVudGlhbFN1YmplY3QiOlt7Il9zZCI6WyJET3lqSi1yWThONnNGLW4xeC1KRVc4UlFXMXFUSXR4Wkk5dlREVjBBUzJFIiwiV1htSndGN1BuWk5mSzVlWmZ1STRkWVJVLWNndHBLRmNJMEVaNmdYM2FacyJdfSx7Il9zZCI6WyI3aXI2aU44S2k2YXB2MFZPcHlmWVRNbnBBUVQ5NWc5VnRsaWhfRkdlWG9NIiwiT19PSGVHanpiQ1p6QjBnUWJCZEJRT2hIclM3ZXlMYjdJWnhmM3dTX1VaVSJdfV0sIl9zZCI6WyJORlJiRjNZcXo1bHNPM2ZMeUFJZ1VIaEN0SGg2YVJuem5xZlJLT19MeDU0IiwiYUhTaGpETEh6TUhJRjNHejdmSzluUkpodzZ1SmFmazlmTi16aXBoZGtXVSJdLCJfc2RfYWxnIjoic2hhLTI1NiIsImlzcyI6ImRpZDp3ZWI6aXNzdWVyLmV4YW1wbGUiLCJpYXQiOjE2OTY2MTg5MTQsImV4cCI6MTcyODI0MTMxNCwiY25mIjp7Imp3ayI6eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2IiwiYWxnIjoiRVMyNTYiLCJ4IjoiaWVaZDlSMWxPY01uMDhSWWlaTkZtWUV5ODdSSFBqeFlacUJrT0g0VVZCWSIsInkiOiJscG5uelQtVEl2M3ZkQkVPeUNMY1RmZWpQRUxSSllVRnAzNGRneF85bncwIn19fQ.dlPuUH16-yWs9CUAODYJR6EcJdXCx6vmli0elx3YXMLXC5pyo9zTjkKXUp_VVllUyfLtZKb-Z9SoMXu6lv1agA~WyIyeHlyR3F5WTA1bUlZMWdpVlpNV0R3IiwgImlkIiwgImh0dHBzOi8vY29udG9zby5leGFtcGxlIl0~WyJ3cWpjQVpfZGYtclRsTW5qRnA5VzZBIiwgImlkIiwgImh0dHBzOi8vY29udG9zby5leGFtcGxlL2NyZWRlbnRpYWxzL3N0YXR1cy80IzI3Mzc2MiJd~WyJMMnQtSWx6dHhYRGJxalBIMDloRXB3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIks5VW5pdENyZWRlbnRpYWwiXV0~eyJhbGciOiJFUzI1NiIsInR5cCI6ImtiK2p3dCJ9.eyJub25jZSI6Ilcxb3BuaUhhQXpqYkJHVFdvQmU4R3ciLCJhdWQiOiJkaWQ6d2ViOnZlcmlmaWVyLmV4YW1wbGUiLCJpYXQiOjE2OTY2MTg5MTR9.HbZKA9g4dYDbsti2i8zoAvi7g8I3xnBF9_gx1k8NHA94R2G6yYARYE3XXXPGlJzomg1rCq0l7IwuqtPW4DxQ_A

Example 15: A credential with a schema

application/vc+ld+json
text/vnd.mermaid
application/vc+ld+json+sd-jwt

{
  "@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"
  }
}

graph LR

53("VerifiableCredential")
54{{"id"}}
55("https://contoso.example/credentials/35327255")
56(("type"))
57("KYCExample")
58("issuer")
59("did:web:contoso.example")
60("validFrom")
61("2019-05-25T03:10:16.992Z")
62("validUntil")
63("2027-05-25T03:10:16.992Z")
64("credentialSchema")
65{{"id"}}
66("https://contoso.example/bafybeigdyr...lqabf3oclgtqy55fbzdi")
67(("type"))
68("JsonSchema")
69("credentialSubject")
70{{"id"}}
71("did:example:1231588")
72(("type"))
73("Person")

53 --- 54
54 --- 55
53 --- 56
56 --- 57
53 --- 58
58 --- 59
53 --- 60
60 --- 61
53 --- 62
62 --- 63
53 --- 64
64 --- 65
65 --- 66
64 --- 67
67 --- 68
53 --- 69
69 --- 70
70 --- 71
69 --- 72
72 --- 73

---------------- Issuer Claims ----------------
"@context":
  - https://www.w3.org/ns/credentials/v2
  - https://www.w3.org/ns/credentials/examples/v2
!sd id: https://contoso.example/credentials/35327255
!sd type:
  - VerifiableCredential
  - KYCExample
issuer: did:web:contoso.example
validFrom: 2019-05-25T03:10:16.992Z
validUntil: 2027-05-25T03:10:16.992Z
credentialSchema:
  !sd id: https://contoso.example/bafybeigdyr...lqabf3oclgtqy55fbzdi
  !sd type: JsonSchema
credentialSubject:
  !sd id: did:example:1231588
  !sd type: Person
---------------- Holder Disclosure ----------------
issuer:
  id: True
credentialStatus:
  id: True
credentialSubject:
  id: True
  type: False
---------------- Decoded Protected Header ----------------
{
  "alg": "ES384"
}
---------------- Decoded Protected Claimset ----------------
{
  "@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": {},
  "credentialSubject": {
    "id": "did:example:1231588"
  },
  "iss": "did:web:issuer.example",
  "iat": 1696618914,
  "exp": 1728241314,
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-384",
      "alg": "ES384",
      "x": "kPzP7dtj6WGJyl-LSB_p6G7IXQuzy7Yt2MgOODqo-uOzYmwKjtqabNsJCH_T9NUd",
      "y": "yCJ0scFHITLdcrzFFiHOWjNiPEd0y8EiWhNjvfJhAbtfvR9Hmdserpkkm6796_cd"
    }
  }
}
---------------- Compact Encoded Selective Disclosure JSON Web Token ----------------
eyJhbGciOiJFUzM4NCJ9.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiZGlkOndlYjpjb250b3NvLmV4YW1wbGUiLCJ2YWxpZEZyb20iOiIyMDE5LTA1LTI1VDAzOjEwOjE2Ljk5MloiLCJ2YWxpZFVudGlsIjoiMjAyNy0wNS0yNVQwMzoxMDoxNi45OTJaIiwiY3JlZGVudGlhbFNjaGVtYSI6eyJfc2QiOlsiNWw3Ql9ZV0Uzd0trTlVNVHNTamtsalcxZ180aFJyMXVsUVNxeVZ4VUxSWSIsIlUyXzVkTW9uZWxoc0VKRnhfS25teFp0b2FHUllFZ1hER25SSVF6b3BFX2MiXX0sImNyZWRlbnRpYWxTdWJqZWN0Ijp7Il9zZCI6WyJPV2VoaTJNODZlVGhxYmZHX2Rma2tneFVTMnNVQzk5N0JwRnVGTzVMcC1RIiwidGZoYjFEbmJ0Y0FRLVdfenNOc0R2ZnFlcEtYcVdtWm85bkdJZXlNeGMtTSJdfSwiX3NkIjpbInI2MUhrUTZWaTlLVmd5azE1b21LV0xVQVhOVktuWnJRaS1ranZualhSTDgiLCJ3YVd0TUJPUy1zQVVaYXJEaFdSRGdQTVJCUnNoMzIxS3JlYUdwNEhsZEM4Il0sIl9zZF9hbGciOiJzaGEtMjU2IiwiaXNzIjoiZGlkOndlYjppc3N1ZXIuZXhhbXBsZSIsImlhdCI6MTY5NjYxODkxNCwiZXhwIjoxNzI4MjQxMzE0LCJjbmYiOnsiandrIjp7Imt0eSI6IkVDIiwiY3J2IjoiUC0zODQiLCJhbGciOiJFUzM4NCIsIngiOiJrUHpQN2R0ajZXR0p5bC1MU0JfcDZHN0lYUXV6eTdZdDJNZ09PRHFvLXVPelltd0tqdHFhYk5zSkNIX1Q5TlVkIiwieSI6InlDSjBzY0ZISVRMZGNyekZGaUhPV2pOaVBFZDB5OEVpV2hOanZmSmhBYnRmdlI5SG1kc2VycGtrbTY3OTZfY2QifX19.LKZ2ku6js00o569HO3k8sOK-M0Ajmu2s8J3Y22GNMh9mJuPXUkfjN1GfPI2erz3fiugNYU_Px36ToSkh4V10rTVVSv2MHe3vAgN4v5WbrOY99YJ-bZMkVa9ERrBIIhRb~WyJ2RlFkdTdFRVVnYjNjeFQxYWc4ZUZBIiwgImlkIiwgImRpZDpleGFtcGxlOjEyMzE1ODgiXQ~eyJhbGciOiJFUzM4NCIsInR5cCI6ImtiK2p3dCJ9.eyJub25jZSI6IldVQjZBZDVJNnM2TXlPYVhsd1lyamciLCJhdWQiOiJkaWQ6d2ViOnZlcmlmaWVyLmV4YW1wbGUiLCJpYXQiOjE2OTY2MTg5MTR9.6YlVD28hG7xlNr81AD-feI3PYB_8Ao8EE3_rBqSkBQv5rmthCwRpik0x21a6UtbYhVWGXbz651fFbac9Ra0NR-ZzrKaZt3GLwIxyjyzT9TkGTZ6sYEUzA48sW-0y0jon

Example 16: Presentation

application/vp+ld+json
text/vnd.mermaid
application/vp+ld+json+sd-jwt

{
  "@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="
  ]
}

graph LR

87("VerifiablePresentation")
88("holder")
89("urn:ietf:params:oauth:jwk-thumbprint:sha-256:_Fpfe27AuGmEljZE9s2lw2UH-qrZLRFNrWbJrWIe4SI")
90("verifiableCredential")
91("issuer")
92("https://issuer.example/issuers/68")
93("validFrom")
94("2023-06-07T21:14:14.148Z")
95("credentialSubject")
96{{"id"}}
97("https://subject.vendor.example")
98("verifiableCredential")
99("https://vendor.example/credentials/42")
100("verifiableCredential")
101("did:example:123")
102("verifiableCredential")
103("urn:uuid:01ec9426-c175-4e39-a006-d30050e28214")
104("verifiableCredential")
105("urn:ietf:params:oauth:jwk-thumbprint:sha-256:_Fpfe27AuGmEljZE9s2lw2UH-qrZLRFNrWbJrWIe4SI")
106("verifiableCredential")
107("data:application/vc+ld+json;base64,eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiXSwidHlwZSI6WyJWZXJpZmlhYmxlQ3JlZGVudGlhbCJdLCJpc3N1ZXIiOiJkaWQ6andrOmV5SnJhV1FpT2lKMWNtNDZhV1YwWmpwd1lYSmhiWE02YjJGMWRHZzZhbmRyTFhSb2RXMWljSEpwYm5RNmMyaGhMVEkxTmpwdlFtUm1kbVpET1hoNk1GOUJVWFpSTjNZMU1YbERXbDl6ZUdwNU56VkNUSEpJZWsxT1Jqa3lPV1U0SWl3aWEzUjVJam9pVDB0UUlpd2lZM0oySWpvaVJXUXlOVFV4T1NJc0ltRnNaeUk2SWtWa1JGTkJJaXdpZUNJNklqTmljbU5zYjBJNGFEUk5XbFZJYms5UVVHbGtTbXd0U2pkdVVsRkpXSFJUYUZwM1oyNW1jbHAxVDI4aWZRIiwidmFsaWRGcm9tIjoiMjAyMy0wNi0wN1QyMToxNDoxNC4xNDhaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiaWQiOiJodHRwczovL3N1YmplY3QudmVuZG9yLmV4YW1wbGUifX0=")

87 --- 88
88 --- 89
87 --- 90
90 --- 91
91 --- 92
90 --- 93
93 --- 94
90 --- 95
95 --- 96
96 --- 97
87 --- 98
98 --- 99
87 --- 100
100 --- 101
87 --- 102
102 --- 103
87 --- 104
104 --- 105
87 --- 106
106 --- 107

---------------- Issuer Claims ----------------
"@context":
  - https://www.w3.org/ns/credentials/v2
!sd type:
  - VerifiablePresentation
holder: urn:ietf:params:oauth:jwk-thumbprint:sha-256:_Fpfe27AuGmEljZE9s2lw2UH-qrZLRFNrWbJrWIe4SI
verifiableCredential:
  - "@context":
      - https://www.w3.org/ns/credentials/v2
    !sd type:
      - VerifiableCredential
    issuer: https://issuer.example/issuers/68
    validFrom: 2023-06-07T21:14:14.148Z
    credentialSubject:
      !sd 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=
---------------- Holder Disclosure ----------------
id: True
type: True
holder:
  id: True
---------------- Decoded Protected Header ----------------
{
  "alg": "ES256",
  "typ": "vp+ld+json+sd-jwt",
  "cty": "vp+ld+json"
}
---------------- Decoded Protected Claimset ----------------
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2"
  ],
  "holder": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:_Fpfe27AuGmEljZE9s2lw2UH-qrZLRFNrWbJrWIe4SI",
  "verifiableCredential": [
    {
      "@context": [
        "https://www.w3.org/ns/credentials/v2"
      ],
      "issuer": "https://issuer.example/issuers/68",
      "validFrom": "2023-06-07T21:14:14.148Z",
      "credentialSubject": {}
    },
    "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="
  ],
  "iss": "did:web:issuer.example",
  "iat": 1696618914,
  "exp": 1728241314,
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "alg": "ES256",
      "x": "Yp8eCn2Oad0nlYpVejzKtnEZWlIGAH6KLcTXRiWip54",
      "y": "yCUaOcbgOiAl2RyccaxMTLA9DXwuYelgAx7xU0q-KfI"
    }
  },
  "type": [
    "VerifiablePresentation"
  ]
}
---------------- Compact Encoded Selective Disclosure JSON Web Token ----------------
eyJhbGciOiJFUzI1NiIsInR5cCI6InZwK2xkK2pzb24rc2Qtand0IiwiY3R5IjoidnArbGQranNvbiJ9.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiXSwiaG9sZGVyIjoidXJuOmlldGY6cGFyYW1zOm9hdXRoOmp3ay10aHVtYnByaW50OnNoYS0yNTY6X0ZwZmUyN0F1R21FbGpaRTlzMmx3MlVILXFyWkxSRk5yV2JKcldJZTRTSSIsInZlcmlmaWFibGVDcmVkZW50aWFsIjpbeyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6Ly9pc3N1ZXIuZXhhbXBsZS9pc3N1ZXJzLzY4IiwidmFsaWRGcm9tIjoiMjAyMy0wNi0wN1QyMToxNDoxNC4xNDhaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiX3NkIjpbIjRXT0h5eXg0ZzdDalFhejBSMHl1NnA0NURQNlIwRDhuczZyTExxanhBdTgiXX0sIl9zZCI6WyJpZW16RFBPbE9VYjhqblI4ZUNKX09QVkc2Q01XSWFFb1lDSmN6REljdXB3Il19LCJodHRwczovL3ZlbmRvci5leGFtcGxlL2NyZWRlbnRpYWxzLzQyIiwiZGlkOmV4YW1wbGU6MTIzIiwidXJuOnV1aWQ6MDFlYzk0MjYtYzE3NS00ZTM5LWEwMDYtZDMwMDUwZTI4MjE0IiwidXJuOmlldGY6cGFyYW1zOm9hdXRoOmp3ay10aHVtYnByaW50OnNoYS0yNTY6X0ZwZmUyN0F1R21FbGpaRTlzMmx3MlVILXFyWkxSRk5yV2JKcldJZTRTSSIsImRhdGE6YXBwbGljYXRpb24vdmMrbGQranNvbjtiYXNlNjQsZXlKQVkyOXVkR1Y0ZENJNld5Sm9kSFJ3Y3pvdkwzZDNkeTUzTXk1dmNtY3Zibk12WTNKbFpHVnVkR2xoYkhNdmRqSWlYU3dpZEhsd1pTSTZXeUpXWlhKcFptbGhZbXhsUTNKbFpHVnVkR2xoYkNKZExDSnBjM04xWlhJaU9pSmthV1E2YW5kck9tVjVTbkpoVjFGcFQybEtNV050TkRaaFYxWXdXbXB3ZDFsWVNtaGlXRTAyWWpKR01XUkhaelpoYm1SeVRGaFNiMlJYTVdsalNFcHdZbTVSTm1NeWFHaE1WRWt4VG1wd2RsRnRVbTFrYlZwRVQxaG9OazFHT1VKVldGcFNUak5aTVUxWWJFUlhiRGw2WlVkd05VNTZWa05VU0VwSlpXc3hUMUpxYTNsUFYxVTBTV2wzYVdFelVqVkphbTlwVkRCMFVVbHBkMmxaTTBveVNXcHZhVkpYVVhsT1ZGVjRUMU5KYzBsdFJuTmFlVWsyU1d0V2ExSkdUa0pKYVhkcFpVTkpOa2xxVG1samJVNXpZakJKTkdGRVVrNVhiRlpKWW1zNVVWVkhiR3RUYlhkMFUycGtkVlZzUmtwWFNGSlVZVVp3TTFveU5XMWpiSEF4VkRJNGFXWlJJaXdpZG1Gc2FXUkdjbTl0SWpvaU1qQXlNeTB3Tmkwd04xUXlNVG94TkRveE5DNHhORGhhSWl3aVkzSmxaR1Z1ZEdsaGJGTjFZbXBsWTNRaU9uc2lhV1FpT2lKb2RIUndjem92TDNOMVltcGxZM1F1ZG1WdVpHOXlMbVY0WVcxd2JHVWlmWDA9Il0sIl9zZCI6WyJKQ19nWmpEVEs0dWJ1bmxmajBoQ0VTRWYtSF9CYWJoc2FuU0NGZUtjd2o4Il0sIl9zZF9hbGciOiJzaGEtMjU2IiwiaXNzIjoiZGlkOndlYjppc3N1ZXIuZXhhbXBsZSIsImlhdCI6MTY5NjYxODkxNCwiZXhwIjoxNzI4MjQxMzE0LCJjbmYiOnsiandrIjp7Imt0eSI6IkVDIiwiY3J2IjoiUC0yNTYiLCJhbGciOiJFUzI1NiIsIngiOiJZcDhlQ24yT2FkMG5sWXBWZWp6S3RuRVpXbElHQUg2S0xjVFhSaVdpcDU0IiwieSI6InlDVWFPY2JnT2lBbDJSeWNjYXhNVExBOURYd3VZZWxnQXg3eFUwcS1LZkkifX19.Wmd5xy4MjdvQILB7wk2eW37cV-VjOkuKqU-OwaTT4Ym_DxuCjjADLAeD1Pfu7SO8qzpYNRFnJXZr_NoLQGTHYg~WyJzOHI5bmdSYWc4dGprNEFfREkycTdnIiwgInR5cGUiLCBbIlZlcmlmaWFibGVQcmVzZW50YXRpb24iXV0~eyJhbGciOiJFUzI1NiIsInR5cCI6ImtiK2p3dCJ9.eyJub25jZSI6IllhaDJyM1p6NENTTHFRSWVweVZlcmciLCJhdWQiOiJkaWQ6d2ViOnZlcmlmaWVyLmV4YW1wbGUiLCJpYXQiOjE2OTY2MTg5MTR9.XiqOPH8wPdQsoUmUPB8rrEegQJbxTV1bxjJ3RqZQWJc-roqFU0gt3sR0vvc1t4YiaMpmqZSet4219Uh1QuEFqg

Example 17: JSON-LD Verifiable Credential

data:application/vc+ld+json;base64,eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiXSwidHlwZSI6WyJWZXJpZmlhYmxlQ3JlZGVudGlhbCJdLCJpc3N1ZXIiOiJkaWQ6andrOmV5SnJhV1FpT2lKMWNtNDZhV1YwWmpwd1lYSmhiWE02YjJGMWRHZzZhbmRyTFhSb2RXMWljSEpwYm5RNmMyaGhMVEkxTmpwdlFtUm1kbVpET1hoNk1GOUJVWFpSTjNZMU1YbERXbDl6ZUdwNU56VkNUSEpJZWsxT1Jqa3lPV1U0SWl3aWEzUjVJam9pVDB0UUlpd2lZM0oySWpvaVJXUXlOVFV4T1NJc0ltRnNaeUk2SWtWa1JGTkJJaXdpZUNJNklqTmljbU5zYjBJNGFEUk5XbFZJYms5UVVHbGtTbXd0U2pkdVVsRkpXSFJUYUZwM1oyNW1jbHAxVDI4aWZRIiwidmFsaWRGcm9tIjoiMjAyMy0wNi0wN1QyMToxNDoxNC4xNDhaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiaWQiOiJodHRwczovL3N1YmplY3QudmVuZG9yLmV4YW1wbGUifX0=

Example 18: JSON-LD Verifiable Presentation

data:application/vp+ld+json+json;base64,eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiXSwidHlwZSI6WyJWZXJpZmlhYmxlQ3JlZGVudGlhbCJdLCJpc3N1ZXIiOiJkaWQ6andrOmV5SnJhV1FpT2lKMWNtNDZhV1YwWmpwd1lYSmhiWE02YjJGMWRHZzZhbmRyTFhSb2RXMWljSEpwYm5RNmMyaGhMVEkxTmpwdlFtUm1kbVpET1hoNk1GOUJVWFpSTjNZMU1YbERXbDl6ZUdwNU56VkNUSEpJZWsxT1Jqa3lPV1U0SWl3aWEzUjVJam9pVDB0UUlpd2lZM0oySWpvaVJXUXlOVFV4T1NJc0ltRnNaeUk2SWtWa1JGTkJJaXdpZUNJNklqTmljbU5zYjBJNGFEUk5XbFZJYms5UVVHbGtTbXd0U2pkdVVsRkpXSFJUYUZwM1oyNW1jbHAxVDI4aWZRIiwidmFsaWRGcm9tIjoiMjAyMy0wNi0wN1QyMToxNDoxNC4xNDhaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiaWQiOiJodHRwczovL3N1YmplY3QudmVuZG9yLmV4YW1wbGUifX0=

Issue

TODO add COSE Sign1 detached payload examples

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

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

Securing Verifiable Credentials using JOSE and COSE

Abstract

Status of This Document

1. Introduction

2. Terminology

3. Securing the VC Data Model

3.1 With JOSE

3.1.1 Securing JSON-LD Verifiable Credentials with JOSE

3.1.2 Securing JSON-LD Verifiable Presentations with JOSE

3.2 With COSE

3.2.1 Securing JSON-LD VCs with COSE

4. Wallets

5. Key Discovery

5.1 Registered Header Parameter and Claim Names

5.1.1 kid

5.1.2 iss

5.1.3 cnf

5.2 Well Known URIs

5.2.1 JWT Issuer

5.3 Controller Documents

5.3.1 Verification Methods

Verification Material

JsonWebKey

Referring to Verification Methods

5.3.2 Verification Relationships

Authentication

Assertion

6. JOSE Header Parameters

7. Conformance

7.1 Securing Verifiable Credentials

8. IANA Considerations

8.1 Media Types

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

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

8.2 Registered Claims

8.2.1 vc

8.2.2 vp

9. Other Considerations

9.1 Privacy Considerations

9.2 Security Considerations

9.3 Accessibility

9.4 Internationalization

10. Appendix

10.1 Controllers

10.2 Credentials

10.3 Presentations

10.4 Data URIs

10.5 Detached Payload

A. References

A.1 Normative references

A.2 Informative references

8.1.1 `application/vc+ld+json+sd-jwt`

8.1.2 `application/vp+ld+json+sd-jwt`

8.2.1 `vc`

8.2.2 `vp`