W3C Candidate Recommendation Draft
Copyright © 2024 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 Verifiable Credential data model [VC-DATA-MODEL-2.0] with JSON Object Signing and Encryption (JOSE), Selective Disclosure for JWTs [SD-JWT], and CBOR Object Signing and Encryption (COSE) [RFC9052]. This enables the Verifiable Credential data model [VC-DATA-MODEL-2.0] to be implemented with standards for signing and encryption that are widely adopted.
This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.
The Working Group is actively seeking implementation feedback for this specification. In order to exit the Candidate Recommendation phase, the Working Group has set the requirement of at least two independent implementations for each mandatory feature in the specification. For details on the conformance testing process, see the test suite listed in the implementation report.
This document was published by the Verifiable Credentials Working Group as a Candidate Recommendation Draft using the Recommendation track.
Publication as a Candidate Recommendation does not imply endorsement by W3C and its Members. A Candidate Recommendation Draft integrates changes from the previous Candidate Recommendation that the Working Group intends to include in a subsequent Candidate Recommendation Snapshot.
This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 03 November 2023 W3C Process Document.
This specification defines how to secure media types expressing Verifiable Credentials and Verifiable Presentations as described in [VC-DATA-MODEL-2.0] using approaches defined by the JOSE, OAuth, and COSE working groups at the IETF. This includes JSON Web Signature (JWS) [RFC7515], Selective Disclosure for JWTs [SD-JWT], and CBOR Object Signing and Encryption (COSE) [RFC9052]. It uses content types [RFC6838] to distinguish between the data types of unsecured documents conforming to [VC-DATA-MODEL-2.0] and the data types of secured documents conforming to [VC-DATA-MODEL-2.0].
JSON Web Signature (JWS) [RFC7515] defines a standard means of digitally signing documents, including JSON documents, using JSON-based data structures. It provides a means to ensure the integrity, authenticity, and non-repudiation of the information contained in the document. Selective Disclosure for JWTs (SD-JWT) [SD-JWT] builds on JWS by also providing a mechanism enabling selective disclosure of document elements. These properties make JWS and SD-JWT especially well suited to securing documents conforming to [VC-DATA-MODEL-2.0].
CBOR Object Signing and Encryption (COSE) [RFC9052] defines a standard means of representing digitally signed data structures using Concise Binary Object Representation (CBOR) [RFC8949]. Like JWS, COSE provides a standardized way to secure the integrity, authenticity, and confidentiality of information. It offers a flexible and extensible set of cryptographic options, allowing for a wide range of algorithms to be used for signing and encryption.
COSE supports two main operations: signing and encryption. For signing, COSE allows the creation of digital signatures over CBOR data using various algorithms such as RSA, ECDSA, and EdDSA. These signatures provide assurance of data integrity and authenticity. COSE also supports encryption, enabling the confidentiality of CBOR data by encrypting it with symmetric or asymmetric encryption algorithms.
This section defines the terms used in this specification. A link to these terms is included whenever they appear in this specification.
This section outlines how to secure documents conforming to [VC-DATA-MODEL-2.0] using JOSE, SD-JWT, and COSE.
Documents conforming to [VC-DATA-MODEL-2.0], and their associated media types, rely on JSON-LD, which is an extensible format for describing linked data; see JSON-LD Relationship to RDF.
A benefit to this approach is that payloads can be made to conform directly to [VC-DATA-MODEL-2.0] without any mappings or transformation, while at the same time supporting registered header parameters and claims that are understood in the context of JOSE, SD-JWT, and COSE.
It is RECOMMENDED that media types be used to distinguish verifiable credentials and verifiable presentations from other kinds of secured JSON or CBOR.
The most specific media type (or subtype) available SHOULD be used, instead of
more generic media types (or supertypes). For example, rather than the general
application/sd-jwt
, application/vc-ld+sd-jwt
SHOULD be used, unless there is a more specific media type that would even
better identify the secured envelope format.
If implementations do not know which media type to use, media types defined in this specification MUST be used.
This section details how to use JOSE to secure verifiable credentials conforming to [VC-DATA-MODEL-2.0].
A conforming JWS issuer implementation MUST use [RFC7515] to secure this media type. The unsecured verifiable credential is the unencoded JWS payload.
The typ
header parameter SHOULD be vc-ld+jwt
.
When present, the cty
header parameter SHOULD be vc
.
See Registered Header Parameter Names
for additional details regarding usage of typ
and
cty
.
A conforming JWS verifier implementation MUST use [RFC7515] to verify conforming JWS documents that use this media type.
To encrypt a secured verifiable credential when transmitting over an insecure channel, implementers MAY use JSON Web Encryption (JWE) [RFC7516] by nesting the secured verifiable credential as the plaintext payload of a JWE, per the description of Nested JWTs in [RFC7519].
{ "@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].
A conforming JWS issuer implementation MUST use [RFC7515] to secure this media type. The unsecured verifiable presentation is the unencoded JWS payload.
The typ
header parameter SHOULD be vp-ld+jwt
.
When present, the cty
header parameter SHOULD be vp
.
See Registered Header Parameter Names
for additional details regarding usage of typ
and
cty
.
A conforming JWS verifier implementation MUST use [RFC7515] to verify conforming JWS documents that use this media type.
Verifiable Credentials secured in verifiable presentations MUST use the Enveloped Verifiable Credential type defined by the [VC-DATA-MODEL-2.0].
Verifiable Presentations in verifiable presentations MUST use the Enveloped Verifiable Presentation type defined by the [VC-DATA-MODEL-2.0].
Credentials in verifiable presentations MUST be secured. These credentials are secured using JWS in this case.
To encrypt a secured verifiable presentation when transmitting over an insecure channel, implementers MAY use JSON Web Encryption (JWE) [RFC7516] by nesting the secured verifiable presentation as the plaintext payload of a JWE, per the description of Nested JWTs in [RFC7519].
{ "@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"], "type": ["EnvelopedVerifiableCredential"], "id": "data:application/vc-ld+jwt,eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMzODQifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzE4NzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiRXhhbXBsZUFsdW1uaUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTY2hlbWEiOnsiaWQiOiJodHRwczovL2V4YW1wbGUub3JnL2V4YW1wbGVzL2RlZ3JlZS5qc29uIiwidHlwZSI6Ikpzb25TY2hlbWEifSwiY3JlZGVudGlhbFN1YmplY3QiOnsiaWQiOiJkaWQ6ZXhhbXBsZToxMjMiLCJkZWdyZWUiOnsidHlwZSI6IkJhY2hlbG9yRGVncmVlIiwibmFtZSI6IkJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMifX19.d2k4O3FytQJf83kLh-HsXuPvh6yeOlhJELVo5TF71gu7elslQyOf2ZItAXrtbXF4Kz9WivNdztOayz4VUQ0Mwa8yCDZkP9B2pH-9S_tcAFxeoeJ6Z4XnFuL_DOfkR1fP" }] }
See Verifiable Credentials Data Model v2.0 for more details regarding this example.
{ "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "type": "EnvelopedVerifiablePresentation", "id": "data:application/vp-ld+jwt,eyJraWQiOiJFeEhrQk1XOWZtYmt2VjI2Nm1ScHVQMnNVWV9OX0VXSU4xbGFwVXpPOHJvIiwiYWxnIjoiRVMzODQifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2NyZWRlbnRpYWxzLzE4NzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiRXhhbXBsZUFsdW1uaUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTY2hlbWEiOnsiaWQiOiJodHRwczovL2V4YW1wbGUub3JnL2V4YW1wbGVzL2RlZ3JlZS5qc29uIiwidHlwZSI6Ikpzb25TY2hlbWEifSwiY3JlZGVudGlhbFN1YmplY3QiOnsiaWQiOiJkaWQ6ZXhhbXBsZToxMjMiLCJkZWdyZWUiOnsidHlwZSI6IkJhY2hlbG9yRGVncmVlIiwibmFtZSI6IkJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMifX19.d2k4O3FytQJf83kLh-HsXuPvh6yeOlhJELVo5TF71gu7elslQyOf2ZItAXrtbXF4Kz9WivNdztOayz4VUQ0Mwa8yCDZkP9B2pH-9S_tcAFxeoeJ6Z4XnFuL_DOfkR1fP" }
See Verifiable Credentials Data Model v2.0 for more details regarding this example.
Implementations MUST support the JWS compact serialization. Use of the JWS JSON serialization is NOT RECOMMENDED.
When present in the JOSE Header or the JWT Claims Set, members registered in the IANA JSON Web Token Claims registry or the IANA JSON Web Signature and Encryption Header Parameters registry are to be interpreted as defined by the specifications referenced in the registries.
The normative statements in Registered Header Parameter Names, JOSE Header, and Replicating Claims as Header Parameters apply to securing credentials and presentations.
The unencoded JOSE Header is JSON (application/json
), not JSON-LD
(application/ld+json
).
It is RECOMMENDED to use the IANA
JSON Web Token Claims
registry and the IANA
JSON Web Signature and Encryption Header
Parameters
registry to identify any claims and header parameters that might be confused
with members defined by Verifiable Credentials Data Model v2.0 [VC-DATA-MODEL-2.0]. These include but are not limited
to: iss
, kid
, alg
, iat
,
exp
, and cnf
.
When the iat
(Issued At) and/or
exp
(Expiration Time) 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.
Use of the nbf
(Not Before) claim is NOT RECOMMENDED,
as it makes little sense to attempt to assign a future date to
a signature.
The claims and security provided by this specification are independent of the data secured and semantics provided by the Verifiable Credentials Data Model v2.0 [VC-DATA-MODEL-2.0]. This means that while the security features of this specification ensure data integrity and authenticity, they do not dictate the interpretation of claim data.
Implementers SHOULD avoid setting JWT claims to values that conflict with the
values of verifiable credential properties when a claim and property pair refer
to the same conceptual entity, especially with pairs such as iss
and issuer
,
jti
and id
, and sub
and credentialSubject.id
. For example, JWK claim
iss
should not be set to a value which conflicts with the value of verifiable
credential property issuer
.
The JWT Claim Names vc
and vp
MUST NOT be present.
Additional members may be present as header parameters and claims. If they are not understood, they MUST be ignored.
This section details how to use JOSE to secure verifiable credentials conforming to [VC-DATA-MODEL-2.0].
A conforming SD-JWT issuer implementation MUST use Selective Disclosure for JWTs (SD-JWT) [SD-JWT] to secure this media type. The unsecured verifiable credential is the input JSON claim set. The Issuer then converts the input JSON claim set (i.e., the unsecured verifiable credential) into an SD-JWT payload according to SD-JWT issuance instructions.
The typ
header parameter SHOULD be vc-ld+sd-jwt
.
When present, the cty
header parameter SHOULD be vc
.
See Registered Header Parameter Names
for additional details regarding usage of typ
and
cty
.
A conforming SD-JWT verifier implementation MUST use [SD-JWT] to verify conforming JWS documents that use this media type.
When securing verifiable credentials with [SD-JWT] implementers MUST ensure that
properties necessary for the validation and verification of a credential are NOT selectively
disclosable (i.e., such properties MUST be disclosed). These properties include but are not
limited to credentialStatus
and credentialSchema
.
To encrypt a secured verifiable credential when transmitting over an insecure channel, implementers MAY use JSON Web Encryption (JWE) [RFC7516] by nesting the secured verifiable credential as the plaintext payload of a JWE, per the instructions in Section 11.2 of [SD-JWT].
{ "@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 SD-JWT to secure verifiable presentations conforming to [VC-DATA-MODEL-2.0].
A conforming SD-JWT issuer implementation MUST use [SD-JWT] to secure this media type. The unsecured verifiable presentation is the unencoded SD-JWT payload.
The typ
header parameter SHOULD be vp-ld+sd-jwt
.
When present, the cty
header parameter SHOULD be vp
.
See Registered Header Parameter Names
for additional details regarding usage of typ
and
cty
.
A conforming SD-JWT verifier implementation MUST use [SD-JWT] to verify conforming JWS documents that use this media type.
Verifiable Credentials secured in verifiable presentations MUST use the Enveloped Verifiable Credential type defined by the [VC-DATA-MODEL-2.0].
Verifiable Presentations in verifiable presentations MUST use the Enveloped Verifiable Presentation type defined by the [VC-DATA-MODEL-2.0].
Credentials in verifiable presentations MUST be secured. These credentials are secured using SD-JWT in this case.
When securing verifiable presentations with [SD-JWT] implementers MUST ensure that
properties necessary for the validation and verification of a credential are NOT selectively
disclosable (i.e., such properties MUST be disclosed). These properties include but are not
limited to credentialStatus
and credentialSchema
.
To encrypt a secured verifiable presentation when transmitting over an insecure channel, implementers MAY use JSON Web Encryption (JWE) [RFC7516] by nesting the secured verifiable presentation as the plaintext payload of a JWE, per the instructions in Section 11.2 of [SD-JWT].
{ "@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", "type": "EnvelopedVerifiableCredential", "id": "data:application/vc-ld+sd-jwt,eyJhbGciOiJFUzM4NCIsImtpZCI6IlVRTV9fblE0UzZCTzhuUTRuT05YeHB4aHRob3lOeGI1M0xZZ1l6LTJBQnMiLCJ0eXAiOiJ2cCtsZCtqc29uK3NkLWp3dCIsImN0eSI6InZwK2xkK2pzb24ifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwidmVyaWZpYWJsZUNyZWRlbnRpYWwiOlt7IkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy92MiIsImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy9leGFtcGxlcy92MiJdLCJpc3N1ZXIiOiJodHRwczovL3VuaXZlcnNpdHkuZXhhbXBsZS9pc3N1ZXJzLzU2NTA0OSIsInZhbGlkRnJvbSI6IjIwMTAtMDEtMDFUMTk6MjM6MjRaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiYWx1bW5pT2YiOnsibmFtZSI6IkV4YW1wbGUgVW5pdmVyc2l0eSIsIl9zZCI6WyJoek9LRzU2cDI5c1ByTGFDNUE4RndFdUczVU05dUlZU1p1cU9YczJlVGJBIl19LCJfc2QiOlsiWVdXVmVDRndxQmk4WDBqSF9jV0NWWU16STNhOHBjTEVYRWZicFNSQVlndyJdfSwiX3NkIjpbIjJJZjhhaUs4REZwVWJ4dEc1cGMwel9SaFJzbm1ybGFRMEhzcTk4WFNyYWsiLCJUeDZ4ZWZMVUdUZUpfYWtVUFdGeHNvbUhobGtWVnpfNzVoaVZ6eWpyYmVzIl19XSwiX3NkIjpbIjd2anl0VVN3ZEJ0MXQ5RktlOVFfS3JIRXhFWGxrTEFaTzBKM0Jpd200dlkiXSwiX3NkX2FsZyI6InNoYS0yNTYiLCJpYXQiOjE3MDY1NjI4NDksImV4cCI6MTczODE4NTI0OSwiY25mIjp7Imp3ayI6eyJrdHkiOiJFQyIsImNydiI6IlAtMzg0IiwiYWxnIjoiRVMzODQiLCJ4IjoidWtEd1U2ZzlQUVRFUWhYaEgyckRZNndMQlg3UHFlUjZBcGlhVHBEUXowcl8tdDl6UXNxem54Z0hEcE5oekZlQyIsInkiOiJMQnhVYnBVdFNGMVVKVTVpYnJIdkpINjBUSG5YMk1xa0xHZGltU1l0UGR4RlkxOEdhcldiS3FZV0djUkZHVE9BIn19fQ.kYD63YtBNYnLUTw6Szf1vs_Ug3UBXhPwCyqpNmPnPDa3rXZQhQLdB1BgaoO8zgQ-c3B41fxaXMnLHYV9-B20uboSpJP0B-2Vre917eQt1cSDswDGA_Ytvn4BSqYVBB2J~WyJFMkFsRzhsY2p0QVFrcllIbjlIbnVRIiwgInR5cGUiLCAiVmVyaWZpYWJsZVByZXNlbnRhdGlvbiJd~WyI5NldYMDRneno4cVZzOVZLU2wwYTVnIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMTg3MiJd~WyJaekU2VFVaamtHMW1DWXBKMEhnc0l3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl1d~WyItQ3NsS25GZGFYb2JiQWsyU0JBVGR3IiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd~WyJuRm1OWl9IczB3WWNoOFdkeTdnQUNRIiwgImlkIiwgImRpZDpleGFtcGxlOmMyNzZlMTJlYzIxZWJmZWIxZjcxMmViYzZmMSJd" }] }
See Verifiable Credentials Data Model v2.0 for more details regarding this example.
{ "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "type": "EnvelopedVerifiablePresentation", "id": "data:application/vp-ld+sd-jwt,eyJhbGciOiJFUzM4NCIsImtpZCI6IlVRTV9fblE0UzZCTzhuUTRuT05YeHB4aHRob3lOeGI1M0xZZ1l6LTJBQnMiLCJ0eXAiOiJ2cCtsZCtqc29uK3NkLWp3dCIsImN0eSI6InZwK2xkK2pzb24ifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwidmVyaWZpYWJsZUNyZWRlbnRpYWwiOlt7IkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy92MiIsImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy9leGFtcGxlcy92MiJdLCJpc3N1ZXIiOiJodHRwczovL3VuaXZlcnNpdHkuZXhhbXBsZS9pc3N1ZXJzLzU2NTA0OSIsInZhbGlkRnJvbSI6IjIwMTAtMDEtMDFUMTk6MjM6MjRaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiYWx1bW5pT2YiOnsibmFtZSI6IkV4YW1wbGUgVW5pdmVyc2l0eSIsIl9zZCI6WyJoek9LRzU2cDI5c1ByTGFDNUE4RndFdUczVU05dUlZU1p1cU9YczJlVGJBIl19LCJfc2QiOlsiWVdXVmVDRndxQmk4WDBqSF9jV0NWWU16STNhOHBjTEVYRWZicFNSQVlndyJdfSwiX3NkIjpbIjJJZjhhaUs4REZwVWJ4dEc1cGMwel9SaFJzbm1ybGFRMEhzcTk4WFNyYWsiLCJUeDZ4ZWZMVUdUZUpfYWtVUFdGeHNvbUhobGtWVnpfNzVoaVZ6eWpyYmVzIl19XSwiX3NkIjpbIjd2anl0VVN3ZEJ0MXQ5RktlOVFfS3JIRXhFWGxrTEFaTzBKM0Jpd200dlkiXSwiX3NkX2FsZyI6InNoYS0yNTYiLCJpYXQiOjE3MDY1NjI4NDksImV4cCI6MTczODE4NTI0OSwiY25mIjp7Imp3ayI6eyJrdHkiOiJFQyIsImNydiI6IlAtMzg0IiwiYWxnIjoiRVMzODQiLCJ4IjoidWtEd1U2ZzlQUVRFUWhYaEgyckRZNndMQlg3UHFlUjZBcGlhVHBEUXowcl8tdDl6UXNxem54Z0hEcE5oekZlQyIsInkiOiJMQnhVYnBVdFNGMVVKVTVpYnJIdkpINjBUSG5YMk1xa0xHZGltU1l0UGR4RlkxOEdhcldiS3FZV0djUkZHVE9BIn19fQ.kYD63YtBNYnLUTw6Szf1vs_Ug3UBXhPwCyqpNmPnPDa3rXZQhQLdB1BgaoO8zgQ-c3B41fxaXMnLHYV9-B20uboSpJP0B-2Vre917eQt1cSDswDGA_Ytvn4BSqYVBB2J~WyJFMkFsRzhsY2p0QVFrcllIbjlIbnVRIiwgInR5cGUiLCAiVmVyaWZpYWJsZVByZXNlbnRhdGlvbiJd~WyI5NldYMDRneno4cVZzOVZLU2wwYTVnIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMTg3MiJd~WyJaekU2VFVaamtHMW1DWXBKMEhnc0l3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl1d~WyItQ3NsS25GZGFYb2JiQWsyU0JBVGR3IiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd~WyJuRm1OWl9IczB3WWNoOFdkeTdnQUNRIiwgImlkIiwgImRpZDpleGFtcGxlOmMyNzZlMTJlYzIxZWJmZWIxZjcxMmViYzZmMSJd" }
See Verifiable Credentials Data Model v2.0 for more details regarding this example.
Implementations MUST support the compact serialization (application/sd-jwt
)
and MAY support the JSON serialization (application/sd-jwt+json
).
If the JSON serialization is used, it is RECOMMENDED that a profile be defined
to ensure any additional JSON members are understood consistently.
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 use COSE to secure verifiable credentials conforming to [VC-DATA-MODEL-2.0].
A conforming COSE issuer implementation MUST use COSE_Sign1 as specified in [RFC9052] to secure this media type. The unsecured verifiable credential is the unencoded COSE_Sign1 payload.
The typ
header parameter, as described in COSE "typ" (type) Header Parameter, SHOULD be application/vc-ld+cose
.
When present, the content type (3)
header parameter
SHOULD be application/vc
.
See Common COSE Header Parameters for additional details.
A conforming COSE verifier implementation MUST use COSE_Sign1 as specified in [RFC9052] to verify conforming COSE documents that use this media type.
To encrypt a secured verifiable credential when transmitting over an insecure channel, implementers MAY use COSE encryption, as defined in Section 5 of [RFC9052], by nesting the secured verifiable credential as the plaintext payload of an encrypted COSE object.
{ "@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 COSE to secure verifiable presentations conforming to [VC-DATA-MODEL-2.0].
A conforming COSE issuer implementation MUST use COSE_Sign1 as specified in [RFC9052] to secure this media type. The unsecured verifiable presentation is the unencoded COSE_Sign1 payload.
The typ
header parameter SHOULD be application/vp-ld+cose
.
When present, the cty
header parameter SHOULD be application/vp
.
See Common COSE Header Parameters for additional details.
A conforming COSE verifier implementation MUST use COSE_Sign1 as specified in [RFC9052] to verify conforming COSE documents that use this media type.
Verifiable Credentials secured in verifiable presentations MUST use the Enveloped Verifiable Credential type defined by the [VC-DATA-MODEL-2.0].
Verifiable Presentations in verifiable presentations MUST use the Enveloped Verifiable Presentation type defined by the [VC-DATA-MODEL-2.0].
Credentials in verifiable presentations MUST be secured. These credentials are secured using COSE in this case.
To encrypt a secured verifiable presentation when transmitting over an insecure channel, implementers MAY use COSE encryption, as defined in Section 5 of [RFC9052], by nesting the secured verifiable presentation as the plaintext payload of an encrypted COSE object.
{ "@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", "type": "EnvelopedVerifiableCredential", "id": "data:application/vc-ld+sd-jwt,eyJhbGciOiJFUzM4NCIsImtpZCI6IlVRTV9fblE0UzZCTzhuUTRuT05YeHB4aHRob3lOeGI1M0xZZ1l6LTJBQnMiLCJ0eXAiOiJ2cCtsZCtqc29uK3NkLWp3dCIsImN0eSI6InZwK2xkK2pzb24ifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwidmVyaWZpYWJsZUNyZWRlbnRpYWwiOlt7IkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy92MiIsImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy9leGFtcGxlcy92MiJdLCJpc3N1ZXIiOiJodHRwczovL3VuaXZlcnNpdHkuZXhhbXBsZS9pc3N1ZXJzLzU2NTA0OSIsInZhbGlkRnJvbSI6IjIwMTAtMDEtMDFUMTk6MjM6MjRaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiYWx1bW5pT2YiOnsibmFtZSI6IkV4YW1wbGUgVW5pdmVyc2l0eSIsIl9zZCI6WyJoek9LRzU2cDI5c1ByTGFDNUE4RndFdUczVU05dUlZU1p1cU9YczJlVGJBIl19LCJfc2QiOlsiWVdXVmVDRndxQmk4WDBqSF9jV0NWWU16STNhOHBjTEVYRWZicFNSQVlndyJdfSwiX3NkIjpbIjJJZjhhaUs4REZwVWJ4dEc1cGMwel9SaFJzbm1ybGFRMEhzcTk4WFNyYWsiLCJUeDZ4ZWZMVUdUZUpfYWtVUFdGeHNvbUhobGtWVnpfNzVoaVZ6eWpyYmVzIl19XSwiX3NkIjpbIjd2anl0VVN3ZEJ0MXQ5RktlOVFfS3JIRXhFWGxrTEFaTzBKM0Jpd200dlkiXSwiX3NkX2FsZyI6InNoYS0yNTYiLCJpYXQiOjE3MDY1NjI4NDksImV4cCI6MTczODE4NTI0OSwiY25mIjp7Imp3ayI6eyJrdHkiOiJFQyIsImNydiI6IlAtMzg0IiwiYWxnIjoiRVMzODQiLCJ4IjoidWtEd1U2ZzlQUVRFUWhYaEgyckRZNndMQlg3UHFlUjZBcGlhVHBEUXowcl8tdDl6UXNxem54Z0hEcE5oekZlQyIsInkiOiJMQnhVYnBVdFNGMVVKVTVpYnJIdkpINjBUSG5YMk1xa0xHZGltU1l0UGR4RlkxOEdhcldiS3FZV0djUkZHVE9BIn19fQ.kYD63YtBNYnLUTw6Szf1vs_Ug3UBXhPwCyqpNmPnPDa3rXZQhQLdB1BgaoO8zgQ-c3B41fxaXMnLHYV9-B20uboSpJP0B-2Vre917eQt1cSDswDGA_Ytvn4BSqYVBB2J~WyJFMkFsRzhsY2p0QVFrcllIbjlIbnVRIiwgInR5cGUiLCAiVmVyaWZpYWJsZVByZXNlbnRhdGlvbiJd~WyI5NldYMDRneno4cVZzOVZLU2wwYTVnIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMTg3MiJd~WyJaekU2VFVaamtHMW1DWXBKMEhnc0l3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl1d~WyItQ3NsS25GZGFYb2JiQWsyU0JBVGR3IiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd~WyJuRm1OWl9IczB3WWNoOFdkeTdnQUNRIiwgImlkIiwgImRpZDpleGFtcGxlOmMyNzZlMTJlYzIxZWJmZWIxZjcxMmViYzZmMSJd" }] }
See Verifiable Credentials Data Model v2.0 for more details regarding this example.
{ "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/examples/v2" ], "type": "EnvelopedVerifiablePresentation", "id": "data:application/vp-ld+sd-jwt,eyJhbGciOiJFUzM4NCIsImtpZCI6IlVRTV9fblE0UzZCTzhuUTRuT05YeHB4aHRob3lOeGI1M0xZZ1l6LTJBQnMiLCJ0eXAiOiJ2cCtsZCtqc29uK3NkLWp3dCIsImN0eSI6InZwK2xkK2pzb24ifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwidmVyaWZpYWJsZUNyZWRlbnRpYWwiOlt7IkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy92MiIsImh0dHBzOi8vd3d3LnczLm9yZy9ucy9jcmVkZW50aWFscy9leGFtcGxlcy92MiJdLCJpc3N1ZXIiOiJodHRwczovL3VuaXZlcnNpdHkuZXhhbXBsZS9pc3N1ZXJzLzU2NTA0OSIsInZhbGlkRnJvbSI6IjIwMTAtMDEtMDFUMTk6MjM6MjRaIiwiY3JlZGVudGlhbFN1YmplY3QiOnsiYWx1bW5pT2YiOnsibmFtZSI6IkV4YW1wbGUgVW5pdmVyc2l0eSIsIl9zZCI6WyJoek9LRzU2cDI5c1ByTGFDNUE4RndFdUczVU05dUlZU1p1cU9YczJlVGJBIl19LCJfc2QiOlsiWVdXVmVDRndxQmk4WDBqSF9jV0NWWU16STNhOHBjTEVYRWZicFNSQVlndyJdfSwiX3NkIjpbIjJJZjhhaUs4REZwVWJ4dEc1cGMwel9SaFJzbm1ybGFRMEhzcTk4WFNyYWsiLCJUeDZ4ZWZMVUdUZUpfYWtVUFdGeHNvbUhobGtWVnpfNzVoaVZ6eWpyYmVzIl19XSwiX3NkIjpbIjd2anl0VVN3ZEJ0MXQ5RktlOVFfS3JIRXhFWGxrTEFaTzBKM0Jpd200dlkiXSwiX3NkX2FsZyI6InNoYS0yNTYiLCJpYXQiOjE3MDY1NjI4NDksImV4cCI6MTczODE4NTI0OSwiY25mIjp7Imp3ayI6eyJrdHkiOiJFQyIsImNydiI6IlAtMzg0IiwiYWxnIjoiRVMzODQiLCJ4IjoidWtEd1U2ZzlQUVRFUWhYaEgyckRZNndMQlg3UHFlUjZBcGlhVHBEUXowcl8tdDl6UXNxem54Z0hEcE5oekZlQyIsInkiOiJMQnhVYnBVdFNGMVVKVTVpYnJIdkpINjBUSG5YMk1xa0xHZGltU1l0UGR4RlkxOEdhcldiS3FZV0djUkZHVE9BIn19fQ.kYD63YtBNYnLUTw6Szf1vs_Ug3UBXhPwCyqpNmPnPDa3rXZQhQLdB1BgaoO8zgQ-c3B41fxaXMnLHYV9-B20uboSpJP0B-2Vre917eQt1cSDswDGA_Ytvn4BSqYVBB2J~WyJFMkFsRzhsY2p0QVFrcllIbjlIbnVRIiwgInR5cGUiLCAiVmVyaWZpYWJsZVByZXNlbnRhdGlvbiJd~WyI5NldYMDRneno4cVZzOVZLU2wwYTVnIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMTg3MiJd~WyJaekU2VFVaamtHMW1DWXBKMEhnc0l3IiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl1d~WyItQ3NsS25GZGFYb2JiQWsyU0JBVGR3IiwgImlkIiwgImRpZDpleGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJd~WyJuRm1OWl9IczB3WWNoOFdkeTdnQUNRIiwgImlkIiwgImRpZDpleGFtcGxlOmMyNzZlMTJlYzIxZWJmZWIxZjcxMmViYzZmMSJd" }
See Verifiable Credentials Data Model v2.0 for more details regarding this example.
When present in the COSE Header or as CWT Claims, members registered in the IANA CBOR Web Token (CWT) Claims registry or the IANA COSE Header Parameters registry are to be interpreted as defined by the specifications referenced in those registries. CBOR Web Token (CWT) [RFC8392] Claims MAY be included in a COSE header parameter, as specified in I-D.ietf-cose-cwt-claims-in-headers.
The normative statements in Header Parameters, Claims, and CBOR Web Token (CWT) Claims in COSE Headers apply to securing credentials and presentations.
It is RECOMMENDED to use the IANA
CBOR Web Token Claims
registry and the IANA
COSE Header Parameters
registry to identify any claims and header parameters that might be confused
with members defined by Verifiable Credentials Data Model v2.0 [VC-DATA-MODEL-2.0]. These include but are not limited
to: iss
, kid
, alg
, iat
,
exp
, and cnf
.
When the iat
(Issued At) and/or
exp
(Expiration Time) 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.
Use of the nbf
(Not Before) claim is NOT RECOMMENDED,
as it makes little sense to attempt to assign a future date to
a signature.
Additional members may be present as header parameters and claims. If they are not understood, they MUST be ignored.
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 present and is a [URL], the kid MUST match a key discovered via a JWT Issuer Metadata Request, as described in [SD-JWT-VC].
This normative statement depends on the IETF OAuth working group draft [SD-JWT-VC]. This feature is at risk and will be removed from the specification if at least two independent, interoperable implementations are not demonstrated.
To complete the verification process, a verifier needs to obtain the cryptographic keys used to secure the credential.
There are several different ways to discover the verification keys of the issuers and holders.
These JOSE header parameters and JWT claims can be used by verifiers to discover verification keys.
If kid
is present in the JOSE Header
or the COSE Header,
a verifier can use this parameter
as a hint indicating which key was used to secure the verifiable credential, when performing a
verification process as defined in RFC7515.
kid
MUST be present when the key of the issuer
or subject is expressed as a DID URL.
If iss
is present in the JOSE Header,
the JWT Claims,
or the COSE Header,
a verifier can use this parameter
to obtain a JSON Web Key to use in the
verification process.
The value of the issuer property can be either a string or
an object.
When issuer
value is a string, iss
value, if present, MUST match
issuer
value.
When issuer
value is an object with an id
value,
iss
value, if present, MUST match issuer.id
value.
If kid
is also present in the
JOSE Header, it is used to
distinguish the specific key used.
If cnf
is present in the JOSE Header,
the JWT Claims,
or the COSE Header,
a verifier MAY use this parameter
to identify a proof-of-possession key in the manner described in [RFC7800]
or [RFC8747] for use in the
verification process.
Use of a proof-of-possession key provided by the Holder to the Issuer to establish a cryptographic binding to the Holder in the Verifiable Credential that is verifiable by the Verifier in the Verifiable Presentation is RECOMMENDED.
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].
This normative statement depends on the IETF OAuth working group draft [SD-JWT-VC]. This feature is at risk and will be removed from the specification if at least two independent, interoperable implementations are not demonstrated.
When using controller documents with this specification, the following requirements apply.
The value of the type
property of the verification method MUST be JsonWebKey
.
Verification material MUST be expressed in the publicKeyJwk
property
of a JsonWebKey
. This key material is retrieved based on hints in the
JOSE or COSE message envelopes, such as kid
or iss
. At
the time of writing, there is no standard way to retrieve a public key in JWK format
from a DID URL or controller document.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, MUST NOT, NOT RECOMMENDED, RECOMMENDED, 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.
A conforming JWS document is one that conforms to all of the "MUST" statements in Section 3.1 With JOSE.
A conforming JWS issuer implementation produces conforming JWS documents and MUST secure them as described in Section 3.1 With JOSE.
A conforming JWS verifier implementation verifies conforming JWS documents as described in Section 3.1 With JOSE.
A conforming SD-JWT document is one that conforms to all of the "MUST" statements in Section 3.2 With SD-JWT.
A conforming SD-JWT issuer implementation produces conforming SD-JWT documents and MUST secure them as described in Section 3.2 With SD-JWT.
A conforming SD-JWT verifier implementation verifies conforming SD-JWT documents as described in Section 3.2 With SD-JWT.
A conforming COSE document is one that conforms to all of the "MUST" statements in Section 3.3 With COSE.
A conforming COSE issuer implementation produces conforming COSE documents and MUST secure them as described in Section 3.3 With COSE.
A conforming COSE verifier implementation verifies conforming COSE documents as described in Section 3.3 With COSE.
The Verifiable Credentials Data Model v2.0 describes
the approach taken by JSON Web Tokens to secure JWT Claims Sets as applying an
external proof
.
The normative statements in Securing
Mechanisms apply to securing
application/vc-ld+jwt
and
application/vp-ld+jwt
,
application/vc-ld+sd-jwt
and
application/vp-ld+sd-jwt
,
as well as
application/vc-ld+cose
and
application/vp-ld+cose
.
JSON Web Token implementers are advised to review Implementation Requirements.
Accordingly, Issuers, Holders, and Verifiers MUST understand the
JSON Web Token header parameter
"alg": "none"
when securing [VC-DATA-MODEL-2.0]
with JSON Web Tokens.
When content types from [VC-DATA-MODEL-2.0] are secured using
JSON Web Tokens, the header parameter "alg": "none"
,
MUST be used to communicate that a JWT Claims Set (a
Verifiable Credential or a Verifiable Presentation) has no
integrity protection.
When a JWT Claims Set (a Verifiable Credential or a
Verifiable Presentation) contains
proof
, and the JSON Web Token header contains
"alg": "none"
, the JWT Claims Set MUST be considered to
have no integrity protection.
Verifiable Credentials and Verifiable Presentations are not
required to be secured or integrity protected or to contain a
proof
member.
Issuers, Holders, and Verifiers MUST ignore all JWT Claims Sets that have no integrity protection.
The JWT Claim Names vc
and vp
MUST NOT be present in any JWT Claims Set.
This specification registers the
application/vc-ld+jwt
Media Type specifically for
identifying a JSON Web Token (JWT)
with a payload
conforming to the
Verifiable Credential Data Model.
Type name: | application |
Subtype name: | vc-ld+jwt |
Required parameters: | None |
Encoding considerations: |
binary; application/jwt values are a series of base64url-encoded values
(some of which may be the empty string) separated by period ('.').
|
Security considerations: |
As defined in this specification. See also the security considerations in JSON Web Token (JWT). |
Contact: | W3C Verifiable Credentials Working Group public-vc-wg@w3.org |
This specification registers the
application/vp-ld+jwt
Media Type specifically for
identifying a JSON Web Token (JWT)
with a payload
conforming to the
Verifiable Presentations definition in the Verifiable Credential Data Model.
Type name: | application |
Subtype name: | vp-ld+jwt |
Required parameters: | None |
Encoding considerations: |
binary; application/jwt values are a series of base64url-encoded values
(some of which may be the empty string) separated by period ('.').
|
Security considerations: |
As defined in this specification. See also the security considerations in JSON Web Token (JWT). |
Contact: | W3C Verifiable Credentials Working Group public-vc-wg@w3.org |
This specification registers the
application/vc-ld+sd-jwt
Media Type specifically for
identifying a Selective Disclosure for JWTs (SD-JWT)
with a payload
conforming to the
Verifiable Credential Data Model.
Type name: | application |
Subtype name: | vc-ld+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+sd-jwt
Media Type specifically for
identifying a Selective Disclosure for JWTs (SD-JWT)
with a payload
conforming to the
Verifiable Presentations definition in the Verifiable Credential Data Model.
Type name: | application |
Subtype name: | vp-ld+sd-jwt |
Required parameters: | None |
Encoding considerations: |
binary; application/sd-jwt values are a series of base64url-encoded values
(some of which may be the empty string) separated by period ('.') or tilde ('~') characters.
|
Security considerations: |
As defined in this specification. See also the security considerations in Selective Disclosure for JWTs (SD-JWT). |
Contact: | W3C Verifiable Credentials Working Group public-vc-wg@w3.org |
This specification registers the
application/vc-ld+cose
Media Type specifically for
identifying a COSE object [RFC9052]
with a payload
conforming to the
Verifiable Credential Data Model.
Type name: | application |
Subtype name: | vc-ld+cose |
Required parameters: | None |
Encoding considerations: | binary (CBOR) |
Security considerations: |
As defined in this specification. See also the security considerations in [RFC9052]. |
Contact: | W3C Verifiable Credentials Working Group public-vc-wg@w3.org |
This specification registers the
application/vp-ld+cose
Media Type specifically for
identifying a COSE object [RFC9052]
with a payload
conforming to the
Verifiable Presentations definition in the Verifiable Credential Data Model.
Type name: | application |
Subtype name: | vp-ld+cose |
Required parameters: | None |
Encoding considerations: | binary (CBOR) |
Security considerations: |
As defined in this specification. See also the security considerations in [RFC9052]. |
Contact: | W3C Verifiable Credentials Working Group public-vc-wg@w3.org |
Verifiable Credentials often contain sensitive information that needs to be protected to ensure the privacy and security of organizations and individuals. This section outlines some privacy considerations relevant to implementers and users.
Implementers are advised to note and abide by all privacy considerations called out in [VC-DATA-MODEL-2.0].
Implementers are additionally advised to reference the Privacy Consideration section of the JWT specification and NIST Special Publication 800-122 [[SP-800-122] "Guide to Protecting the Confidentiality of Personally Identifiable Information (PII)" for privacy guidance.
In addition to the privacy recommendations in the [VC-DATA-MODEL-2.0], 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 this specification.
This section outlines security considerations for implementers and users of this specification. It is important to carefully consider these factors to ensure the security and integrity of Verifiable Credentials when implemented using JOSE or COSE.
When implementing this specification, it is essential to address all security issues relevant to broad cryptographic applications. This especially includes protecting the user's asymmetric private and symmetric secret keys, as well as employing countermeasures against various attacks. Failure to adequately address these issues could compromise the security and integrity of Verifiable Credentials, potentially leading to unauthorized access, modification, or disclosure of sensitive information.
Implementers are advised to follow best practices and established cryptographic standards to ensure the secure handling of keys and other sensitive data. Additionally, conduct regular security assessments and audits to identify and address any vulnerabilities or threats.
Follow all security considerations outlined in [RFC7515] and [RFC7519].
When utilizing JSON-LD, take special care around remote retrieval of contexts and follow the additional security considerations noted in [json-ld11].
As noted in [RFC7515] when utilizing JSON [RFC7159], strict validation is a security requirement. If malformed JSON is received, it may be impossible to reliably interpret the producer's intent, potentially leading to ambiguous or exploitable situations. To prevent these risks, it is essential to use a JSON parser that strictly validates the syntax of all input data. It is essential that any JSON inputs that do not conform to the JSON-text syntax defined in [RFC7159] be rejected in their entirety by JSON parsers. Failure to reject invalid input could compromise the security and integrity of Verifiable Credentials.
This section is non-normative.
When implementing this specification, it is crucial for technical implementers to consider various accessibility factors. Ignoring accessibility concerns renders the information unusable for a significant portion of the population. To ensure equal access for all individuals, regardless of their abilities, it is vital to adhere to accessibility guidelines and standards, such as the Web Content Accessibility Guidelines (WCAG 2.1) [WCAG21]. This becomes even more critical when establishing systems that involve cryptography, as they have historically posed challenges for assistive technologies.
Implementers are advised to note and abide by all accessibility considerations called out in [VC-DATA-MODEL-2.0].
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",
"https://w3id.org/security/jwk/v1",
{
"@vocab": "https://vendor.example#"
}
],
"id": "did:web:vendor.example",
"alsoKnownAs": ["https://vendor.example",
"did:jwk:eyJraWQiOiJ1cm46aWV0ZjpwYXJhbXM6b2F1dGg6andrLXRodW1icHJpbnQ6c2hhLTI1NjpGZk1iek9qTW1RNGVmVDZrdndUSUpqZWxUcWpsMHhqRUlXUTJxb2JzUk1NIiwia3R5IjoiT0tQIiwiY3J2IjoiRWQyNTUxOSIsImFsZyI6IkVkRFNBIiwieCI6IkFOUmpIX3p4Y0tCeHNqUlBVdHpSYnA3RlNWTEtKWFE5QVBYOU1QMWo3azQifQ"
],
"verificationMethod": [{
"id": "#urn:ietf:params:oauth:jwk-thumbprint:sha-256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs",
"type": "JsonWebKey",
"controller": "did:web:vendor.example",
"publicKeyJwk": {
"kty": "EC",
"crv": "P-521",
"alg": "ES512",
"x": "AFTyMw-fIYJNg6fBVJvOPOsLxmnNj8HgqMChyRL0swLaefVAc7wrWZ8okQJqMmvv03JRUp277meQZM3JcvXFkH1v",
"y": "ALn96CrD88b4TClmkl1sk0xk2FgAIda97ZF8TUOjbeWSzbKnN2KB6pqlpbuJ2xIRXvsn5BWQVlAT2JGpGwDNMyV1"
}
}, {
"id": "#z6MkhEdpG12jyQegrr62ACRmNY8gc531W2j9Xo39cHphuCEH",
"type": "JsonWebKey2020",
"controller": "https://vendor.example",
"publicKeyJwk": {
"kid": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:FfMbzOjMmQ4efT6kvwTIJjelTqjl0xjEIWQ2qobsRMM",
"kty": "OKP",
"crv": "Ed25519",
"alg": "EdDSA",
"x": "ANRjH_zxcKBxsjRPUtzRbp7FSVLKJXQ9APX9MP1j7k4"
}
}, {
"id": "#subject-authentication",
"type": "JsonWebKey",
"controller": "did:web:vendor.example",
"publicKeyJwk": {
"kty": "EC",
"crv": "P-384",
"alg": "ES384",
"x": "PxgAmVYOQvSNcMYL2tOzoLwSWn4Ta3tIMPEUKR8pxeb-gmR11-DyKHBoIiY-2LhM",
"y": "BZEBTkImVdpwvxR9THIRw16eblnj5-tZa7m-ww5uVd4kyPJNRoWUn2aT9ZuarAe-"
}
}, {
"id": "#credential-issuance",
"type": "JsonWebKey",
"controller": "did:web:vendor.example",
"publicKeyJwk": {
"kty": "EC",
"crv": "P-256",
"alg": "ES256",
"x": "MYvnaI87pfrn3FpTqW-yNiFcF1K7fedJiqapm20_q7c",
"y": "9YEbT6Tyuc7xp9yRvhOUVKK_NIHkn5HpK9ZMgvK5pVw"
}
}, {
"id": "#key-agreement",
"type": "JsonWebKey",
"controller": "did:web:vendor.example",
"publicKeyJwk": {
"kty": "OKP",
"crv": "X25519",
"alg": "ECDH-ES+A128KW",
"x": "qLZkSTbstvMWPTivmiQglEFWG2Ff7gNDVoVisdZTr1I"
}
}],
"authentication": ["#subject-authentication"],
"assertionMethod": ["#credential-issuance"]
}
{ "@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", "https://www.w3.org/ns/credentials/examples/v2" ], "type": "VerifiablePresentation", "verifiableCredential": [ { "@context": "https://www.w3.org/ns/credentials/v2", "id": "data:application/vc-ld+cose,QzVjV...RMjU", "type": "EnvelopedVerifiableCredential" }, { "@context": "https://www.w3.org/ns/credentials/v2", "id": "data:application/vc-ld+jwt,eyVjV...RMjU", "type": "EnvelopedVerifiableCredential" }, { "@context": "https://www.w3.org/ns/credentials/v2", "id": "data:application/vc-ld+sd-jwt,eyVjV...RMjU", "type": "EnvelopedVerifiableCredential" } ] }
data:application/vc-ld+sd-jwt,eyJhbGciOiJFUzM4NCIsImtpZCI6IlNJM1JITm91aDhvODFOT09OUFFVQUw3RWdaLWtJNl94ajlvUkV2WDF4T3ciLCJ0eXAiOiJ2YytsZCtqc29uK3NkLWp3dCIsImN0eSI6InZjK2xkK2pzb24ifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaXNzdWVyIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy81NjUwNDkiLCJ2YWxpZEZyb20iOiIyMDEwLTAxLTAxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTY2hlbWEiOnsiX3NkIjpbIkU3dU1sSWFyS29iYXJTdEZGRjctZm5qaV9sQVdnM3BGMkV5dVc4dWFYakUiLCJYelRaSVgyNGdDSWxSQVFHclFoNU5FRm1XWkQtZ3Z3dkIybzB5Y0FwNFZzIl19LCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsibmFtZSI6IkJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMiLCJfc2QiOlsiT3oxUEZIMG0tWk9TdEhwUVZyeGlmVlpKRzhvNmlQQmNnLVZ2SXQwd2plcyJdfSwiX3NkIjpbIkVZQ1daMTZZMHB5X1VNNzRHU3NVYU9zT19mdDExTlVSaFFUTS1TT1lFTVEiXX0sIl9zZCI6WyJqT055NnZUbGNvVlAzM25oSTdERGN3ekVka3d2R3VVRXlLUjdrWEVLd3VVIiwid21BdHpwc0dRbDJveS1PY2JrSEVZcE8xb3BoX3VYcWVWVTRKekF0aFFibyJdLCJfc2RfYWxnIjoic2hhLTI1NiIsImlzcyI6Imh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL2lzc3VlcnMvNTY1MDQ5IiwiaWF0IjoxNjk3Mjg5OTk2LCJleHAiOjE3Mjg5MTIzOTYsImNuZiI6eyJqd2siOnsia3R5IjoiRUMiLCJjcnYiOiJQLTM4NCIsImFsZyI6IkVTMzg0IiwieCI6InZFdV84WGxZT0ZFU2hTcVRpZ2JSYWduZ0ZGM1p5U0xrclNHekh3azFBT1loanhlazVhV21HY2UwZU05S0pWOEIiLCJ5IjoiRUpNY2czWXBzUTB3M2RLNHlVa25QczE1Z0lsY2Yyay03dzFKLTNlYlBiOERENmQtUkhBeGUwMDkzSWpfdTRCOSJ9fX0.rYzbxb6j1dwop8_s491iArVVJNm6A6C3b742gOm_qYO3zdkyQU4_VxxOSJ8ECcmWj2r5KyiCNC1ojfO4Yms-zBsjt7PoMYpYWBplsqXpiIvnehmM7D0eOLi40uHXki0X~WyJSWTg1YTZNMmEwX3VDWlFTVGZmTFdRIiwgImlkIiwgImh0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvMTg3MiJd~WyJMeG5GYTBXVm8wRUluVy1QdS1fd1dRIiwgInR5cGUiLCBbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwgIkV4YW1wbGVBbHVtbmlDcmVkZW50aWFsIl1d~WyJUQVdrakpCaVpxdC1rVU54X1EweUJBIiwgImlkIiwgImh0dHBzOi8vZXhhbXBsZS5vcmcvZXhhbXBsZXMvZGVncmVlLmpzb24iXQ~WyJTd2xuZFpPZzZEZ1ZERFp5X0RvYVFBIiwgInR5cGUiLCAiSnNvblNjaGVtYSJd~WyJuSnJlU3E1Nzg3RGZMSDJCbU03cXFRIiwgImlkIiwgImRpZDpleGFtcGxlOjEyMyJd~WyIxMjNNd3hNcHRiek02YUk2aW03ME1RIiwgInR5cGUiLCAiQmFjaGVsb3JEZWdyZWUiXQ
data:application/vp-ld+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.
{ / Protected /
1: -35, / Algorithm /
3: application/vc, / Content type /
4: h'177f12cb...1933d554', / Key identifier /
15: { / CWT Claims /
1: urn:example:123, / Issuer /
2: urn:example:456, / Subject /
},
}
{ / Protected /
1: -35, / Algorithm /
3: application/vp, / Content type /
4: h'177f12cb...1933d554', / Key identifier /
15: { / CWT Claims /
1: urn:example:123, / Issuer /
2: urn:example:456, / Subject /
},
}
18( / COSE Sign 1 /
[
h'a4013822...3a343536', / Protected Header /
{} / Unprotected Header /
h'0fbe22a0...3a009118', / Attached payload /
h'09772c7f...5c4e736f' / Signature /
]
)
The payload can be either a credential or presentation as described in Securing Mechanisms.
This specification might be used with many different key discovery protocols. Therefore, discovery of verification keys is described in 4. Key Discovery, and is assumed to have succeeded prior to beginning the verification process.
As a general rule, verifiers SHOULD strive to minimize the processing of untrusted data. This includes minimizing any processing of the protected header, unprotected header, or payload as part of the key discovery procedures.
After verification has succeeded, additional validation checks SHOULD be performed as described in Section 10. Validation Algorithm
The outputs for the following algorithms are:
status
: a boolean indicating the result of verification,
true
for success and false
for failure.
document
: a document conforming to the Verifiable Credentials Data Model v2.0 [VC-DATA-MODEL-2.0]
mediaType
: vc
or vp
The inputs for this algorithm are:
inputMediaType
: vc-ld+jwt
or
vp-ld+jwt
inputDocument
: the verifiable credential secured as a JWT [RFC7519]
Upon receipt of the verifiable credential or presentation secured as a JWT [RFC7519], the holder or verifier follows this algorithm:
status
to true
mediaType
to vc
or vp
document
to the decoded JWS payload.
status
to false
document
to null
mediaType
to null
The inputs for this algorithm are:
inputMediaType
: vc-ld+sd-jwt
inputDocument
: the verifiable credential secured with [SD-JWT]
Upon receipt of the verifiable credential or presentation secured with [SD-JWT], the holder or verifier follows this algorithm:
status
to true
mediaType
to vc
document
to the JSON claim set.
(For examples of the transition from JSON claim set to SD-JWT payload, please
see SD-JWT examples).
status
to false
document
to null
mediaType
to null
The inputs for this algorithm are:
inputMediaType
: vc-ld+cose
or
vp-ld+cose
inputDocument
: the verifiable credential or verifiable presentation
secured with CBOR Object Signing and Encryption (COSE): Structures and Process
Upon receipt of the verifiable credential or presentation secured with [RFC9052], the holder or verifier follows this algorithm:
status
to true
mediaType
to vc
or vp
document
to the decoded COSE_Sign1 payload.
status
to false
document
to null
mediaType
to null
All claims expected for the typ
MUST be present.
All claims that are understood MUST be evaluated according the verifier's validation policies.
All claims that are not understood MUST be ignored.
The verified document
returned from verification MUST be a
well-formed compact JSON-LD document, as described in
Verifiable Credentials Data Model v2.0.
Schema extension mechanisms such as credentialSchema
SHOULD be checked.
If the extension mechanism type
is not understood, this property
MUST be ignored.
Status extension mechanisms such as credentialStatus
SHOULD be checked.
If the extension mechanism type
is not understood, this property
MUST be ignored.
Based on the validation policy of the verifier, the type of credentials, and the type of securing mechanism, additional validation checks MAY be applied. For example, dependencies between multiple credentials, ordering or timing information associated with multiple credentials, and/or multiple presentations could cause an otherwise valid credential or presentation to be considered invalid.
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: