JWT Profile

Where a definition uses JWT it SHALL conform to the following profile:

The payload is contained within a JSON Web Tokens (JWT) ~ RFC 7519 signed as per JSON Web Signature (JWS) ~ RFC 7515. The signed JWT is used as the payload to a JSON Web Encryption (JWE) ~ RFC 7516.

All definitions are as per the RFCs unless otherwise stated.

Note: All times will be UTC.

UUID Definition

All references to UUIDs refer to UUID (version 4); 128-bits in length as defined in RFC 4122 in their textual representation as defined in section 3 “Namespace Registration Template” without the “urn:uuid:” prefix e.g. “f81d4fae-7dec-11d0-a765-00a0c91e6bf6”.

All UUIDs MUST be randomly generated such that there is negligible probability that the same value will be used twice, even across multiple servers. The same UUID value MUST NOT appear twice in the same JWT in any claim.

JWS Protected Header

JWS Protected Header SHALL contain the following claims:

JWT Payload

All JWT payloads SHALL include the follow claims:
‘tx_id’ - Set to a random UUID.
  • Transaction ID used to trace a transaction through the whole system.
  • MUST NOT be the same as the ‘jti’ value.
‘jti’ - Set to a random UUID. See RFC 7519 definition of the ‘jti’ claim.
  • ‘jti’ claim MUST NOT be the same value as the ‘tx_id’ in the JWT Payload (see UUID Definition).

The JWT payload can also contain specific other data (claims) defined in the definitions within this website.

Signing

JWT Protected Header and JWT Payload are signed with RSASSA-PKCS1-v1_5 using SHA-256 (RSA-SHA256) using a Private Key to form a JWS.

JWE Header

JWE header will include the ‘alg’ and ‘enc’ claims:

Encrypting

The encrypted signed JWT is used as the payload to a JWE.

The JWE header is used as the Additional Authenticated Data

A 256-bit random CEK and 96-bit IV is generated by the creator of the JWT.

The entire JWT is encrypted with AES-256-GCM using the generated CEK and IV and the Additional Authenticated Data. This process outputs a 128-bit Authentication Tag.

The CEK is encrypted with the JWT receivers public key using the RSAES-OAEP algorithm to produce the JWE Encrypted Key

The JWE is formed from the above values concatenated together (see RFC7516).

Decrypting

JWE payload is decrypted (reverse of encryption process) by JWT receiver using their private key; revealing the signed JWT.

Verifying

Signature of JWT verified by the receiver using the Public Key of the creator of the JWT.

Only the RSA-SHA256 algorithm will be accepted, all other algorithms (including None) are rejected.