Notification of Revoked Access Tokens in the Authentication and Authorization for Constrained Environments (ACE) Framework
Extracted elements (31)
HASH_INPUT is derived from the content of the 'access_token' parameter in the AS-to-Client response because that is the one artifact that the AS, the client, and the RS are all able to see in some form. This ensures that the same HASH_INPUT is used regardless of CWT/JWT token format or CBOR/JSON response encoding.
The diff query mechanism and optional Cursor extension implement the Series Transfer Pattern (Appendix A, referencing [STP]), allowing incremental transfer of ordered update entries. This avoids full TRL retransmission while the Cursor extension handles cases where update history exceeds MAX_DIFF_BATCH entries per response.
An RS using the method defined in this document with CWT access tokens must attempt hash computation under both CBOR-encoded and JSON-encoded AS-to-Client response assumptions, because the RS may not know which encoding was used. Failure under the first assumption triggers a retry with the second, based on base64url decoding of TOKEN_INFO.
A requester SHOULD NOT rely solely on diff query requests to detect revoked tokens, because series items may be dropped from the update collection (bounded at MAX_N). A requester SHOULD also regularly send full query requests per an application policy.
All communications between the AS and a requester at the TRL endpoint MUST be encrypted, integrity-protected, and replay-protected. Responses from the AS MUST be bound to their corresponding requests. The AS MUST prevent access to the TRL endpoint by entities other than registered devices and authorized administrators.
An RS expecting JWT access tokens MUST perform Step 3 (compute a hash assuming JSON-encoded AS-to-Client response) and MUST perform Step 4 (compute a hash assuming CBOR-encoded AS-to-Client response), unless it is certain all pertaining tokens arrive via only one encoding type. If both are performed, the RS MUST store, maintain, and rely on both token hashes.
An RS MUST NOT accept and store an access token if its token hash is already stored, if a CWT has non-empty unprotected fields or non-conformant CBOR tag structure, or if a JSON-serialized token includes an unprotected header. This prevents replay of tokens previously revoked and later expired.
Communications between the AS and an administrator MUST be mutually authenticated, encrypted, integrity-protected, and replay-protected. Mutual authentication is REQUIRED when establishing the secure association. Suitable mechanisms include TLS/DTLS with mutual authentication or OSCORE via EDHOC.
MAX_INDEX is REQUIRED to be at least (MAX_N - 1) and is RECOMMENDED to be at least ((2^32) - 1). MAX_INDEX SHOULD be orders of magnitude greater than MAX_N to reduce the likelihood of index wraparound causing ambiguity in cursor-based diff queries.
The hash function used to compute token hashes MUST be collision resistant on byte strings and MUST be selected from the Named Information Hash Algorithm Registry. SHA-256 is mandatory to implement, consistent with RFC 6920 Section 2.
When issuing an access token that is a CWT, the AS MUST ensure all 'unprotected' fields (top-level, in 'signatures' array, in 'recipients' array) are empty (0xa0). The CWT MUST use its corresponding tagged COSE structure with the CWT CBOR tag (61) as the outer tag, tag numbers encoded at minimum length, and MUST NOT be further tagged.
When receiving a response from the TRL endpoint, a registered device MUST expunge every stored access token associated with a token hash specified in the response. An RS MUST NOT delete stored token hashes after expunging the associated access token until both conditions hold: the token has been seen and confirmed expired.
An administrator with full TRL access can derive additional information by correlating token hashes with other AS data, such as determining that accesses have been revoked for specific registered devices. Operator policies should limit administrator access to the minimum necessary.
A token hash is a binary-format identifier for an access token, computed as a named-information hash (per RFC 6920) over the HASH_INPUT value. The first byte of the token hash embeds the identifier of the hash function used. Token hashes have no relation to the 'cti' or 'jti' claims.
During registration, a device receives: the url-path to the TRL endpoint, the hash function identifier (from Named Information Hash Algorithm Registry), MAX_N (if diff queries supported), and MAX_DIFF_BATCH (if the Cursor extension is also supported). The AS maintains registration state until deregistration.
The Cursor extension for diff queries allows pagination of diff entries. The AS maintains a per-requester 'index' counter (0 to MAX_INDEX) assigned to each series item, with wraparound at MAX_INDEX. MAX_DIFF_BATCH limits entries per response. Full and diff query responses include 'cursor' (index) and 'more' (boolean) parameters when this extension is active.
The Token Revocation List (TRL) is a CBOR array of CBOR byte strings, each being the token hash of a revoked but not yet expired access token. The array MUST be treated as a set (order has no meaning). It is initialized as empty and accessible via the TRL endpoint at the AS.
The TRL endpoint (default url-path: /revoke/trl) supports only the GET method and two query types: full query (returning all current pertaining token hashes) and diff query (returning ordered diff entries of recent TRL updates). The AS MUST support full queries; diff queries are optional.
The 'ACE Token Revocation List Errors' registry is created by Section 15.5, mapping error identifiers to integer values: 0 = 'Invalid parameter value', 1 = 'Invalid set of parameters', 2 = 'Out of bound cursor value'. These appear in the 'error-id' field of 'ace-trl-error' problem detail entries.
The 'ACE Token Revocation List Parameters' registry is created by Section 15.4, mapping parameter names (full_set, diff_set, cursor, more) to CBOR integer abbreviations (0, 1, 2, 3) used in TRL endpoint response payloads.
The media type 'application/ace-trl+cbor' is registered (Section 15.1) and assigned CoAP Content-Format 262 (Section 15.2). The Custom Problem Detail key 'ace-trl-error' is registered with map key integer 1 in the 'Custom Problem Detail Keys' registry (Section 15.3).
A dishonest client can present a JWT access token to an RS via a specific encoding path (CBOR or JSON AS-to-Client response) to cause the RS to compute a different token hash from the one the AS stored. Computing and storing both possible token hashes at the RS (Section 4.3.2) neutralizes this attack.
Access to the TRL endpoint must be restricted to registered devices and authorized administrators. Registered devices see only their own pertaining token hashes (filtered by authenticated identity), while administrators see the full TRL. The AS may use an access control list of trusted administrator credentials.
An active adversary can manipulate unprotected header fields of a CWT to cause an RS to compute a different token hash than the one stored by the AS, making revocation notifications ineffective. Requiring all unprotected fields to be empty (Section 3) neutralizes this attack by ensuring deterministic CWT encoding.
There is a vulnerable time window at the RS between when an access token is revoked and when the RS learns of the revocation via TRL polling or Observe notification. During this window a client may use a revoked token successfully. Using CoAP Observe subscriptions minimizes this window.
The TRL transitions between states as follows: token hash added when a non-expired access token is revoked; token hash removed when a revoked access token expires. The AS MAY perform a single batch update adding or removing multiple token hashes at once.
Diff query success response payload is a CBOR map with a mandatory 'diff_set' parameter encoding a CBOR array of diff_entry items, each being [removed: trl_patch, added: trl_patch], where trl_patch = [* token_hash]. Entries are sorted in reverse chronological order (most recent first). CDDL: diff_entry = [removed: trl_patch, added: trl_patch].
Error responses from the TRL endpoint MAY use the problem-details format (Content-Format 'application/concise-problem-details+cbor', code 257). The payload MUST include the Custom Problem Detail entry 'ace-trl-error' (a CBOR map with mandatory 'error-id' field at key 0 and optional 'cursor' field at key 1).
Full query success response uses Content-Format 'application/ace-trl+cbor' (code 262). The payload is a CBOR map with a mandatory 'full_set' parameter encoding a CBOR array of CBOR byte strings (token hashes). The array MUST be treated as a set. CDDL: full_set_value = [* token_hash], where token_hash = bytes.
When the AS-to-Client response is CBOR-encoded (application/ace+cbor), HASH_INPUT is computed as: take BYTES (the value of the 'access_token' CBOR byte string), base64url-encode it to produce HASH_INPUT_TEXT, then use the UTF-8 binary representation of HASH_INPUT_TEXT as HASH_INPUT.
When the AS-to-Client response is JSON-encoded (application/ace+json), HASH_INPUT is the binary (UTF-8) representation of the text string conveyed by the 'access_token' parameter — the JWT string directly, or a base64url-encoded string for CWTs.