Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
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.
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.
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 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 unsecured documents conforming to [VC-DATA-MODEL] from the data types of secured documents conforming to [VC-DATA-MODEL], defined in this specification.
Selective Disclosure for JWTs (SD-JWT) [SD-JWT] provides a standardized mechanism for digitally signing JSON documents. It provides a means to ensure the integrity, authenticity, selective disclosure and non-repudiation of the information contained in a JSON document. These properties make SD-JWT especially well suited to securing documents conforming to the JSON-LD [VC-DATA-MODEL].
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.
This section is non-normative.
This section defines the terms used in this specification. A link to these terms is included whenever they appear in this specification.
id
property in a controller document.
Anything can be a subject: person, group, organization, physical thing, digital
thing, logical thing, etc.
A set of parameters that can be used together with a process to independently verify a proof. For example, a cryptographic public key can be used as a verification method with respect to a digital signature; in such usage, it verifies that the signer possessed the associated cryptographic private key.
"Verification" and "proof" in this definition are intended to apply broadly. For example, a cryptographic public key might be used during Diffie-Hellman key exchange to negotiate a shared symmetric key for encryption. This guarantees the integrity of the key agreement process. It is thus another type of verification method, even though descriptions of the process might not use the words "verification" or "proof."
An expression of the relationship between the subject and a verification method. An example of a verification relationship is authentication.
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.
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 the [VC-DATA-MODEL].
[rfc7515] MAY be used to secure this media type.
The typ
parameter SHOULD be vc+ld+json+sd-jwt
When present, the cty
SHOULD be
vc+ld+json
See Common JOSE Header
Parameters
for additional details regarding usage of typ
and
cty
.
{
"@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 the [VC-DATA-MODEL].
[rfc7515] MAY be used to secure this media type.
The typ
parameter SHOULD be
vp+ld+json+sd-jwt
When present, the cty
parameter SHOULD be
vp+ld+json
See Common JOSE Header
Parameters
for additional details regarding usage of typ
and
cty
.
{
"@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.
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.
When using this approach, the typ
SHOULD be
vc+ld+json+cose
.
See I-D.ietf-cose-typ-header-parameter
for the COSE "typ
" (type) header parameter.
When using this approach, the content type (3)
SHOULD be application/vc+ld+json
.
See Common COSE Header Parameters for additional details.
See the IANA Concise Binary Object Representation (CBOR) Tags registry for additional details.
This section is non-normative.
Issuers, holders and verifiers might rely on clients, as defined in RFC4949. Such clients are often referred to as wallets or digital credential wallets, when they support storing and presenting digital credentials.
In order to meet verifier requirements, some issuers might need to assess the quality of a wallet used by a holder, prior to issuing and delivering credentials to a holder.
For example, some verifiers might require that cryptographic material associated with a holder, be protected at specific assurance levels. (See NIST 800-63-3: Authenticator Assurance Levels.)
Also see OAuth 2.0 Attestation-Based Client Authentication .
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.
{
"issuer": "did:example:123"
// ...
}
{
"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.
{
"holder": "did:example:abc"
// ...
}
{
"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.
{
"issuer": {
"id": "https://university.example/issuers/565049"
}
// ...
}
{
"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.
{
"holder": {
"id": "https://university.example/issuers/565049"
}
// ...
}
{
"alg": "ES384",
"kid": "https://university.example/issuers/565049#key-123
}
When iss is a present, and is a [URL], the kid MUST match a key discovered via JWT Issuer Metadata Request
This normative statement depends on a -00 IETF OAUTH WG Adopted draft. This feature is at risk and will be removed from the specification if at least two independent, interoperable implementations are not demonstrated.
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.
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.
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.
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:
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.
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.
The value of the id
property for a verification
method MUST be a string that
conforms to the [URL] syntax.
type
property MUST be a string that references exactly one verification
method type. To maximize interoperability, the
verification method type SHOULD be JsonWebKey
.
controller
property MUST be a string that conforms to the [URL] syntax.
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.
{ "@context": [ "https://www.w3.org/ns/did/v1", "https://www.w3.org/ns/credentials/v2" ] "id": "did:example:123456789abcdefghi", ... "verificationMethod": [{ "id": ..., "type": ..., "controller": ..., "publicKeyJwk": ... }] }
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.
{ "@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
property MUST contain the string JsonWebKey
.
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 12 for an example of a
public key with a compound key identifier.
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:
{ "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.
{ "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.
{ ... "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
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.
{ "@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
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.
{ "@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", ... }
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 JOSE 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 JWT Claims Set to Header Parameters, it is
RECOMMENDED to use [RFC7519],
the IANA JSON Web Token Claims registry, and
the IANA JSON Web Signature and Encryption Header Parameters registry
to identify any claims that might be confused with
members defined by the [[VC-DATA-MODEL]. 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
that represent the validity of the data that is being secured.
The JWT 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 the corresponding definitions found in the IANA JSON Web Signature and Encryption Header Parameters registry and the IANA JSON Web Token Claims registry.
Additional members may be present. If they are not understood, they MUST be ignored.
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 v1.1 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 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 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 Presenatations 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.
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 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".
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?
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 |
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:
Minimization of data: It is considered best practice for Verifiable Credentials to only contain the minimum amount of data necessary to achieve their intended purpose. This helps to limit the amount of sensitive information that is shared or stored unnecessarily.
Informed consent: It is considered best practice that individuals be fully informed about how their data will be used and provide the ability to consent to or decline the use of their data. This helps to ensure that individuals maintain control over their own personal information.
Data protection: It is considered best practice to protect Verifiable Credentials using strong encryption and other security measures to prevent unauthorized access, modification, or disclosure.
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.
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.
This section is non-normative.
When implementing this specification, it is crucial for technical implementers to consider various accessibility factors. Ignoring accessibility concerns renders the information unusable for a significant portion of the population. To ensure equal access for all individuals, regardless of their abilities, it is vital to adhere to accessibility guidelines and standards, such as the Web Content Accessibility Guidelines (WCAG 2.1) [WCAG21]. This becomes even more critical when establishing systems that involve cryptography, as they have historically posed challenges for assistive technologies.
Implementers are advised to note and abide by all accessibility considerations called out in the [VC-DATA-MODEL].
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
This section is non-normative.
{
"id": "https://vendor.example",
}
{
"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-"
}
}]
}
{
"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"]
}
{
"@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"]
}
{
"@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"
}]
}
{
"@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"
}
}
{
"@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"
]
}
data:application/vc+ld+json+sd-jwt;eyJhbGciOiJFUzM4NCIsImtpZCI6IlNJM1JITm91aDhvODFOT09OUFFVQUw3RWdaLWtJNl94ajlvUkV2WDF4T3ciLCJ0eXAiOiJ2YytsZCtqc29uK3NkLWp3dCIsImN0eSI6InZjK2xkK2pzb24ifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTY2hlbWEiOnsiX3NkIjpbIkU3dU1sSWFyS29iYXJTdEZGRjctZm5qaV9sQVdnM3BGMkV5dVc4dWFYakUiLCJYelRaSVgyNGdDSWxSQVFHclFoNU5FRm1XWkQtZ3Z3dkIybzB5Y0FwNFZzIl19LCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsibmFtZSI6IkJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMiLCJfc2QiOlsiT3oxUEZIMG0tWk9TdEhwUVZyeGlmVlpKRzhvNmlQQmNnLVZ2SXQwd2plcyJdfSwiX3NkIjpbIkVZQ1daMTZZMHB5X1VNNzRHU3NVYU9zT19mdDExTlVSaFFUTS1TT1lFTVEiXX0sIl9zZCI6WyJqT055NnZUbGNvVlAzM25oSTdERGN3ekVka3d2R3VVRXlLUjdrWEVLd3VVIiwid21BdHpwc0dRbDJveS1PY2JrSEVZcE8xb3BoX3VYcWVWVTRKekF0aFFibyJdLCJfc2RfYWxnIjoic2hhLTI1NiIsImlzcyI6Imh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL2lzc3VlcnMvNTY1MDQ5IiwiaWF0IjoxNjk3Mjg5OTk2LCJleHAiOjE3Mjg5MTIzOTYsImNuZiI6eyJqd2siOnsia3R5IjoiRUMiLCJjcnYiOiJQLTM4NCIsImFsZyI6IkVTMzg0IiwieCI6InZFdV84WGxZT0ZFU2hTcVRpZ2JSYWduZ0ZGM1p5U0xrclNHekh3azFBT1loanhlazVhV21HY2UwZU05S0pWOEIiLCJ5IjoiRUpNY2czWXBzUTB3M2RLNHlVa25QczE1Z0lsY2Yyay03dzFKLTNlYlBiOERENmQtUkhBeGUwMDkzSWpfdTRCOSJ9fX0.rYzbxb6j1dwop8_s491iArVVJNm6A6C3b742gOm_qYO3zdkyQU4_VxxOSJ8ECcmWj2r5KyiCNC1ojfO4Yms-zBsjt7PoMYpYWBplsqXpiIvnehmM7D0eOLi40uHXki0X~WyJSWTg1YTZNMmEwX3VDWlFTVGZmTFdRIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMTg3MiJd~WyJMeG5GYTBXVm8wRUluVy1QdS1fd1dRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl1d~WyJUQVdrakpCaVpxdC1rVU54X1EweUJBIiwgImlkIiwgImh0dHBzOi8vZXhhbXBsZS5vcmcvZXhhbXBsZXMvZGVncmVlLmpzb24iXQ~WyJTd2xuZFpPZzZEZ1ZERFp5X0RvYVFBIiwgInR5cGUiLCAiSnNvblNjaGVtYSJd~WyJuSnJlU3E1Nzg3RGZMSDJCbU03cXFRIiwgImlkIiwgImRpZDpleGFtcGxlOjEyMyJd~WyIxMjNNd3hNcHRiek02YUk2aW03ME1RIiwgInR5cGUiLCAiQmFjaGVsb3JEZWdyZWUiXQ
data:application/vp+ld+json+sd-jwt;eyJhbGciOiJFUzM4NCIsImtpZCI6IlNJM1JITm91aDhvODFOT09OUFFVQUw3RWdaLWtJNl94ajlvUkV2WDF4T3ciLCJ0eXAiOiJ2YytsZCtqc29uK3NkLWp3dCIsImN0eSI6InZjK2xkK2pzb24ifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTY2hlbWEiOnsiX3NkIjpbIkU3dU1sSWFyS29iYXJTdEZGRjctZm5qaV9sQVdnM3BGMkV5dVc4dWFYakUiLCJYelRaSVgyNGdDSWxSQVFHclFoNU5FRm1XWkQtZ3Z3dkIybzB5Y0FwNFZzIl19LCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsibmFtZSI6IkJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMiLCJfc2QiOlsiT3oxUEZIMG0tWk9TdEhwUVZyeGlmVlpKRzhvNmlQQmNnLVZ2SXQwd2plcyJdfSwiX3NkIjpbIkVZQ1daMTZZMHB5X1VNNzRHU3NVYU9zT19mdDExTlVSaFFUTS1TT1lFTVEiXX0sIl9zZCI6WyJqT055NnZUbGNvVlAzM25oSTdERGN3ekVka3d2R3VVRXlLUjdrWEVLd3VVIiwid21BdHpwc0dRbDJveS1PY2JrSEVZcE8xb3BoX3VYcWVWVTRKekF0aFFibyJdLCJfc2RfYWxnIjoic2hhLTI1NiIsImlzcyI6Imh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL2lzc3VlcnMvNTY1MDQ5IiwiaWF0IjoxNjk3Mjg5OTk2LCJleHAiOjE3Mjg5MTIzOTYsImNuZiI6eyJqd2siOnsia3R5IjoiRUMiLCJjcnYiOiJQLTM4NCIsImFsZyI6IkVTMzg0IiwieCI6InZFdV84WGxZT0ZFU2hTcVRpZ2JSYWduZ0ZGM1p5U0xrclNHekh3azFBT1loanhlazVhV21HY2UwZU05S0pWOEIiLCJ5IjoiRUpNY2czWXBzUTB3M2RLNHlVa25QczE1Z0lsY2Yyay03dzFKLTNlYlBiOERENmQtUkhBeGUwMDkzSWpfdTRCOSJ9fX0.rYzbxb6j1dwop8_s491iArVVJNm6A6C3b742gOm_qYO3zdkyQU4_VxxOSJ8ECcmWj2r5KyiCNC1ojfO4Yms-zBsjt7PoMYpYWBplsqXpiIvnehmM7D0eOLi40uHXki0X~WyJTd2xuZFpPZzZEZ1ZERFp5X0RvYVFBIiwgInR5cGUiLCAiSnNvblNjaGVtYSJd~WyIxMjNNd3hNcHRiek02YUk2aW03ME1RIiwgInR5cGUiLCAiQmFjaGVsb3JEZWdyZWUiXQ~WyJMeG5GYTBXVm8wRUluVy1QdS1fd1dRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl1d~WyJSWTg1YTZNMmEwX3VDWlFTVGZmTFdRIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMTg3MiJd~eyJhbGciOiJFUzM4NCIsInR5cCI6ImtiK2p3dCJ9.eyJub25jZSI6IkVmeTROTFJPX3ZvSkszdDIzcUNfQlEiLCJhdWQiOiJodHRwczovL3ZlcmlmaWVyLmV4YW1wbGUiLCJpYXQiOjE2OTcyODk5OTZ9.6G-1nVcrDKFzR6BdbcFHcbtassEb8NZ7ZavTYz3SJ-e4pXleXs0tNcCkUCwMI70gsuOY0AXzeDPbHjp5GKyLDVuNWgWCt3Wo2VSaCwUkyfLyvhkCsmkF9kvFhMIOhp1i
TODO add COSE Sign1 detached payload examples
Referenced in:
Referenced in:
Referenced in:
Referenced in: