Additional OAuth Parameters for Authentication and Authorization for Constrained Environments (ACE)
Extracted elements (22)
Although all examples are shown in CBOR, JSON MAY be used as an alternative for HTTP-based communications as specified in RFC 9200. The parameters and claims are defined in a dedicated document independent of RFC 9200 to facilitate their use in other contexts.
The restriction that an RS MUST NOT hold several asymmetric key pairs for the same algorithm exists because the RS has no way of determining which key to use before the client's identity is established, meaning authentication attempts could randomly fail based on which key the RS selects.
For multi-audience access tokens (issued for several RSs), rs_cnf MUST NOT be used; a different endpoint for acquiring RS authentication keys should be specified in such cases, though the specification of that endpoint is out of scope for this document.
An RS MUST reject a proof of possession using a key that is incompatible with the alg or key_ops parameters in the COSE_Key, with a response code equivalent to the CoAP code 4.00 (Bad Request).
An RS using asymmetric keys to authenticate to the client MUST NOT hold several different asymmetric key pairs applicable to the same authentication algorithm (e.g., when using DTLS, MUST NOT hold several asymmetric key pairs applicable to the same cipher suite).
If a COSE_Key structure in a confirmation claim or parameter contains an alg or key_ops parameter, a client MUST NOT use a key that is incompatible with the profile or PoP algorithm according to those parameters.
If an access token is issued for an audience that includes several RSs, the rs_cnf parameter MUST NOT be used, since the client cannot determine for which RS the key applies.
If CBOR is used in an interaction with the introspection endpoint, the AS MUST use the parameter mapping specified in Table 1 and the value must follow the syntax of cnf claim values from Section 3.1 of RFC 8747.
If CBOR is used, the new parameters and claims defined in this document MUST be mapped to CBOR types as specified in Table 1, using the given integer abbreviation for the map key.
It is RECOMMENDED that an AS rejects a request containing a symmetric key value in the req_cnf field (kty=Symmetric), since the AS is expected to be able to generate better symmetric keys than a constrained client.
Profiles of RFC 9200 using req_cnf MUST define the PoP method used by the AS if they allow clients to use this request parameter.
The AS MUST verify that the client really is in possession of the corresponding key when a req_cnf parameter is included in the token request.
This document is an extension to RFC 9200, and all privacy considerations from that document apply here as well. No additional privacy considerations beyond those in RFC 9200 are identified.
The cnf parameter in the AS-to-client token response is REQUIRED if the token type is 'pop' and a symmetric key is used, and MAY be present for asymmetric PoP keys. It contains the PoP key that the AS selected for the token.
The cnf parameter in the introspection response is REQUIRED if the access token subject to introspection is a PoP token, and absent otherwise. It indicates the PoP key bound to the access token.
The req_cnf parameter is an OPTIONAL field in the client-to-AS token request that contains information about the key the client would like to bind to the access token for proof of possession. Values follow the syntax and semantics of the cnf claim from RFC 8747 (CBOR) or RFC 7800 (JSON).
The rs_cnf parameter in the AS-to-client token response is OPTIONAL when token type is 'pop' and asymmetric keys are used, and MUST NOT be present otherwise. It contains the public key used by the RS to authenticate to the client.
The cnf parameter with CBOR key 8 and map value type is registered in the 'OAuth Token Introspection Response CBOR Mappings' registry established in RFC 9200, with original specification RFC 8705.
Three entries registered in the 'OAuth Parameters CBOR Mappings' registry (established by RFC 9200): req_cnf with CBOR key 4, cnf with CBOR key 8, and rs_cnf with CBOR key 41, all as map type.
Three parameters registered in the IANA 'OAuth Parameters' registry: req_cnf (token request), rs_cnf (token response), and cnf (token response), all with IETF as change controller and RFC 9201 as reference.
This document is an extension to RFC 9200, and all security considerations from that document apply here as well. No additional security considerations beyond those in RFC 9200 are identified.
CBOR mappings for the new parameters: req_cnf maps to CBOR key 4 (map type, token request); cnf maps to CBOR key 8 (map type, token response and introspection response); rs_cnf maps to CBOR key 41 (map type, token response).