Securing Verifiable Credentials using JSON Web Tokens

Abstract

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.

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.

Example 4: verifiable credential header (decoded JWT header)

Example

{
  "kid": "urn:example:issuer#key-0",
  "alg": "ES256",
  "typ": "vc+ld+jwt",
  "cty": "vc+ld+json"
}

Example 5: verifiable credential (decoded JWT claimset)

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu/issuers/14",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:123",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  }
}

Example 6: verifiable credential (encoded as JWT)

eyJraWQiOiJ1cm46ZXhhbXBsZTppc3N1ZXIja2V5LTAiLCJhbGciOiJFUzI1NiIsInR5cCI6InZjK2xkK2p3dCIsImN0eSI6InZjK2xkK2pzb24ifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiXSwiaWQiOiJodHRwOi8vZXhhbXBsZS5lZHUvY3JlZGVudGlhbHMvMzczMiIsInR5cGUiOlsiVmVyaWZpYWJsZUNyZWRlbnRpYWwiLCJVbml2ZXJzaXR5RGVncmVlQ3JlZGVudGlhbCJdLCJpc3N1ZXIiOiJodHRwczovL2V4YW1wbGUuZWR1L2lzc3VlcnMvMTQiLCJpc3N1YW5jZURhdGUiOiIyMDEwLTAxLTAxVDE5OjIzOjI0WiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoiZGlkOmV4YW1wbGU6MTIzIiwiZGVncmVlIjp7InR5cGUiOiJCYWNoZWxvckRlZ3JlZSIsIm5hbWUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIn19fQ.pfbhgWlTUZA8WmoFbi8WEIUFyC_lSQaAswoW87D1YeimdWZLq4MiJ3o-CmTkvkEQFhffvRiCzmkhxjS_R_RdOw

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.

Example 7: verifiable presentation header (decoded JWT header)

Example

{
  "kid": "urn:example:holder#key-0",
  "alg": "ES256",
  "typ": "vp+ld+jwt",
  "cty": "vp+ld+json"
}

Example 8: verifiable presentation (decoded JWT claimset)

Example

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2"
  ],
  "id": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
  "type": ["VerifiablePresentation"],
  "verifiableCredential": [
    "eyJraWQiOiJodHRwczovL2V4YW1wbGUuZWR1L2lzc3VlcnMvMTQja2V5LTAiLCJhbGciOiJFUzI1NiIsInR5cCI6InZjK2p3dCJ9.eyJpc3MiOiJodHRwczovL2V4YW1wbGUuZWR1L2lzc3VlcnMvMTQiLCJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJ1cm46ZXhhbXBsZTpjbGFpbSI6dHJ1ZX0.H3v8sm9_sOClSA65h_MK_ZsoBiuJ0z2pPNS-yfqXdUIWl0n5VlZlfANsMYaTycF-Fdkdqjts6H-q4LO27vxFnA"
  ]
}

Issue

presentation.verifiableCredential[0] is not a valid IRI.

Example 9: verifiable presentation

An encoded verifiable presentation (using external proof).

eyJraWQiOiJ1cm46ZXhhbXBsZTpob2xkZXIja2V5LTAiLCJhbGciOiJFUzI1NiIsInR5cCI6InZwK2xkK2p3dCIsImN0eSI6InZwK2xkK2pzb24ifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiXSwiaWQiOiJ1cm46dXVpZDozOTc4MzQ0Zi04NTk2LTRjM2EtYTk3OC04ZmNhYmEzOTAzYzUiLCJ0eXBlIjpbIlZlcmlmaWFibGVQcmVzZW50YXRpb24iXSwidmVyaWZpYWJsZUNyZWRlbnRpYWwiOlsiZXlKcmFXUWlPaUpvZEhSd2N6b3ZMMlY0WVcxd2JHVXVaV1IxTDJsemMzVmxjbk12TVRRamEyVjVMVEFpTENKaGJHY2lPaUpGVXpJMU5pSXNJblI1Y0NJNkluWmpLMnAzZENKOS5leUpwYzNNaU9pSm9kSFJ3Y3pvdkwyVjRZVzF3YkdVdVpXUjFMMmx6YzNWbGNuTXZNVFFpTENKemRXSWlPaUl4TWpNME5UWTNPRGt3SWl3aWJtRnRaU0k2SWtwdmFHNGdSRzlsSWl3aWFXRjBJam94TlRFMk1qTTVNREl5TENKMWNtNDZaWGhoYlhCc1pUcGpiR0ZwYlNJNmRISjFaWDAuSDN2OHNtOV9zT0NsU0E2NWhfTUtfWnNvQml1SjB6MnBQTlMteWZxWGRVSVdsMG41VmxabGZBTnNNWWFUeWNGLUZka2RxanRzNkgtcTRMTzI3dnhGbkEiXX0.XIiemybajGhLwxE6dTsBioYCpb8vxT4x5we_lig2iMRlU2q4oXbvqAi02HpXmzd6LuTy8sOUi4OKjRaOIMb7_w

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.

Issue 67: typ for COSE

There is no registered tag for typ in COSE.

This prevents following the guidance from the JWT BCP

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, and MUST NOT 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 [VC-DATA-MODEL] describes the approach taken by JSON Web Tokens to securing claimsets 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+jwt and application/vp+ld+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 claimset (a Verifiable Credential or a Verifiable Presentation) has no integrity protection.

When a JSON Web Token claimset (a Verifiable Credential or a Verifiable Presentation) contains proof, and the JSON Web Token header contains "alg": "none", the claimset 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 claimsets that have no integrity protection.

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

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

This specification registers the application/vp+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:	vp+ld+jwt
Required parameters:	None
Encoding considerations:	`application/vp+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].	Be advised, per the [VC-DATA-MODEL], verifiable presentations are not required to be secured. This "typ" value might be paired with "alg: none", in headers.
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 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 the VC-JWT 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

Example 10: A revocable credential with multiple subjects

Claimset
Verifiable Credential
Graph

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2",
    "https://w3id.org/vc/status-list/2021/v1"
  ],
  "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"
  }]
}

---------------- Decoded Protected Header ---------------
{
  "alg": "ES384",
  "typ": "vc+ld+jwt",
  "iss": "https://contoso.example",
  "kid": "#urn:ietf:params:oauth:jwk-thumbprint:sha-256:NzbLsXh8uDCcd-6MNwX
F4W_7noWXFZAfHkxZsRGC9Xs"
}
--------------- Decoded Claimset ---------------
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2",
    "https://w3id.org/vc/status-list/2021/v1"
  ],
  "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"
    }
  ]
}
--------------- Compact Encoded JSON Web Token ---------------
eyJhbGciOiJFUzM4NCIsInR5cCI6InZjK2xkK2p3dCIsImlzcyI6Imh0dHBzOi8vY29udG9zby5
leGFtcGxlIiwia2lkIjoiI3VybjppZXRmOnBhcmFtczpvYXV0aDpqd2stdGh1bWJwcmludDpzaG
EtMjU2Ok56YkxzWGg4dURDY2QtNk1Od1hGNFdfN25vV1hGWkFmSGt4WnNSR0M5WHMifQ.eyJAY2
9udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL
3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvZXhhbXBsZXMvdjIiLCJodHRwczovL3czaWQub3Jn
L3ZjL3N0YXR1cy1saXN0LzIwMjEvdjEiXSwiaWQiOiJodHRwczovL2NvbnRvc28uZXhhbXBsZS9
jcmVkZW50aWFscy8yMzg5NDY3MjM5NCIsInR5cGUiOlsiVmVyaWZpYWJsZUNyZWRlbnRpYWwiLC
JLOVVuaXRDcmVkZW50aWFsIl0sImlzc3VlciI6eyJpZCI6Imh0dHBzOi8vY29udG9zby5leGFtc
GxlIn0sInZhbGlkRnJvbSI6IjIwMTUtMDQtMTZUMDU6MTE6MzIuNDMyWiIsImNyZWRlbnRpYWxT
dGF0dXMiOnsiaWQiOiJodHRwczovL2NvbnRvc28uZXhhbXBsZS9jcmVkZW50aWFscy9zdGF0dXM
vNCMyNzM3NjIiLCJ0eXBlIjoiU3RhdHVzTGlzdDIwMjFFbnRyeSIsInN0YXR1c1B1cnBvc2UiOi
JyZXZvY2F0aW9uIiwic3RhdHVzTGlzdEluZGV4IjoiMjczNzYyIiwic3RhdHVzTGlzdENyZWRlb
nRpYWwiOiJodHRwczovL2NvbnRvc28uZXhhbXBsZS9jcmVkZW50aWFscy9zdGF0dXMvNCJ9LCJj
cmVkZW50aWFsU3ViamVjdCI6W3siaWQiOiJkaWQ6ZXhhbXBsZToxMzEyMzg3NjQxIiwidHlwZSI
6IlBlcnNvbiJ9LHsiaWQiOiJkaWQ6ZXhhbXBsZTo2Mzg4ODIzMSIsInR5cGUiOiJEb2cifV19.P
YuT56cAZOnbEkyz87zsvO8X0z8uD1_AS9mTocli83FSGhpdbdPpnTOYTfX5HSbpVIngNCzuvI48
cT-ZSrn9W2YK3SUjUuY9jdEfOj5RNWNsWQyMVu_aQLI1ziq-P326


graph LR

0("Verifiable Credential")
1{{"id"}}
2("https://contoso.example/credentials/23894672394")
3(("type"))
4("K9UnitCredential")
5("issuer")
6{{"id"}}
7("https://contoso.example")
8("validFrom")
9("2015-04-16T05:11:32.432Z")
10("credentialStatus")
11{{"id"}}
12("https://contoso.example/credentials/status/4#273762")
13(("type"))
14("StatusList2021Entry")
15("statusPurpose")
16("revocation")
17("statusListIndex")
18("273762")
19("statusListCredential")
20("https://contoso.example/credentials/status/4")
21("credentialSubject")
22{{"id"}}
23("did:example:1312387641")
24(("type"))
25("Person")
26("credentialSubject")
27{{"id"}}
28("did:example:63888231")
29(("type"))
30("Dog")

0 --- 1
1 --- 2
0 --- 3
3 --- 4
0 --- 5
5 --- 6
6 --- 7
0 --- 8
8 --- 9
0 --- 10
10 --- 11
11 --- 12
10 --- 13
13 --- 14
10 --- 15
15 --- 16
10 --- 17
17 --- 18
10 --- 19
19 --- 20
0 --- 21
21 --- 22
22 --- 23
21 --- 24
24 --- 25
0 --- 26
26 --- 27
27 --- 28
26 --- 29
29 --- 30

Example 11: A credential with a schema

Claimset
Verifiable Credential
Graph

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

---------------- Decoded Protected Header ---------------
{
  "alg": "ES384",
  "typ": "vc+ld+jwt",
  "iss": "did:web:contoso.example",
  "kid": "#key-42"
}
--------------- Decoded Claimset ---------------
{
  "@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"
  }
}
--------------- Compact Encoded JSON Web Token ---------------
eyJhbGciOiJFUzM4NCIsInR5cCI6InZjK2xkK2p3dCIsImlzcyI6ImRpZDp3ZWI6Y29udG9zby5
leGFtcGxlIiwia2lkIjoiI2tleS00MiJ9.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vc
mcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMv
ZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwczovL2NvbnRvc28uZXhhbXBsZS9jcmVkZW50aWFscy8
zNTMyNzI1NSIsInR5cGUiOlsiVmVyaWZpYWJsZUNyZWRlbnRpYWwiLCJLWUNFeGFtcGxlIl0sIm
lzc3VlciI6ImRpZDp3ZWI6Y29udG9zby5leGFtcGxlIiwidmFsaWRGcm9tIjoiMjAxOS0wNS0yN
VQwMzoxMDoxNi45OTJaIiwidmFsaWRVbnRpbCI6IjIwMjctMDUtMjVUMDM6MTA6MTYuOTkyWiIs
ImNyZWRlbnRpYWxTY2hlbWEiOnsiaWQiOiJodHRwczovL2NvbnRvc28uZXhhbXBsZS9iYWZ5YmV
pZ2R5ci4uLmxxYWJmM29jbGd0cXk1NWZiemRpIiwidHlwZSI6Ikpzb25TY2hlbWEifSwiY3JlZG
VudGlhbFN1YmplY3QiOnsiaWQiOiJkaWQ6ZXhhbXBsZToxMjMxNTg4IiwidHlwZSI6IlBlcnNvb
iJ9fQ.PB1idxgQCTFGEr8MfKyV9u1enDHxOILu5U6ZXdRi9IIZ7yBg-wZMSirto29zZhpukx9J5
96wiB-je79yjhpRDnB2GpYev_X0RZ9wNFDRLpyaR43NWBy4dSx02NwZr13C


graph LR

31("Verifiable Credential")
32{{"id"}}
33("https://contoso.example/credentials/35327255")
34(("type"))
35("KYCExample")
36("issuer")
37("did:web:contoso.example")
38("validFrom")
39("2019-05-25T03:10:16.992Z")
40("validUntil")
41("2027-05-25T03:10:16.992Z")
42("credentialSchema")
43{{"id"}}
44("https://contoso.example/bafybeigdyr...lqabf3oclgtqy55fbzdi")
45(("type"))
46("JsonSchema")
47("credentialSubject")
48{{"id"}}
49("did:example:1231588")
50(("type"))
51("Person")

31 --- 32
32 --- 33
31 --- 34
34 --- 35
31 --- 36
36 --- 37
31 --- 38
38 --- 39
31 --- 40
40 --- 41
31 --- 42
42 --- 43
43 --- 44
42 --- 45
45 --- 46
31 --- 47
47 --- 48
48 --- 49
47 --- 50
50 --- 51

Example 12: A verifiable credential controller document

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    { "@vocab": "https://vendor.example#" }
  ],
  "id": "did:web:vendor.example",
  "alsoKnownAs": [
    "https://vendor.example",
    "did:jwk:eyJraWQiOiJ1cm46aWV0ZjpwYXJhbXM6b2F1dGg6andrLXRodW1icHJpbnQ6c2hhLTI1NjpGZk1iek9qTW1RNGVmVDZrdndUSUpqZWxUcWpsMHhqRUlXUTJxb2JzUk1NIiwia3R5IjoiT0tQIiwiY3J2IjoiRWQyNTUxOSIsImFsZyI6IkVkRFNBIiwieCI6IkFOUmpIX3p4Y0tCeHNqUlBVdHpSYnA3RlNWTEtKWFE5QVBYOU1QMWo3azQifQ"
  ],
  "verificationMethod": [
    {
      "id": "#urn:ietf:params:oauth:jwk-thumbprint:sha-256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs",
      "type": "JsonWebKey",
      "controller": "did:web:vendor.example",
      "publicKeyJwk": {
        "kty": "EC",
        "crv": "P-521",
        "alg": "ES512",
        "x": "AFTyMw-fIYJNg6fBVJvOPOsLxmnNj8HgqMChyRL0swLaefVAc7wrWZ8okQJqMmvv03JRUp277meQZM3JcvXFkH1v",
        "y": "ALn96CrD88b4TClmkl1sk0xk2FgAIda97ZF8TUOjbeWSzbKnN2KB6pqlpbuJ2xIRXvsn5BWQVlAT2JGpGwDNMyV1"
      }
    },
    {
      "id": "#z6MkhEdpG12jyQegrr62ACRmNY8gc531W2j9Xo39cHphuCEH",
      "type": "JsonWebKey2020",
      "controller": "https://vendor.example",
      "publicKeyJwk": {
        "kid": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:FfMbzOjMmQ4efT6kvwTIJjelTqjl0xjEIWQ2qobsRMM",
        "kty": "OKP",
        "crv": "Ed25519",
        "alg": "EdDSA",
        "x": "ANRjH_zxcKBxsjRPUtzRbp7FSVLKJXQ9APX9MP1j7k4"
      }
    }
    {
      "id": "#subject-authenticaton",
      "type": "JsonWebKey",
      "controller": "did:web:vendor.example",
      "publicKeyJwk": {
        "kty": "EC",
        "crv": "P-384",
        "alg": "ES384",
        "x": "PxgAmVYOQvSNcMYL2tOzoLwSWn4Ta3tIMPEUKR8pxeb-gmR11-DyKHBoIiY-2LhM",
        "y": "BZEBTkImVdpwvxR9THIRw16eblnj5-tZa7m-ww5uVd4kyPJNRoWUn2aT9ZuarAe-"
      }
    },
    {
      "id": "#credential-issuance",
      "type": "JsonWebKey",
      "controller": "did:web:vendor.example",
      "publicKeyJwk": {
        "kty": "EC",
        "crv": "P-256",
        "alg": "ES256",
        "x": "MYvnaI87pfrn3FpTqW-yNiFcF1K7fedJiqapm20_q7c",
        "y": "9YEbT6Tyuc7xp9yRvhOUVKK_NIHkn5HpK9ZMgvK5pVw"
      }
    },
    {
      "id": "#key-agreement",
      "type": "JsonWebKey",
      "controller": "did:web:vendor.example",
      "publicKeyJwk": {
        "kty": "OKP",
        "crv": "X25519",
        "alg": "ECDH-ES+A128KW",
        "x": "qLZkSTbstvMWPTivmiQglEFWG2Ff7gNDVoVisdZTr1I"
      }
    }
  ],
  "authentication": ["#subject-authenticaton"],
  "assertionMethod": ["#credential-issuance"],
  "keyAgreement": ["#key-agreement"]
}

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.

Extract iss, sub, iat, nbf, exp, jti, and aud as registered claims.
Set aside all other claims as subject claims.
To construct the VCDM-compliant JSON:
- Set the value of @context to "https://www.w3.org/ns/credentials/v2".
- Set the value of type to ["VerifiableCredential"].
- Set the value of the issuer property to one of the following:
  - If the value of iss is a URL, use the value of iss.
  - If the value of iss is not a URL, use the concatenation of "urn:vc:" and the value of iss.
- If jti is present, set the value of id to the concatenation of "urn:vc:" and the value of jti.
- If 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].
- If 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].
- Set the value of credentialSubject to an object that contains the following properties:
  - If sub is present, set the value of the id property to the concatenation of "urn:vc:" and the value of sub.
  - Add all of the subject claims.

Example 13: application/vc+jwt mapped to application/vc+ld+json

A Verifiable Credential of type application/vc+jwt:

Example

{ 
  "iss": "https://example.edu/issuers/14",
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022,
  "urn:example:claim": true
}

The application/vc+ld+json after applying the mapping:

Example

{
  "@context": "https://www.w3.org/ns/credentials/v2",
  "type": ["VerifiableCredential"],
  "issuer": "https://example.edu/issuers/14",
  "credentialSubject": {
    "id": "urn:vc:1234567890",
    "name": "John Doe",
    "urn:example:claim": true
  }
}

Securing Verifiable Credentials using JSON Web Tokens

Abstract

Status of This Document

1. Introduction

1.1 Verifiable Credentials Data Model

2. Securing JSON

2.1 Credential Header

2.2 Credential

2.3 Verifiable Credential

3. Securing the Core VC Data Model

3.1 With JOSE

3.1.1 Securing JSON-LD VCs with JOSE

Examples

Credential Header

Credential

Verifiable Credential

3.1.2 Securing JSON-LD VPs with JOSE

Examples

Presentation Header

Presentation

Verifiable Presentation

3.2 With COSE

3.2.1 Securing JSON-LD VCs with COSE

4. Conformance

4.1 Securing Verifiable Credentials

5. IANA Considerations

5.1 `application/vc+jwt`

5.2 `application/vc+ld+jwt`

5.3 `application/vp+ld+jwt`

6. Other Considerations

6.1 Privacy Considerations

6.2 Security Considerations

6.3 Accessibility

6.4 Internationalization

7. Appendix

7.1 JSON Examples

7.2 Example Mapping

A. References

A.1 Normative references

A.2 Informative references

Securing Verifiable Credentials using JSON Web Tokens

Abstract

Status of This Document

1. Introduction

1.1 Verifiable Credentials Data Model

2. Securing JSON

2.1 Credential Header

2.2 Credential

2.3 Verifiable Credential

3. Securing the Core VC Data Model

3.1 With JOSE

3.1.1 Securing JSON-LD VCs with JOSE

Examples

Credential Header

Credential

Verifiable Credential

3.1.2 Securing JSON-LD VPs with JOSE

Examples

Presentation Header

Presentation

Verifiable Presentation

3.2 With COSE

3.2.1 Securing JSON-LD VCs with COSE

4. Conformance

4.1 Securing Verifiable Credentials

5. IANA Considerations

5.1 application/vc+jwt

5.2 application/vc+ld+jwt

5.3 application/vp+ld+jwt

6. Other Considerations

6.1 Privacy Considerations

6.2 Security Considerations

6.3 Accessibility

6.4 Internationalization

7. Appendix

7.1 JSON Examples

7.2 Example Mapping

A. References

A.1 Normative references

A.2 Informative references

5.1 `application/vc+jwt`

5.2 `application/vc+ld+jwt`

5.3 `application/vp+ld+jwt`