Securing Verifiable Credentials using JOSE and COSE

Abstract

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

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

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

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

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

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

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

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

[RFC7515] MAY be used to secure this media type. The typ header parameter SHOULD be vc+ld+json+sd-jwt. When present, the cty header parameter SHOULD be vc+ld+json. See Registered Header Parameter Names for additional details regarding usage of typ and cty.

Example 1: A simple example of a verifiable credential

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

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

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

[RFC7515] MAY be used to secure this media type. The typ header parameter SHOULD be vp+ld+json+sd-jwt. When present, the cty header parameter SHOULD be vp+ld+json. See Registered Header Parameter Names for additional details regarding usage of typ and cty.

Example 2: A simple example of a verifiable presentation

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": "VerifiablePresentation",
  "verifiableCredential": [{
    "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://www.w3.org/ns/credentials/examples/v2"
    ],
    "id": "http://university.example/credentials/1872",
    "type": ["VerifiableCredential", "ExampleAlumniCredential"],
    "issuer": "https://university.example/issuers/565049",
    "validFrom": "2010-01-01T19:23:24Z",
    "credentialSubject": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "alumniOf": {
        "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
        "name": "Example University"
      }
    }
  }]
}

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

To improve interoperability, implementations SHOULD support the compact serialization (application/sd-jwt), and MAY support the JSON serialization (application/sd-jwt+json). If the JSON serialization is used, it is RECOMMENDED that a profile be defined, to ensure any addition JSON members are understood consistently.

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

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

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

[RFC9052] MAY be used to secure this media type. The typ header parameter SHOULD be application/vp+ld+json+sd-jwt. When present, the cty header parameter SHOULD be application/vp+ld+json. See Common COSE Header Parameters for additional details.

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

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

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

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

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

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

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

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

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

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

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

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

Issue 160: Controller Documents vs DID Documents post-CR

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

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

Example 3: An issuer identified by a DID

{
  "issuer": "did:example:123"
  // ...
}

Example 4: An absolute DID URL as a kid

{
  "alg": "ES384",
  "kid": "did:example:123#key-456
}

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

Example 5: A holder identified by a DID

{
  "holder": "did:example:abc"
  // ...
}

Example 6: A kid as an absolute DID URL

{
  "alg": "ES384",
  "kid": "did:example:abc#key-456
}

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

Example 7: An issuer identified by a controller document identifier

{
  "issuer": {
    "id": "https://university.example/issuers/565049"
  }
  // ...
}

Example 8: A kid as a controller document verification method identifier

{
  "alg": "ES384",
  "kid": "https://university.example/issuers/565049#key-123
}

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

Example 9: A holder identified by a controller document identifier

{
  "holder": {
    "id": "https://university.example/issuers/565049"
  }
  // ...
}

Example 10: A kid as a controller document verification method identifier

{
  "alg": "ES384",
  "kid": "https://university.example/issuers/565049#key-123
}

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

Issue 160: (AT RISK) Feature depends on demonstration of independent implementations post-CR

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

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

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

These JOSE header parameters and JWT claims can be used by verifiers to 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 used to distinguish the specific key used.

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

Issue 160: Controller Documents vs DID Documents post-CR

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

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

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 5.3.1.1 Verification Material. A verification method MAY include additional properties.

id: The value of the id property for a verification method MUST be a string that conforms to the [URL] syntax.
type: The value of the type property MUST be a string that references exactly one verification method type. To maximize interoperability, the verification method type SHOULD be JsonWebKey.
controller: The value of the controller property MUST be a string that conforms to the [URL] syntax.
revoked: The revoked property is OPTIONAL. If present, its value MUST be an [XMLSCHEMA11-2] combined date and time string specifying when the verification method SHOULD cease to be used. Once the value is set, it is not expected to be updated, and systems depending on the value are expected to not verify any proofs associated with the verification method at or after the time of revocation.

Example 11: 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 MUST be expressed in the publicKeyJwk property of a JsonWebKey or as a COSE_Key. 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 another representtion is prohibited.

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

Example 12: Verification method 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) is a specific type of verification method that uses the JWK specification [RFC7517] to encode key types into a set of parameters.

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

type: The value of the type property MUST contain the string JsonWebKey.
publicKeyJwk: The publicKeyJwk property is REQUIRED, and its value MUST be a JSON Web Key that conforms to [RFC7517]. It is RECOMMENDED that verification methods that use JWKs [RFC7517] to represent their public keys use the value of kid as their fragment identifier. It is RECOMMENDED that JWK kid values be set to the public key fingerprint [RFC7638]. See the first key in the example below for an instance of a public key with a compound key identifier.
secretKeyJwk: The secretKeyJwk property is OPTIONAL. If present, its value MUST be a map representing a JSON Web Key that conforms to [RFC7517]. It MUST NOT be used if the data structure containing it is public or may be revealed to parties other than the legitimate holders of the secret key.

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

Example 13: JSON Web Key encoding of a secp384r1 (P-384) public key

{
  "id": "did:example:123456789abcdefghi#key-1",
  "type": "JsonWebKey",
  "controller": "did:example:123456789abcdefghi",
  "publicKeyJwk": {
      "kid": "key-1",
      "kty": "EC",
      "crv": "P-384",
      "alg": "ES384",
      "x": "1F14JSzKbwxO-Heqew5HzEt-0NZXAjCu8w-RiuV8_9tMiXrSZdjsWqi4y86OFb5d",
      "y": "dnd8yoq-NOJcBuEYgdVVMmSxonXg-DU90d7C4uPWb_Lkd4WIQQEH0DyeC2KUDMIU"
    }
}

In the example above, the publicKeyJwk value contains the JSON Web Key. The kty property encodes the key type of "OKP", which means "Octet string key pairs". The alg property identifies the algorithm intended for use with the public key. Although optional, it is RECOMMENDED that alg 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" or "Secret" in any registry contained in the JOSE Registries [JOSE-REGISTRIES], including "d".

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

Example 14: 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 15: 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. To maximize global interoperability, any such properties used SHOULD be registered in the VC Specifications Directory.

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

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

The key words MAY, MUST, MUST NOT, OPTIONAL, RECOMMENDED, REQUIRED, and SHOULD in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

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

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

For clarity, these requirements are repeated here:

At least one securing mechanism, and the details necessary to evaluate it, MUST be expressed for a credential or presentation to be a verifiable credential or verifiable presentation; that is, to be verifiable.
Methods of securing credentials or presentations that embed a proof in the data model MUST use the proof property.
Methods of securing credentials or presentations that use an external proof MAY use the proof property.
One or more cryptographic proofs that can be used to detect tampering and verify the authorship of a credential or presentation. The specific method used for an embedded proof MUST be included using the type property.

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 [VC-DATA-MODEL-2.0] with JSON Web Tokens. When content types from [VC-DATA-MODEL-2.0] are secured using JSON Web Tokens, the header parameter "alg": "none", MUST be used to communicate that a JWT Claims Set (a Verifiable Credential or a Verifiable Presentation) has no integrity protection. When a JWT Claims Set (a Verifiable Credential or a Verifiable Presentation) contains proof, and the JSON Web Token header contains "alg": "none", the JWT Claims Set MUST be considered to have no integrity protection.

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

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

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

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

Type name:	`application`
Subtype name:	`vc+ld+json+sd-jwt`
Required parameters:	None
Encoding considerations:	binary; `application/sd-jwt` values are a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') or tilde ('~') characters.
Security considerations:	As defined in this specification. See also the security considerations in Selective Disclosure for JWTs (SD-JWT).
Contact:	W3C Verifiable Credentials Working Group public-vc-wg@w3.org

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

Type name:	application
Subtype name:	vp+ld+json+sd-jwt
Required parameters:	None
Encoding considerations:	binary; `application/sd-jwt` values are a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') or tilde ('~') characters.
Security considerations:	As defined in this specification. See also the security considerations in Selective Disclosure for JWTs (SD-JWT).
Contact:	W3C Verifiable Credentials Working Group public-vc-wg@w3.org

This section is non-normative.

Example 18: A minimal controller document

{
  "id": "https://vendor.example",
}

Example 19: A controller document with verification method

{
  "id": "https://university.example/issuers/565049",
  "verificationMethod": [{
    "id": "https://university.example/issuers/565049#key-123",
    "type": "JsonWebKey",
    "controller": "https://university.example/issuers/565049",
    "publicKeyJwk": {
      "kty": "EC",
      "crv": "P-384",
      "alg": "ES384",
      "x": "PxgAmVYOQvSNcMYL2tOzoLwSWn4Ta3tIMPEUKR8pxeb-gmR11-DyKHBoIiY-2LhM",
      "y": "BZEBTkImVdpwvxR9THIRw16eblnj5-tZa7m-ww5uVd4kyPJNRoWUn2aT9ZuarAe-"
    }
  }]
}

Example 20: A controller document with verification relationships

{
  "id": "https://university.example/issuers/565049",
  "verificationMethod": [{
    "id": "https://university.example/issuers/565049#key-123",
    "type": "JsonWebKey",
    "controller": "https://university.example/issuers/565049",
    "publicKeyJwk": {
      "kty": "EC",
      "crv": "P-384",
      "alg": "ES384",
      "x": "PxgAmVYOQvSNcMYL2tOzoLwSWn4Ta3tIMPEUKR8pxeb-gmR11-DyKHBoIiY-2LhM",
      "y": "BZEBTkImVdpwvxR9THIRw16eblnj5-tZa7m-ww5uVd4kyPJNRoWUn2aT9ZuarAe-"
    }
  }],
  "authentication": ["https://university.example/issuers/565049#key-123"],
  "assertionMethod": ["https://university.example/issuers/565049#key-123"]
}

Example 21: 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 22: A revocable credential with multiple 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"
  }]
}

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

Example 24: Presentation

{
  "@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+sd-jwt;eyJhbGciOiJFUzM4NCIsImtpZCI6IlNJM1JITm91aDhvODFOT09OUFFVQUw3RWdaLWtJNl94ajlvUkV2WDF4T3ciLCJ0eXAiOiJ2YytsZCtqc29uK3NkLWp3dCIsImN0eSI6InZjK2xkK2pzb24ifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTY2hlbWEiOnsiX3NkIjpbIkU3dU1sSWFyS29iYXJTdEZGRjctZm5qaV9sQVdnM3BGMkV5dVc4dWFYakUiLCJYelRaSVgyNGdDSWxSQVFHclFoNU5FRm1XWkQtZ3Z3dkIybzB5Y0FwNFZzIl19LCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsibmFtZSI6IkJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMiLCJfc2QiOlsiT3oxUEZIMG0tWk9TdEhwUVZyeGlmVlpKRzhvNmlQQmNnLVZ2SXQwd2plcyJdfSwiX3NkIjpbIkVZQ1daMTZZMHB5X1VNNzRHU3NVYU9zT19mdDExTlVSaFFUTS1TT1lFTVEiXX0sIl9zZCI6WyJqT055NnZUbGNvVlAzM25oSTdERGN3ekVka3d2R3VVRXlLUjdrWEVLd3VVIiwid21BdHpwc0dRbDJveS1PY2JrSEVZcE8xb3BoX3VYcWVWVTRKekF0aFFibyJdLCJfc2RfYWxnIjoic2hhLTI1NiIsImlzcyI6Imh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL2lzc3VlcnMvNTY1MDQ5IiwiaWF0IjoxNjk3Mjg5OTk2LCJleHAiOjE3Mjg5MTIzOTYsImNuZiI6eyJqd2siOnsia3R5IjoiRUMiLCJjcnYiOiJQLTM4NCIsImFsZyI6IkVTMzg0IiwieCI6InZFdV84WGxZT0ZFU2hTcVRpZ2JSYWduZ0ZGM1p5U0xrclNHekh3azFBT1loanhlazVhV21HY2UwZU05S0pWOEIiLCJ5IjoiRUpNY2czWXBzUTB3M2RLNHlVa25QczE1Z0lsY2Yyay03dzFKLTNlYlBiOERENmQtUkhBeGUwMDkzSWpfdTRCOSJ9fX0.rYzbxb6j1dwop8_s491iArVVJNm6A6C3b742gOm_qYO3zdkyQU4_VxxOSJ8ECcmWj2r5KyiCNC1ojfO4Yms-zBsjt7PoMYpYWBplsqXpiIvnehmM7D0eOLi40uHXki0X~WyJSWTg1YTZNMmEwX3VDWlFTVGZmTFdRIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMTg3MiJd~WyJMeG5GYTBXVm8wRUluVy1QdS1fd1dRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl1d~WyJUQVdrakpCaVpxdC1rVU54X1EweUJBIiwgImlkIiwgImh0dHBzOi8vZXhhbXBsZS5vcmcvZXhhbXBsZXMvZGVncmVlLmpzb24iXQ~WyJTd2xuZFpPZzZEZ1ZERFp5X0RvYVFBIiwgInR5cGUiLCAiSnNvblNjaGVtYSJd~WyJuSnJlU3E1Nzg3RGZMSDJCbU03cXFRIiwgImlkIiwgImRpZDpleGFtcGxlOjEyMyJd~WyIxMjNNd3hNcHRiek02YUk2aW03ME1RIiwgInR5cGUiLCAiQmFjaGVsb3JEZWdyZWUiXQ"
  ]
}

Example 25: A simple URI-encoded Verifiable Credential

data:application/vc+ld+json+sd-jwt;eyJhbGciOiJFUzM4NCIsImtpZCI6IlNJM1JITm91aDhvODFOT09OUFFVQUw3RWdaLWtJNl94ajlvUkV2WDF4T3ciLCJ0eXAiOiJ2YytsZCtqc29uK3NkLWp3dCIsImN0eSI6InZjK2xkK2pzb24ifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTY2hlbWEiOnsiX3NkIjpbIkU3dU1sSWFyS29iYXJTdEZGRjctZm5qaV9sQVdnM3BGMkV5dVc4dWFYakUiLCJYelRaSVgyNGdDSWxSQVFHclFoNU5FRm1XWkQtZ3Z3dkIybzB5Y0FwNFZzIl19LCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsibmFtZSI6IkJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMiLCJfc2QiOlsiT3oxUEZIMG0tWk9TdEhwUVZyeGlmVlpKRzhvNmlQQmNnLVZ2SXQwd2plcyJdfSwiX3NkIjpbIkVZQ1daMTZZMHB5X1VNNzRHU3NVYU9zT19mdDExTlVSaFFUTS1TT1lFTVEiXX0sIl9zZCI6WyJqT055NnZUbGNvVlAzM25oSTdERGN3ekVka3d2R3VVRXlLUjdrWEVLd3VVIiwid21BdHpwc0dRbDJveS1PY2JrSEVZcE8xb3BoX3VYcWVWVTRKekF0aFFibyJdLCJfc2RfYWxnIjoic2hhLTI1NiIsImlzcyI6Imh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL2lzc3VlcnMvNTY1MDQ5IiwiaWF0IjoxNjk3Mjg5OTk2LCJleHAiOjE3Mjg5MTIzOTYsImNuZiI6eyJqd2siOnsia3R5IjoiRUMiLCJjcnYiOiJQLTM4NCIsImFsZyI6IkVTMzg0IiwieCI6InZFdV84WGxZT0ZFU2hTcVRpZ2JSYWduZ0ZGM1p5U0xrclNHekh3azFBT1loanhlazVhV21HY2UwZU05S0pWOEIiLCJ5IjoiRUpNY2czWXBzUTB3M2RLNHlVa25QczE1Z0lsY2Yyay03dzFKLTNlYlBiOERENmQtUkhBeGUwMDkzSWpfdTRCOSJ9fX0.rYzbxb6j1dwop8_s491iArVVJNm6A6C3b742gOm_qYO3zdkyQU4_VxxOSJ8ECcmWj2r5KyiCNC1ojfO4Yms-zBsjt7PoMYpYWBplsqXpiIvnehmM7D0eOLi40uHXki0X~WyJSWTg1YTZNMmEwX3VDWlFTVGZmTFdRIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMTg3MiJd~WyJMeG5GYTBXVm8wRUluVy1QdS1fd1dRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl1d~WyJUQVdrakpCaVpxdC1rVU54X1EweUJBIiwgImlkIiwgImh0dHBzOi8vZXhhbXBsZS5vcmcvZXhhbXBsZXMvZGVncmVlLmpzb24iXQ~WyJTd2xuZFpPZzZEZ1ZERFp5X0RvYVFBIiwgInR5cGUiLCAiSnNvblNjaGVtYSJd~WyJuSnJlU3E1Nzg3RGZMSDJCbU03cXFRIiwgImlkIiwgImRpZDpleGFtcGxlOjEyMyJd~WyIxMjNNd3hNcHRiek02YUk2aW03ME1RIiwgInR5cGUiLCAiQmFjaGVsb3JEZWdyZWUiXQ

Example 26: A simple URI-encoded Verifiable Presentation

data:application/vp+ld+json+sd-jwt;eyJhbGciOiJFUzM4NCIsImtpZCI6IlNJM1JITm91aDhvODFOT09OUFFVQUw3RWdaLWtJNl94ajlvUkV2WDF4T3ciLCJ0eXAiOiJ2YytsZCtqc29uK3NkLWp3dCIsImN0eSI6InZjK2xkK2pzb24ifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTY2hlbWEiOnsiX3NkIjpbIkU3dU1sSWFyS29iYXJTdEZGRjctZm5qaV9sQVdnM3BGMkV5dVc4dWFYakUiLCJYelRaSVgyNGdDSWxSQVFHclFoNU5FRm1XWkQtZ3Z3dkIybzB5Y0FwNFZzIl19LCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsibmFtZSI6IkJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMiLCJfc2QiOlsiT3oxUEZIMG0tWk9TdEhwUVZyeGlmVlpKRzhvNmlQQmNnLVZ2SXQwd2plcyJdfSwiX3NkIjpbIkVZQ1daMTZZMHB5X1VNNzRHU3NVYU9zT19mdDExTlVSaFFUTS1TT1lFTVEiXX0sIl9zZCI6WyJqT055NnZUbGNvVlAzM25oSTdERGN3ekVka3d2R3VVRXlLUjdrWEVLd3VVIiwid21BdHpwc0dRbDJveS1PY2JrSEVZcE8xb3BoX3VYcWVWVTRKekF0aFFibyJdLCJfc2RfYWxnIjoic2hhLTI1NiIsImlzcyI6Imh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL2lzc3VlcnMvNTY1MDQ5IiwiaWF0IjoxNjk3Mjg5OTk2LCJleHAiOjE3Mjg5MTIzOTYsImNuZiI6eyJqd2siOnsia3R5IjoiRUMiLCJjcnYiOiJQLTM4NCIsImFsZyI6IkVTMzg0IiwieCI6InZFdV84WGxZT0ZFU2hTcVRpZ2JSYWduZ0ZGM1p5U0xrclNHekh3azFBT1loanhlazVhV21HY2UwZU05S0pWOEIiLCJ5IjoiRUpNY2czWXBzUTB3M2RLNHlVa25QczE1Z0lsY2Yyay03dzFKLTNlYlBiOERENmQtUkhBeGUwMDkzSWpfdTRCOSJ9fX0.rYzbxb6j1dwop8_s491iArVVJNm6A6C3b742gOm_qYO3zdkyQU4_VxxOSJ8ECcmWj2r5KyiCNC1ojfO4Yms-zBsjt7PoMYpYWBplsqXpiIvnehmM7D0eOLi40uHXki0X~WyJTd2xuZFpPZzZEZ1ZERFp5X0RvYVFBIiwgInR5cGUiLCAiSnNvblNjaGVtYSJd~WyIxMjNNd3hNcHRiek02YUk2aW03ME1RIiwgInR5cGUiLCAiQmFjaGVsb3JEZWdyZWUiXQ~WyJMeG5GYTBXVm8wRUluVy1QdS1fd1dRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl1d~WyJSWTg1YTZNMmEwX3VDWlFTVGZmTFdRIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMTg3MiJd~eyJhbGciOiJFUzM4NCIsInR5cCI6ImtiK2p3dCJ9.eyJub25jZSI6IkVmeTROTFJPX3ZvSkszdDIzcUNfQlEiLCJhdWQiOiJodHRwczovL3ZlcmlmaWVyLmV4YW1wbGUiLCJpYXQiOjE2OTcyODk5OTZ9.6G-1nVcrDKFzR6BdbcFHcbtassEb8NZ7ZavTYz3SJ-e4pXleXs0tNcCkUCwMI70gsuOY0AXzeDPbHjp5GKyLDVuNWgWCt3Wo2VSaCwUkyfLyvhkCsmkF9kvFhMIOhp1i

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

Example 27: A COSE Sign 1 Protected Header for a Verifiable Credential

{                                   / Protected                     /
  1: -35,                           / Algorithm                     /
  3: application/vc+ld+json,        / Content type                  /
  4: h'177f12cb...1933d554',        / Key identifier                /
  15: {                             / CWT Claims                    /
    1: urn:example:123,             / Issuer                        /
    2: urn:example:456,             / Subject                       /
  },
}

Example 28: A COSE Sign 1 Protected Header for a Verifiable Presentation

{                                   / Protected                     /
  1: -35,                           / Algorithm                     /
  3: application/vp+ld+json,        / Content type                  /
  4: h'177f12cb...1933d554',        / Key identifier                /
  15: {                             / CWT Claims                    /
    1: urn:example:123,             / Issuer                        /
    2: urn:example:456,             / Subject                       /
  },
}

Example 29: A COSE Sign 1 with an attached payload

18(                                 / COSE Sign 1                   /
    [
      h'a4013822...3a343536',       / Protected Header              /
      {}                            / Unprotected Header            /
      h'0fbe22a0...3a009118',       / Attached payload              /
      h'09772c7f...5c4e736f'        / Signature                     /
    ]
)

Example 30: A COSE Sign 1 with a detached payload

18(                                 / COSE Sign 1                   /
    [
      h'a4013822...3a343536',       / Protected Header              /
      {}                            / Unprotected Header            /
      nil,                          / Detached payload              /
      h'09772c7f...5c4e736f'        / Signature                     /
    ]
)

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

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 Verifiable Credentials with COSE

3.2.2 Securing JSON-LD Verifiable Presentations with COSE

3.3 JOSE Header Parameters and JWT Claims

4. COSE Header Parameters and CWT Claims

5. Key Discovery

5.1 Using Header Parameters and Claims for Key Discovery

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

5.3.1.1 Verification Material

5.3.1.2 JsonWebKey

5.3.1.3 Referring to Verification Methods

5.3.2 Verification Relationships

5.3.2.1 Authentication

5.3.2.2 Assertion

6. Conformance

6.1 Securing Verifiable Credentials

7. Wallets

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

9. Other Considerations

9.1 Privacy Considerations

9.2 Security Considerations

9.3 Accessibility

10. Appendix

10.1 Controllers

10.2 Credentials

10.3 Presentations

10.4 Data URIs

10.5 COSE Examples

11. Verification Algorithm

12. Validation Algorithm

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`