JSON Web Signatures for Data Integrity Proofs

W3C Discontinued Draft

More details about this document
This version:
https://www.w3.org/TR/2024/DISC-vc-jws-2020-20240702/
Latest published version:
https://www.w3.org/TR/vc-jws-2020/
Latest editor's draft:
https://w3c.github.io/vc-jws-2020/
History:
https://www.w3.org/standards/history/vc-jws-2020/
Commit history
Editors:
Orie Steele (Transmute)
Michael Jones (Microsoft Corporation)
Feedback:
GitHub w3c/vc-jws-2020 (pull requests, new issue, open issues)

Copyright © 2024 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

Abstract

This specification describes a JSON Web Signature Suite created in 2020 for the Verifiable Credentials Data Integrity Proof specification. The Signature Suite utilizes Detached JWS signatures to provide support for a subset of the digital signature algorithms registered with IANA.

Status of This Document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This work item has been discontinued. The working group recommends using vc-jwt for securing verifiable credentials using JSON Web Signatures.

This document has been withdrawn due to resolutions from the working group, which can be reviewed here: Abandon JWS2020 in favor of pointing to VC-JWT using the JWS 2020 Readme and text in VC-JWT.

This document was published by the Verifiable Credentials Working Group as a Discontinued Draft using the Recommendation track.

Publication as a Discontinued Draft does not imply endorsement by W3C and its Members.

Publication as a Discontinued Draft implies that this document is no longer intended to advance or to be maintained. It is inappropriate to cite this document as other than abandoned work.

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.

1. Introduction

This specification defines a cryptographic suite for the purpose of creating, verifying proofs for JSON Web Signatures in conformance with the Data Integrity Proofs specification.

In general the suites uses the RDF Dataset Normalization Algorithm to transform an input document into its canonical form. The canonical representation is then hashed and signed with a detached signature algorithm.

2. Terminology

The following terms are used to describe concepts involved in the generation and verification of the Linked Data Proof signature suite.

signature suite
A specified set of cryptographic primitives typically consisting of a canonicalization algorithm, a message digest algorithm, and a signature algorithm that are bundled together by cryptographers for developers for the purposes of safety and convenience.
canonicalization algorithm
An algorithm that takes an input document that has more than one possible representation and always transforms it into a canonical form. This process is sometimes also called normalization.
message digest algorithm
An algorithm that takes a message, preferably in some canonical form and produces a cryptographic output called a digest that is often many orders of magnitude smaller than the input message. These algorithms are often 1) very fast, 2) non-reversible, 3) cause the output to change significantly when even one bit of the input message changes, and 4) make it infeasible to find two different inputs for the same output.
canonical form
The output of applying a canonicalization algorithm to an input document.
signature algorithm
An algorithm that takes an input message and produces an output value where the receiver of the message can mathematically verify that the message has not been modified in transit and came from someone possessing a particular secret.
linked data document
A document comprised of linked data.
linked data proof
A proof which is a set of attributes that represent a linked data digital proof and the parameters required to verify it as defined by RDF-N-Quads.
linked data proof document
A linked data document featuring one or more linked data proofs.
JsonWebKey2020
The type of the verification method for the signature suite JsonWebSignature2020.
JsonWebSignature2020
The type of the linked data proof for the signature suite JsonWebSignature2020.

3. Suite Definition

The JSON Web Signature signature suite 2020 MUST be used in conjunction with the signing and verification algorithms in the Data Integrity Proofs specification. The suite consists of the following algorithms:

Parameter Value Specification
canonicalization algorithm https://w3id.org/security#URDNA2015 TBD
message digest algorithm SHA-256 [RFC4634]
signature algorithm JSON Web Signature (JWS) Unencoded Payload Option [RFC7797]

3.1 JOSE Conformance

This suite support cryptographic agility, see [RFC7696]. This table maps a key type to a subset of [IANA_JOSE] supported signing and encryption algorithms.

kty crvOrSize signature keyAgreement encryption
OKP Ed25519 EdDSA ECDH-ES+A256KW
OKP X25519 ECDH ECDH-ES+A256KW
EC secp256k1 ES256K ECDH ECDH-ES+A256KW
EC P-256 ES256 ECDH ECDH-ES+A256KW
EC P-384 ES384 ECDH ECDH-ES+A256KW
RSA 2048+ PS256 RSA-OAEP

3.2 Verification Method

The cryptographic material used to verify a linked data proof is called the verification method.

This suite relies on public key material represented using [RFC7517].

This suite supports public key use for both digital signature verification, according to [RFC7515], and key agreement according to [RFC8037].

This suite MAY be used to verify linked data proofs produced by key material in any representation that can be converted to JWK, however it is RECOMMENDED that this suite be used with verification method's of type JsonWebKey2020.

3.2.1 JSON Web Key 2020

The id of the verification method SHOULD be the JWK thumbprint calculated from the publicKeyJwk property value according to [RFC7638].

The type of the verification method SHOULD be JsonWebKey2020.

The controller of the verification method SHOULD be a URI.

The publicKeyJwk property of the verification method SHOULD be a JWK formatted according to [RFC7517].

Be careful not to accidentally publish the JWK representation of a private key. See rfc7517#appendix-A.2 for examples of private key representations. The property publicKeyJwk MUST never contain "d".

Example 1 
{
  "id": "https://example.com/issuer/123#ovsDKYBjFemIy8DVhc-w2LSi8CvXMw2AYDzHj04yxkc",
  "type": "JsonWebKey2020",
  "controller": "https://example.com/issuer/123",
  "publicKeyJwk": {
    "kty": "OKP",
    "crv": "Ed25519",
    "x": "CV-aGlld3nVdgnhoZK0D36Wk-9aIMlZjZOK2XhPMnkQ"
  }
}
Example 2: Example in DID Document. 
{
  "@context": ["https://www.w3.org/ns/did/v1", "https://w3id.org/security/suites/jws-2020/v1"],
  "id": "did:example:123",
  "verificationMethod": [
    {
      "id": "did:example:123#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A",
      "type": "JsonWebKey2020",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "OKP",
        "crv": "Ed25519",
        "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ"
      }
    },
    {
      "id": "did:example:123#4SZ-StXrp5Yd4_4rxHVTCYTHyt4zyPfN1fIuYsm6k3A",
      "type": "JsonWebKey2020",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "EC",
        "crv": "secp256k1",
        "x": "Z4Y3NNOxv0J6tCgqOBFnHnaZhJF6LdulT7z8A-2D5_8",
        "y": "i5a2NtJoUKXkLm6q8nOEu9WOkso1Ag6FTUT6k_LMnGk"
      }
    },
    {
      "id": "did:example:123#n4cQ-I_WkHMcwXBJa7IHkYu8CMfdNcZKnKsOrnHLpFs",
      "type": "JsonWebKey2020",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "RSA",
        "e": "AQAB",
        "n": "omwsC1AqEk6whvxyOltCFWheSQvv1MExu5RLCMT4jVk9khJKv8JeMXWe3bWHatjPskdf2dlaGkW5QjtOnUKL742mvr4tCldKS3ULIaT1hJInMHHxj2gcubO6eEegACQ4QSu9LO0H-LM_L3DsRABB7Qja8HecpyuspW1Tu_DbqxcSnwendamwL52V17eKhlO4uXwv2HFlxufFHM0KmCJujIKyAxjD_m3q__IiHUVHD1tDIEvLPhG9Azsn3j95d-saIgZzPLhQFiKluGvsjrSkYU5pXVWIsV-B2jtLeeLC14XcYxWDUJ0qVopxkBvdlERcNtgF4dvW4X00EHj4vCljFw"
      }
    },
    {
      "id": "did:example:123#_TKzHv2jFIyvdTGF1Dsgwngfdg3SH6TpDv0Ta1aOEkw",
      "type": "JsonWebKey2020",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "EC",
        "crv": "P-256",
        "x": "38M1FDts7Oea7urmseiugGW7tWc3mLpJh6rKe7xINZ8",
        "y": "nDQW6XZ7b_u2Sy9slofYLlG03sOEoug3I0aAPQ0exs4"
      }
    },
    {
      "id": "did:example:123#8wgRfY3sWmzoeAL-78-oALNvNj67ZlQxd1ss_NX1hZY",
      "type": "JsonWebKey2020",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "EC",
        "crv": "P-384",
        "x": "GnLl6mDti7a2VUIZP5w6pcRX8q5nvEIgB3Q_5RI2p9F_QVsaAlDN7IG68Jn0dS_F",
        "y": "jq4QoAHKiIzezDp88s_cxSPXtuXYFliuCGndgU4Qp8l91xzD1spCmFIzQgVjqvcP"
      }
    },
    {
      "id": "did:example:123#NjQ6Y_ZMj6IUK_XkgCDwtKHlNTUTVjEYOWZtxhp1n-E",
      "type": "JsonWebKey2020",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "EC",
        "crv": "P-521",
        "x": "AVlZG23LyXYwlbjbGPMxZbHmJpDSu-IvpuKigEN2pzgWtSo--Rwd-n78nrWnZzeDc187Ln3qHlw5LRGrX4qgLQ-y",
        "y": "ANIbFeRdPHf1WYMCUjcPz-ZhecZFybOqLIJjVOlLETH7uPlyG0gEoMWnIZXhQVypPy_HtUiUzdnSEPAylYhHBTX2"

      }
    }
  ],
  "authentication": [
    "did:example:123#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A",
    "did:example:123#4SZ-StXrp5Yd4_4rxHVTCYTHyt4zyPfN1fIuYsm6k3A",
    "did:example:123#n4cQ-I_WkHMcwXBJa7IHkYu8CMfdNcZKnKsOrnHLpFs",
    "did:example:123#_TKzHv2jFIyvdTGF1Dsgwngfdg3SH6TpDv0Ta1aOEkw",
    "did:example:123#8wgRfY3sWmzoeAL-78-oALNvNj67ZlQxd1ss_NX1hZY",
    "did:example:123#NjQ6Y_ZMj6IUK_XkgCDwtKHlNTUTVjEYOWZtxhp1n-E"
  ],
  "assertionMethod": [
    "did:example:123#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A",
    "did:example:123#4SZ-StXrp5Yd4_4rxHVTCYTHyt4zyPfN1fIuYsm6k3A",
    "did:example:123#n4cQ-I_WkHMcwXBJa7IHkYu8CMfdNcZKnKsOrnHLpFs",
    "did:example:123#_TKzHv2jFIyvdTGF1Dsgwngfdg3SH6TpDv0Ta1aOEkw",
    "did:example:123#8wgRfY3sWmzoeAL-78-oALNvNj67ZlQxd1ss_NX1hZY",
    "did:example:123#NjQ6Y_ZMj6IUK_XkgCDwtKHlNTUTVjEYOWZtxhp1n-E"
  ],
  "capabilityDelegation": [
    "did:example:123#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A",
    "did:example:123#4SZ-StXrp5Yd4_4rxHVTCYTHyt4zyPfN1fIuYsm6k3A",
    "did:example:123#n4cQ-I_WkHMcwXBJa7IHkYu8CMfdNcZKnKsOrnHLpFs",
    "did:example:123#_TKzHv2jFIyvdTGF1Dsgwngfdg3SH6TpDv0Ta1aOEkw",
    "did:example:123#8wgRfY3sWmzoeAL-78-oALNvNj67ZlQxd1ss_NX1hZY",
    "did:example:123#NjQ6Y_ZMj6IUK_XkgCDwtKHlNTUTVjEYOWZtxhp1n-E"
  ],
  "capabilityInvocation": [
    "did:example:123#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A",
    "did:example:123#4SZ-StXrp5Yd4_4rxHVTCYTHyt4zyPfN1fIuYsm6k3A",
    "did:example:123#n4cQ-I_WkHMcwXBJa7IHkYu8CMfdNcZKnKsOrnHLpFs",
    "did:example:123#_TKzHv2jFIyvdTGF1Dsgwngfdg3SH6TpDv0Ta1aOEkw",
    "did:example:123#8wgRfY3sWmzoeAL-78-oALNvNj67ZlQxd1ss_NX1hZY",
    "did:example:123#NjQ6Y_ZMj6IUK_XkgCDwtKHlNTUTVjEYOWZtxhp1n-E"
  ]
}

3.3 Proof Representation

The cryptographic material used to represent a linked data proof is called the proof type.

This suite relies on detached digital signatures represented using [RFC7797].

3.3.1 JSON Web Signature 2020

The verificationMethod property of the proof SHOULD be a URI. Dereferencing the verificationMethod SHOULD result in an object of type JsonWebKey2020.

The type property of the proof MUST be JsonWebSignature2020.

The created property of the proof MUST be an [ISO_8601] formatted date string.

The proofPurpose property of the proof MUST be a string, and SHOULD match the verification relationship expressed by the verification method controller.

The jws property of the proof MUST be a detached JWS produced according to [RFC7797].

The header of the detached JWS MUST look like this: {"b64":false,"crit":["b64"],"alg":"PS256"} where alg is a value registered in [IANA_JOSE] AND is present in the supported algorithms table of this suite.

4. Test Vectors

The following test vectors are provided to assist with implementers.

Example 3 
{
  "seed_0": "9b937b81322d816cfab9d5a3baacc9b2a5febe4b149f126b3630f93a29527017"
}
Example 4 
{
  "keypair_0": {
    "id": "#ovsDKYBjFemIy8DVhc-w2LSi8CvXMw2AYDzHj04yxkc",
    "type": "JsonWebKey2020",
    "controller": "did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP",
    "publicKeyJwk": {
      "kty": "OKP",
      "crv": "Ed25519",
      "x": "CV-aGlld3nVdgnhoZK0D36Wk-9aIMlZjZOK2XhPMnkQ"
    },
    "privateKeyJwk": {
      "kty": "OKP",
      "crv": "Ed25519",
      "x": "CV-aGlld3nVdgnhoZK0D36Wk-9aIMlZjZOK2XhPMnkQ",
      "d": "m5N7gTItgWz6udWjuqzJsqX-vksUnxJrNjD5OilScBc"
    }
  },
  "keypair_1": {
    "id": "#zaS0k3zk2KpT4NqqpdUA1YD0JVTOtQf3pNoKDI-wes0",
    "type": "JsonWebKey2020",
    "controller": "did:key:zQ3shP2mWsZYWgvgM11nenXRTx9L1yiJKmkf9dfX7NaMKb1pX",
    "publicKeyJwk": {
      "kty": "EC",
      "crv": "secp256k1",
      "x": "GBMxavme-AfIVDKqI6WBJ4V5wZItsxJ9muhxPByllHQ",
      "y": "SChlfVBhTXG_sRGc9ZdFeCYzI3Kbph3ivE12OFVk4jo"
    },
    "privateKeyJwk": {
      "kty": "EC",
      "crv": "secp256k1",
      "x": "GBMxavme-AfIVDKqI6WBJ4V5wZItsxJ9muhxPByllHQ",
      "y": "SChlfVBhTXG_sRGc9ZdFeCYzI3Kbph3ivE12OFVk4jo",
      "d": "m5N7gTItgWz6udWjuqzJsqX-vksUnxJrNjD5OilScBc"
    }
  },
  "keypair_2": {
    "id": "#zwlFQYyCqQXZ3nzpxkxJFxlpGU2l8LZQ9gxIxDdEhuY",
    "type": "JsonWebKey2020",
    "controller": "did:key:zUewtYk1yGS3SWp7kxrFK3DZRHMFbGEnrgFrqsi6hG8Z7EpRzbMP7d5y49HhrUv4tgV4DHCSoQUtF1NRNe43bymdi7K91PkwEGJRR4jv4Vb2mu2ZcBJXbw3d35JfqsVeLcwXFUi",
    "publicKeyJwk": {
      "kty": "EC",
      "crv": "P-384",
      "x": "eQbMauiHc9HuiqXT894gW5XTCrOpeY8cjLXAckfRtdVBLzVHKaiXAAxBFeVrSB75",
      "y": "YOjxhMkdH9QnNmGCGuGXJrjAtk8CQ1kTmEEi9cg2R9ge-zh8SFT1Xu6awoUjK5Bv"
    },
    "privateKeyJwk": {
      "kty": "EC",
      "crv": "P-384",
      "x": "eQbMauiHc9HuiqXT894gW5XTCrOpeY8cjLXAckfRtdVBLzVHKaiXAAxBFeVrSB75",
      "y": "YOjxhMkdH9QnNmGCGuGXJrjAtk8CQ1kTmEEi9cg2R9ge-zh8SFT1Xu6awoUjK5Bv",
      "d": "dXghMAzYZmv46SNRuxmfDIuAlv7XIhvlkPzW3vXsopB1ihWp47tx0hqjZmYO6fJa"
    }
  }
}
Example 5 
{
  "message_0": "hello world"
}
Example 6 
{
  "signature_0": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..v_Tni1_9lPQsS52GOnCMTFp7vDRjZIcj3pmuY1mF9W7nMAH94DpGecNwdFsXrz09n9bDTd8gJFqXWZeWIGvUAA",
  "signature_1": "eyJhbGciOiJFUzI1NksiLCJiNjQiOmZhbHNlLCJjcml0IjpbImI2NCJdfQ..dsgrLHXb5-VsUKVop4JJyO9dkFvJKRVNeOcEDD9nBAl3MqzJrJYfEfL8wArG-9ZjL12UD8btrJljZ7_C8p51mA"
}
Example 7 
{
  "issuer_0": {
    "@context": [
      "https://www.w3.org/ns/did/v1",
      "https://w3id.org/security/suites/jws-2020/v1",
      {
        "@base": "https://example.com/issuer/123"
      }
    ],
    "id": "https://example.com/issuer/123",
    "verificationMethod": [
      {
        "id": "#ovsDKYBjFemIy8DVhc-w2LSi8CvXMw2AYDzHj04yxkc",
        "type": "JsonWebKey2020",
        "controller": "https://example.com/issuer/123",
        "publicKeyJwk": {
          "kty": "OKP",
          "crv": "Ed25519",
          "x": "CV-aGlld3nVdgnhoZK0D36Wk-9aIMlZjZOK2XhPMnkQ"
        }
      }
    ],
    "assertionMethod": ["#ovsDKYBjFemIy8DVhc-w2LSi8CvXMw2AYDzHj04yxkc"]
  }
}
Example 8 
{
  "vc_template_0": {
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1",
      "https://w3id.org/security/suites/jws-2020/v1"
    ],
    "id": "http://example.gov/credentials/3732",
    "type": ["VerifiableCredential", "UniversityDegreeCredential"],
    "issuer": { "id": "did:example:123" },
    "issuanceDate": "2020-03-10T04:24:12.164Z",
    "credentialSubject": {
      "id": "did:example:456",
      "degree": {
        "type": "BachelorDegree",
        "name": "Bachelor of Science and Arts"
      }
    }
  },
  "vc_0": {
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1",
      "https://w3id.org/security/suites/jws-2020/v1"
    ],
    "id": "http://example.gov/credentials/3732",
    "type": ["VerifiableCredential", "UniversityDegreeCredential"],
    "issuer": {
      "id": "https://example.com/issuer/123"
    },
    "issuanceDate": "2020-03-10T04:24:12.164Z",
    "credentialSubject": {
      "id": "did:example:456",
      "degree": {
        "type": "BachelorDegree",
        "name": "Bachelor of Science and Arts"
      }
    },
    "proof": {
      "type": "JsonWebSignature2020",
      "created": "2019-12-11T03:50:55Z",
      "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..MJ5GwWRMsadCyLNXU_flgJtsS32584MydBxBuygps_cM0sbU3abTEOMyUvmLNcKOwOBE1MfDoB1_YY425W3sAg",
      "proofPurpose": "assertionMethod",
      "verificationMethod": "https://example.com/issuer/123#ovsDKYBjFemIy8DVhc-w2LSi8CvXMw2AYDzHj04yxkc"
    }
  }
}

5. Conformance

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, 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 document is any concrete expression of the data model that complies with the normative statements in this specification. Specifically, all relevant normative statements in Sections 2. Terminology and 3. Suite Definition of this document MUST be enforced.

A conforming processor is any algorithm realized as software and/or hardware that generates or consumes a conforming document. Conforming processors MUST produce errors when non-conforming documents are consumed.

This document also contains examples that contain JSON and JSON-LD content. Some of these examples contain characters that are invalid JSON, such as inline comments (//) and the use of ellipsis (...) to denote information that adds little value to the example. Implementers are cautioned to remove this content if they desire to use the information as valid JSON or JSON-LD.

6. Privacy Considerations

Issue 1
TODO: We need to add a complete list of privacy considerations.

7. Security Considerations

The following section describes security considerations that developers implementing this specification should be aware of in order to create secure software.

Note

This specification relies on URDNA2015.

Note

This specification relies on [IANA_JOSE], please review [RFC8725].

Issue 2
TODO: We need to add a complete list of security considerations.

A. References

A.1 Normative references

[IANA_JOSE]
JOSE. URL: https://www.iana.org/assignments/jose/jose.xhtml
[ISO_8601]
ISO_8601. URL: https://en.wikipedia.org/wiki/ISO_8601
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC4634]
US Secure Hash Algorithms (SHA and HMAC-SHA). D. Eastlake 3rd; T. Hansen. IETF. July 2006. Informational. URL: https://www.rfc-editor.org/rfc/rfc4634
[RFC7515]
JSON Web Signature (JWS). M. Jones; J. Bradley; N. Sakimura. IETF. May 2015. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7515
[RFC7517]
JSON Web Key (JWK). M. Jones. IETF. May 2015. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7517
[RFC7638]
JSON Web Key (JWK) Thumbprint. M. Jones; N. Sakimura. IETF. September 2015. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7638
[RFC7696]
Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms. R. Housley. IETF. November 2015. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc7696
[RFC7797]
JSON Web Signature (JWS) Unencoded Payload Option. M. Jones. IETF. February 2016. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7797
[RFC8037]
CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE). I. Liusvaara. IETF. January 2017. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc8037
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174

A.2 Informative references

[RFC8725]
JSON Web Token Best Current Practices. Y. Sheffer; D. Hardt; M. Jones. IETF. February 2020. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8725