CBOR Web Token (CWT)
Extracted elements (27)
CBOR tags are explicitly excluded from claim values to avoid wasting space without adding information, since the claim definition already specifies the encoding. Future claim definitions may require CBOR tags for specific claims if needed.
CWT uses CBOR instead of JSON (as in JWT) because JSON encoding is considered inefficient for IoT systems that use low-power radio technologies. Integer map keys are used for compactness of encoding and easy comparison.
NumericDate values (exp, nbf, iat) omit the leading CBOR tag 1 (epoch-based date/time) that would logically prefix them, because the claim definition already specifies the encoding and adding the tag would waste space without adding information.
CWT is closely related to JWT and reuses JWT claim names and semantics; CWT claims should normally have a corresponding JWT claim. The CWT Claims registry is coordinated with the JWT Claims registry to avoid duplication and maintain alignment.
All claims that are not understood by implementations MUST be ignored, unless the application context requires understanding specific claims.
Claim values defined in this specification MUST NOT be prefixed with any CBOR tag (e.g., tag 1 for epoch-based date/time MUST be omitted from exp, nbf, and iat values) since the representation is already specified by the claim definition.
If any validation step fails, the CWT MUST be rejected — treated by the application as invalid input.
If present, the CWT CBOR tag MUST prefix a tagged object using one of the COSE CBOR tags.
When creating a CWT, the COSE Header MUST be valid per the COSE specification (RFC 8152), and all steps specified in RFC 8152 for the chosen COSE object type MUST be followed.
The aud (Audience) claim uses Claim Key 3 and carries a StringOrURI or array of StringOrURIs, with the same meaning and processing rules as the JWT 'aud' claim.
The cti (CWT ID) claim uses Claim Key 7 and carries a byte string value; it corresponds to the JWT 'jti' claim but uses a byte string rather than a text string.
The CWT CBOR tag (tag value 61) is an optional means for applications to declare that a CBOR data structure is a CWT; it MUST prefix a tagged COSE object (e.g., COSE_Mac0) when used.
The exp (Expiration Time) claim uses Claim Key 4 and carries a NumericDate encoded as an integer or floating-point number (CBOR numeric date without the leading tag 1).
The iat (Issued At) claim uses Claim Key 6 and carries a NumericDate encoded as an integer or floating-point number.
The iss (Issuer) claim uses Claim Key 1 and carries a StringOrURI text string value, with the same meaning and processing rules as the JWT 'iss' claim except represented as CBOR text string.
The nbf (Not Before) claim uses Claim Key 5 and carries a NumericDate encoded as an integer or floating-point number.
The sub (Subject) claim uses Claim Key 2 and carries a StringOrURI text string value, with the same meaning and processing rules as the JWT 'sub' claim.
Initial CWT Claims registry contents include key 0 (RESERVED), key 1 (iss, text string), key 2 (sub, text string), key 3 (aud, text string), key 4 (exp, integer or floating-point), key 5 (nbf, integer or floating-point), key 6 (iat, integer or floating-point), key 7 (cti, byte string).
This document creates the 'CBOR Web Token (CWT) Claims' registry with registration policies: Standards Action for integer keys -256 to 255 and length-1 strings; Specification Required for keys -65536 to -257, 256 to 65535, and length-2 strings; Expert Review for larger values; Private Use for integers below -65536.
This document registers CBOR tag 61 for 'CBOR Web Token (CWT)' in the CBOR Tags registry.
This document registers CoAP Content-Format ID 61 for the 'application/cwt' media type in the CoAP Content-Formats registry.
This document registers the 'application/cwt' media type for use in indicating that content is a CWT, intended for IoT applications sending security tokens over HTTP(S), CoAP(S), and other transports.
For Nested CWTs requiring both signing and encryption, producers normally should sign first and then encrypt the result (encrypting the signature). This prevents signature-stripping attacks and provides signer privacy; signatures over encrypted text are not valid in many jurisdictions.
The security of CWT relies on COSE protections; without protection, an adversary can modify, add, or remove claims. Recipients must be able to authenticate the party that assembled the claims, since authorization decisions depend on trust in the CWT creator.
Creating a CWT involves: (1) create CWT Claims Set, (2) serialize to binary, (3) create COSE Header, (4) apply COSE_Sign/Sign1, COSE_Mac/Mac0, or COSE_Encrypt/Encrypt0, (5) optionally repeat for nested operations, (6) optionally prepend COSE and CWT CBOR tags.
Validating a CWT requires: verify valid CBOR, strip CWT tag if present and verify COSE tag follows, determine COSE message type, verify COSE Header, validate the COSE structure per RFC 8152, handle nested CWTs recursively, and verify the payload is a valid CBOR map.
CWT Claim Keys are encoded as integers or text strings in a CBOR map (the CWT Claims Set). Integer keys 1–7 are assigned to iss, sub, aud, exp, nbf, iat, and cti respectively; key 0 is reserved.