This specification defines how to secure Verifiable Credentials with JSON Web Tokens (JWT) [RFC7519], which build on JSON Web Signatures (JWS) [RFC7515]. This enables Verifiable Credentials to be easily integrated into ecosystems that already support JSON Web Tokens.
JSON Web Token (JWT) [[RFC7519]] is a widely-used means of expressing claims to be transferred between two parties. Providing a representation of the Verifiable Credentials Data Model for JWT allows existing systems and libraries to participate in the ecosystem described in Section ecosystem overview. A JWT encodes a set of claims as a JSON object that is contained in a JSON Web Signature (JWS) [[RFC7515]] and/or JSON Web Encryption (JWE) [[?RFC7516]]. For this specification, the use of JWE is out of scope.
This specification describes how to secure media types expressing Verifiable Credentials and Verifiable Presentations as described in the [[VC-DATA-MODEL]], using JWTs [[RFC7519]].
The application/vc+jwt
media type described in this specification defines
an example of a unidirectional mapping to a base media type defined in
the [[VC-DATA-MODEL]]; see Appendix A.4.1.
This section provides guidance on how to use JSON [[RFC7159]] claimsets with JWT registered claims to construct a JWT that can be mapped to a verifiable credential. This section also describes how to use content types and token types to distinguish different representations of verifiable credentials.
This representation relies on claims registered in the IANA JSON Web Token Claims Registry whenever possible.
Production of this representation does not use vc+ld+json
as an input.
typ MUST use the media type vc+jwt
.
The vc
and vp
claims MUST NOT be present when the content type header parameter is set to credential-claims-set+json
.
The use of Verifiable Credentials often involves the representation and exchange of structured data in the form of JSON-LD as this is the format of the core data model. While JSON-LD provides a flexible and extensible format for describing data, it is important to note that it also provides a linkage between the data structure and semantic meaning of data.
This section outlines how JSON-LD encoded claimset can be secured using either JOSE or COSE.
A benefit to this approach is that payloads can be made to conform directly to the [[VC-DATA-MODEL]] without any mapping or transformation.
This section details how to secure data payloads with the type application/vc+ld+json
with JOSE.
[[rfc7515]] MAY be used to secure this media type.
When using this approach, the typ
MUST be vc+ld+jwt
When using this approach, the cty
MUST be vc+ld+json
See Common JOSE Header Parameters
for additional details regarding usage of typ
and cty
.
This section details how to secure verifiable presentations with the type
application/vp+ld+json
with JOSE.
[[rfc7515]] MAY be used to secure this media type.
When using this approach, the typ
MUST be vp+ld+jwt
When using this approach, the cty
MUST be vp+ld+json
See Common JOSE Header Parameters
for additional details regarding usage of typ
and cty
.
COSE [[rfc8152]] is a common approach to encoding and securing information using CBOR [[rfc8949]]. Verifiable credentials MAY be secured using COSE [[rfc8152]] and MUST 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.
[[rfc8152]] MAY be used to secure this media type.
When using this approach, the type (TBD)
MUST be vc+ld+cwt
When using this approach, the content type (3)
MUST be application/vc+ld+json
See Common COSE Header Parameters for additional details.
See Concise Binary Object Representation (CBOR) Tags for additional details.
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.
application/vc+jwt
This specification registers the application/vc+jwt
Media Type specifically for
identifying a JWT conforming to the Verifiable Credentials JWT format in the `typ` header.
Type name: | application |
Subtype name: | application/vc+jwt |
Required parameters: | None |
Encoding considerations: |
application/vc+jwt values are encoded
as a series of base64url encoded values (some of which may be the
empty string) each separated from the next by a single period
('.') character.
|
Security considerations: |
As defined in this specification. See also the security considerations in [[RFC7519]]. |
Contact: | W3C Verifiable Credentials Working Group public-vc-wg@w3.org |
application/vc+ld+jwt
This specification registers the application/vc+ld+jwt
Media Type specifically for
identifying a JWT conforming to the Verifiable Credentials JWT format in the `typ` header.
Type name: | application |
Subtype name: | vc+ld+jwt |
Required parameters: | None |
Encoding considerations: |
application/vc+ld+jwt values are encoded
as a series of base64url encoded values (some of which may be the
empty string) each separated from the next by a single period
('.') character.
|
Security considerations: |
As defined in this specification. See also the security considerations in [[RFC7519]]. |
Contact: | W3C Verifiable Credentials Working Group public-vc-wg@w3.org |
application/credential-claims-set-1.1+json
This specification registers the application/credential-claims-set-1.1+json
MIME Media Type specifically for
identifying a JWT Claims Set conforming to the Verifiable Credentials 1.1 JWT format in the `cty` header.
Type name: | application |
Subtype name: | application/credential-claims-set-1.1+json |
Required parameters: | None |
Encoding considerations: |
Resources that use the "application/credential-claims-set-1.1+json "
Media Type are required to conform to all of the requirements
for the "application/json " Media Type and are
therefore subject to the same encoding considerations specified
in Section 11 of [[RFC7159]].
|
Security considerations: |
As defined in this specification. See also the security considerations in [[RFC7519]]. |
Contact: | W3C Verifiable Credentials Working Group public-vc-wg@w3.org |
The following describes a mapping from application/vc+jwt
to
application/vc+ld+json
. This is one possible unidirectional mapping
between 2.0 VC-JWTs and the VC Data Model; other such mappings are possible.
iss
, sub
, iat
, nbf
,
exp
, jti
, and aud
as registered claims.
@context
to
"https://www.w3.org/ns/credentials/v2"
.
type
to ["VerifiableCredential"]
.
issuer
property to one of the following:
iss
is a URL, use the value of iss
.
iss
is not a URL, use the concatenation of "urn:vc:
"
and the value of iss
.
jti
is present, set the value of id
to the
concatenation of "urn:vc:
" and the value of jti
.
nbf
is present, set the value of validFrom
to the
dateTime
obtained by converting the value of nbf
from
the NumericDate
described in [[!RFC7519]] to a dateTime
as
described in [[XMLSCHEMA11-2]].
exp
is present, set the value of validUntil
to the
dateTime
obtained by converting the value of exp
from
the NumericDate
described in [[!RFC7519]] to a dateTime
as
described in [[XMLSCHEMA11-2]].
credentialSubject
to an object that contains
the following properties:
sub
is present, set the value of the id
property to
the concatenation of "urn:vc:" and the value of sub
.