]> Short Distribution Chain (SDC) Workflow and New OAuth Parameters for the Authentication and Authorization for Constrained Environments (ACE) Framework RISE AB
Isafjordsgatan 22 Kista 16440 Sweden marco.tiloca@ri.se
Ericsson AB
Torshamnsgatan 23 Kista 16440 Stockholm Sweden goran.selander@ericsson.com
Security ACE Working Group Internet-Draft This document updates the Authentication and Authorization for Constrained Environments Framework (ACE, RFC 9200) as follows. (1) It defines the Short Distribution Chain (SDC) workflow that the authorization server can use for uploading an access token to a resource server on behalf of the client. (2) For the OAuth 2.0 token endpoint, it defines new parameters and encodings, and extends the semantics of the "ace_profile" parameter. (3) It defines how the client and the authorization server can coordinate on the exchange of the client's and resource server's public authentication credentials, when those can be transported by value or identified by reference; this extends the semantics of the "rs_cnf" parameter for the OAuth 2.0 token endpoint, thus updating RFC 9201. (4) It amends two of the requirements on profiles of the framework. (5) It deprecates the original payload format of error responses conveying an error code, when CBOR is used to encode message payloads. For those responses, it defines a new payload format aligned with RFC 9290, thus updating in this respect also the profiles defined in RFC 9202, RFC 9203, and RFC 9431. About This Document Status information for this document may be found at . Discussion of this document takes place on the Authentication and Authorization for Constrained Environments (ace) Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .
Introduction The Authentication and Authorization for Constrained Environments (ACE) framework defines an architecture to enforce access control for constrained devices. A client (C) requests an assertion of granted permissions from an authorization server (AS) in the form of an access token, then uploads the access token to the target resource server (RS), and finally accesses protected resources at the RS according to the permissions specified in the access token. The framework has as main building blocks the OAuth 2.0 framework , the Constrained Application Protocol (CoAP) for message transfer, Concise Binary Object Representation (CBOR) for compact encoding, and CBOR Object Signing and Encryption (COSE) for self-contained protection of access tokens. In addition, separate profile documents define in detail how the participants in the ACE architecture communicate, especially as to the security protocols that they use. This document updates as follows.
  • It defines the Short Distribution Chain (SDC) workflow for the ACE framework (see ), according to which the AS uploads the access token to the RS on behalf of C, and then informs C about the outcome. The SDC workflow is especially convenient in deployments where the communication leg between C and the RS is constrained, but the communication leg between the AS and the RS is not. The SDC workflow has no ambition to replace the original workflow defined in . The AS can use one workflow or the other depending, for example, on the specific RS for which an access token has been issued and the nature of the communication leg with that RS.
  • It defines new parameters and encodings for the OAuth 2.0 token endpoint at the AS (see ). These include:
    • "token_upload", used by C to inform the AS that it opts in to use the SDC workflow, and by the AS to inform C about the outcome of the token uploading to the RS per the SDC workflow.
    • "token_hash", used by the AS to provide C with a token hash, corresponding to an access token that the AS has issued for C and has successfully uploaded to the RS on behalf of C per the SDC workflow.
    • "to_rs", used by C to provide the AS with information to relay to the RS, upon asking the AS to upload the access token to the RS per the SDC workflow. Its specific use with the OSCORE profile is also defined, thereby effectively enabling the use of the SDC workflow for that profile.
    • "from_rs", used by the AS to provide C with information to relay from the RS, after the AS has successfully uploaded the access token to the RS per the SDC workflow. Its specific use with the OSCORE profile is also defined, thereby effectively enabling the use of SDC workflow for that profile.
    • "rs_cnf2", used by the AS to provide C with the public keys of the RSs in the group-audience for which the access token is issued (see ).
    • "audience2", used by the AS to provide C with the identifiers of the RSs in the group-audience for which the access token is issued.
    • "anchor_cnf", used by the AS to provide C with the public keys of trust anchors, which C can use to validate the public key of an RS (e.g., as provided in the "rs_cnf" parameter defined in or in the "rs_cnf2" parameter defined in this document).
    • "token_series_id", used by the AS to provide C with the identifier of a token series, and by C to ask the AS for a new access token in the same token series that dynamically updates access rights. A corresponding access token claim, namely "token_series_id", is also defined.
  • It extends the semantics of the "ace_profile" parameter for the OAuth 2.0 token endpoint at the authorization server defined in (see ).
  • It defines how C and the AS can coordinate on the exchange of the client's and resource server's public authentication credentials, when those can be transported by value or identified by reference in the access token request and response (see ). This extends the semantics of the "rs_cnf" parameter for the OAuth 2.0 token endpoint defined in , and therefore updates .
  • It amends two of the requirements on profiles of the ACE framework (see ).
  • It deprecates the original payload format of error responses that convey an error code, when CBOR is used to encode message payloads in the ACE framework. For such error responses, it defines a new payload format according to the problem-details format specified in (see ). In this respect, it also updates the profiles of the ACE framework defined in , , and .
Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Readers are expected to be familiar with the terms and concepts described in the ACE framework for Authentication and Authorization , as well as with terms and concepts related to CBOR Web Tokens (CWTs) and CWT Confirmation Methods . The terminology for entities in the considered architecture is defined in OAuth 2.0 . In particular, this includes client (C), resource server (RS), and authorization server (AS). Readers are also expected to be familiar with the terms and concepts related to CoAP , Concise Data Definition Language (CDDL) , CBOR , JavaScript Object Notation (JSON) , and COSE . Note that the term "endpoint" is used here following its OAuth definition , aimed at denoting resources such as /token and /introspect at the AS, and /authz-info at the RS. This document does not use the CoAP definition of "endpoint", which is "An entity participating in the CoAP protocol." Furthermore, this document uses the following terms.
  • Token series: a set of access tokens, all of which are bound to the same proof-of-possession (PoP) key and are sequentially issued by the same AS for the same pair (client, audience) per the same profile of ACE. A token series ends when the latest access token of that token series becomes invalid (e.g., when it expires or gets revoked). Profiles of ACE can provide their extended and specialized definition, e.g., by further taking into account the public authentication credentials of C and the RS.
  • Token hash: identifier of an access token, in binary format encoding. The token hash has no relation to other possibly used token identifiers, such as the 'cti' (CWT ID) claim of CBOR Web Tokens (CWTs) .
CBOR and CDDL are used in this document. CDDL predefined type names, especially bstr for CBOR byte strings and tstr for CBOR text strings, are used extensively in this document. Examples throughout this document are expressed in CBOR diagnostic notation as defined in and . Diagnostic notation comments are often used to provide a textual representation of the parameters' keys and values. In the CBOR diagnostic notation used in this document, constructs of the form e'SOME_NAME' are replaced by the value assigned to SOME_NAME in the CDDL model shown in of . For example, {e'audience2' : ["rs1", "rs2"]} stands for {53 : ["rs1", "rs2"]}. Note to RFC Editor: Please delete the paragraph immediately preceding this note. Also, in the CBOR diagnostic notation used in this document, please replace the constructs of the form e'SOME_NAME' with the value assigned to SOME_NAME in the CDDL model shown in of . Finally, please delete this note.
The Short Distribution Chain (SDC) Workflow As defined in , the ACE framework relies on its basic protocol workflow shown in . That is, the client first sends an access token request to the token endpoint at the AS (Step A), specifying permissions that it seeks to obtain for accessing protected resources at the RS, possibly together with information on its own public authentication credential. Then, if the request has been successfully verified, authenticated, and authorized, the AS replies to the client (Step B), providing an access token and possibly additional parameters as access information including the actually granted permissions. Finally, the client uploads the access token to the RS and, consistently with the permissions granted according to the access token, accesses a resource at the RS (Step C), which replies with the result of the resource access (Step F). Details about what protocol the client and the RS use to establish a secure association, mutually authenticate, and secure their communications are defined in the specific profile of ACE used, e.g., . Further interactions are possible between the AS and the RS, i.e., the exchange of an introspection request and response where the AS validates a previously issued access token for the RS (Steps D and E).
ACE Basic Protocol Workflow. | | | | | Authorization | | |<--(B)-- Access Token ---------| Server | | | + Access Information | | | | + Refresh Token (optional) +---------------+ | | ^ | | | Introspection Request (D)| | | Client | Response | |(E) | | (optional exchange) | | | | | v | | +--------------+ | |---(C)-- Token + Request ----->| | | | | Resource | | |<--(F)-- Protected Resource ---| Server | | | | | +--------+ +--------------+ ]]>
This section defines the alternative Short Distribution Chain (SDC) workflow shown in , which MAY be supported by the AS. Unlike in the original workflow defined in , the AS uploads the access token to the RS on behalf of the client, and then informs the client about the outcome. If the token uploading has been successfully completed, the client typically does not need to obtain the access token from the AS altogether. Instead, the client simply establishes a secure association with the RS (if that has not happened already), and then accesses protected resources at the RS according to the permissions granted per the access token and specified by the AS as access information.
ACE Short Distribution Chain (SDC) Workflow. | | | | | Authorization | | |<--(B)-- Token Response -------| Server | | | + Access Information | | | | + Access Token (optional) +----------------------------+ | | + Refresh Token (optional) ^ | | ^ | | | | | | Token-Upload | | Introspection Request (D)| | (A1)| | Request | Client | Response | |(E) | |(A2) Response | | (optional exchange) | | | | | | | v v | | | +----------------------------+ | |---(C1)-- Token (Optional) --->| | | | | | | |---(C2)-- Protected Request -->| Resource | | | | Server | | |<--(F)--- Protected Resource --| | | | | | +--------+ +----------------------------+ ]]>
More specifically, the SDC workflow consists of the following steps.
  • Step A - Like in the original workflow, the client sends an access token request to the token endpoint at the AS, with the additional indication that it opts in to use the SDC workflow. As defined in , this information is conveyed to the AS by means of the "token_upload" parameter. The parameter also specifies what the AS has to return in the access token response at Step B, following a successful uploading of the access token from the AS to the RS.
  • Step A1 - This new step consists of the AS uploading the access token to the RS, typically at the authz-info endpoint, just like the client does in the original workflow.
  • Step A2 - This new step consists of the RS replying to the AS, following the uploading of the access token at Step A1.
  • Step B - In the access token response, the AS tells the client that it has attempted to upload the access token to the RS, specifying the outcome of the token uploading based on the reply received from the RS at Step A2. As defined in , this information is conveyed to the client by means of the "token_upload" parameter included in the access token response. If the token uploading has failed, the access token response also includes the access token. Otherwise, the access token response includes information consistent with what was specified by the "token_upload" parameter of the access token request at Step A.
  • Step C1 - This step occurs only if the token uploading from the AS has failed, and the AS has provided the client with the access token at Step B. In such a case, the client uploads the access token to the RS just like at Step C of the original workflow.
  • Step C2 - The client attempts to access a protected resource at the RS, according to the permissions granted per the access token and specified by the AS as access information at Step B.
  • Steps D, E, and F are as in the original workflow.
The SDC workflow has no ambition to replace the original workflow defined in . The AS can use one workflow or the other depending, for example, on the specific RS for which the access token has been issued and the nature of the communication leg with that RS. When using the SDC workflow, all the communications between the AS and the RS MUST be protected, consistent with Sections and of . Unlike in the original workflow, this results in protecting also the uploading of the first access token in a token series, i.e., in addition to the uploading of the following access tokens in the token series for dynamically updating the access rights of the client. The SDC workflow is also suitable for deployments where clients are not aware of details such as the need for access tokens to be issued by the AS and uploaded at the RS. Consistent with the intended access policies, the AS can be configured to automatically issue access tokens for such clients and upload those access tokens to the RS. This means that such clients do not have to request for an access token to be issued in the first place, and instead can immediately send requests to the RS for accessing its protected resources, in accordance with the access tokens already issued and uploaded by the AS.
New Parameters The rest of this section defines a number of additional parameters and encodings for the OAuth 2.0 token endpoint at the AS.
token_upload This section defines the additional "token_upload" parameter. The parameter can be used in an access token request sent by C to the token endpoint at the AS, as well as in the successful access token response sent as reply by the AS.
  • The "token_upload" parameter is OPTIONAL in an access token request. The presence of this parameter indicates that C opts in to use the SDC workflow defined in , whose actual use for uploading the issued access token to the RS is an exclusive prerogative of the AS. This parameter can take one of the following integer values. When the access token request is encoded in CBOR, those values are encoded as CBOR unsigned integers. The value of the parameter determines whether the follow-up successful access token response will have to include certain information, in case the AS has successfully uploaded the access token to the RS.
    • 0: The access token response will have to include neither the access token nor its corresponding token hash.
    • 1: The access token response will have to include the token hash corresponding to the access token, but not the access token.
    • 2: The access token response will have to include the access token, but not the corresponding token hash.
    If the AS supports the SDC workflow and the access token request includes the "token_upload" parameter with value 0, 1, or 2, then the AS MAY use the SDC workflow to upload the access token to the RS on behalf of C. Otherwise, following that access token request, the AS MUST NOT use the SDC workflow.
  • The "token_upload" parameter is REQUIRED in a successful access token response with response code 2.01 (Created), if both the following conditions apply. Otherwise, the "token_upload" parameter MUST NOT be present.
    • The corresponding access token request included the "token_upload" parameter, with value 0, 1, or 2.
    • The AS has attempted to upload the issued access token to the RS as per the SDC workflow, irrespective of the result of the token upload.
    When the "token_upload" parameter is present in the access token response, it can take one of the following integer values. When the access token response is encoded in CBOR, those values are encoded as CBOR unsigned integers.
    • If the token upload to the RS was not successful, then the "token_upload" parameter MUST specify the value 1. In this case, the access token response MUST include the "access_token" parameter specifying the issued access token.
    • If the token upload at the RS was successful, then the "token_upload" parameter MUST specify the value 0. In this case, the access token response can include additional parameters as defined below, depending on the value of the "token_upload" parameter in the corresponding access token request.
      • If the "token_upload" parameter in the access token request specified the value 0, then the access token response MUST NOT include the "access_token" parameter and MUST NOT include the "token_hash" parameter defined in .
      • If the "token_upload" parameter in the access token request specified the value 1, then the access token response MUST NOT include the "access_token" parameter and MUST include the "token_hash" parameter defined in , specifying the hash corresponding to the issued access token and computed as defined in .
      • If the "token_upload" parameter in the access token request specified the value 2, then the access token response MUST include the "access_token" parameter specifying the issued access token and MUST NOT include the "token_hash" parameter defined in .
Examples shows an example with first an access token request from C to the AS, and then an access token response from the AS to C, following the issue of an access token bound to a symmetric PoP key. The access token request specifies the "token_upload" parameter with value 0. That is, C indicates that it requires neither the access token nor the corresponding token hash from the AS, in case the AS successfully uploads the access token to the RS. The access token response specifies the "token_upload" parameter with value 0, which indicates that the AS has successfully uploaded the access token to the RS on behalf of C. Consistent with the value of the "token_upload" parameter in the access token request, the access token response includes neither the access token nor its corresponding token hash. The access token response also includes the "cnf" parameter specifying the symmetric PoP key bound to the access token.
Example of Access Token Request-Response Exchange. Following a successful uploading of the access token from the AS to the RS, the access token response includes the "token_upload" parameter but not the access token, which is bound to a symmetric key and was uploaded to the RS by the AS.
shows another example with first an access token request from C to the AS, and then an access token response from the AS to C, following the issue of an access token bound to a symmetric PoP key. The access token request specifies the "token_upload" parameter with value 2. That is, C indicates that it requires the access token from the AS, even in case the AS successfully uploads the access token to the RS. The access token response specifies the "token_upload" parameter with value 0, which indicates that the AS has successfully uploaded the access token to the RS on behalf of C. Consistent with the value of the "token_upload" parameter in the access token request, the access token response includes the "access_token" parameter specifying the issued access token. The access token response also includes the "cnf" parameter specifying the symmetric PoP key bound to the access token.
Example of Access Token Request-Response Exchange. Following a successful uploading of the access token from the AS to the RS, the access token response includes the "token_upload" parameter as well as the "access_token" parameter conveying the access token, which is bound to a symmetric key and was uploaded to the RS by the AS.
shows another example with first an access token request from C to the AS, and then an access token response from the AS to C, also following the issue of an access token bound to a symmetric PoP key. The access token request specifies the "token_upload" parameter with value 0. That is, C indicates that it requires neither the access token nor the corresponding token hash from the AS, in case the AS successfully uploads the access token to the RS. In this example, the access token response includes the "token_upload" parameter with value 1, which indicates that the AS has attempted and failed to upload the access token to the RS on behalf of C. The access token response also includes the "access_token" parameter specifying the issued access token, together with the "cnf" parameter specifying the symmetric PoP key bound to the access token. Note that, even though the AS has failed to upload the access token to the RS, the response code 2.01 (Created) is used when replying to C, since the access token request as such has been successfully processed at the AS, with the following issue of the access token.
Example of Access Token Request-Response Exchange. Following a failed uploading of the access token from the AS to the RS, the access token response includes the "token_upload" parameter with value 1 as well the "access_token" parameter conveying the access token bound to a symmetric key.
token_hash This section defines the additional "token_hash" parameter. The parameter can be used in a successful access token response sent as reply by the AS to C. The following refers to the base64url encoding without padding (see ), and denotes as "binary representation" of a text string the corresponding UTF-8 encoding , which is the implied charset used in JSON (see ). The "token_hash" parameter is REQUIRED in a successful access token response with response code 2.01 (Created), if both the following conditions apply. Otherwise, the "token_hash" parameter MUST NOT be present.
  • The corresponding access token request included the "token_upload" parameter with value 1.
  • The access token response includes the "token_upload" parameter with value 0. That is, the AS has successfully uploaded the issued access token to the RS, as per the SDC workflow.
This parameter specifies the token hash corresponding to the access token issued by the AS and successfully uploaded to the RS on behalf of C. In particular:
  • If the access token response is encoded in CBOR, then the "token_hash" parameter is a CBOR byte string, with value the token hash.
  • If the access token response is encoded in JSON, then the "token_hash" parameter has as value the base64url-encoded text string that encodes the token hash.
The AS computes the token hash as defined in .
Computing the Token Hash The AS computes the token hash over the value that the "access_token" parameter would have had in the same access token response, if it was included therein and specifying the access token. In particular, the input HASH_INPUT over which the token hash is computed is determined as follows.
  • If the access token response is encoded in CBOR, then:
    • BYTES denotes the value of the CBOR byte string that would be conveyed by the "access_token" parameter, if this was included in the access token response.
    • HASH_INPUT_TEXT is the base64url-encoded text string that encodes BYTES.
    • HASH_INPUT is the binary representation of HASH_INPUT_TEXT.
  • If the access token response is encoded in JSON, then HASH_INPUT is the binary representation of the text string conveyed by the "access_token" parameter, if this was included in the access token response.
Once determined HASH_INPUT as defined above, a hash value of HASH_INPUT is generated as per . The resulting output in binary format is used as the token hash. Note that the used binary format embeds the identifier of the used hash function, in the first byte of the computed token hash. The specifically used hash function MUST be collision-resistant on byte-strings, and MUST be selected from the "Named Information Hash Algorithm" Registry . Consistent with the compliance requirements in , the hash function sha-256 as specified in is mandatory to implement. The computation of token hashes defined above is aligned with that specified for the computation of token hashes in , where they are used as identifiers of revoked access tokens. Therefore, given a hash algorithm and an access token, the AS computes the same corresponding token hash in either case. If the AS supports the method specified in , then the AS MUST use the same hash algorithm for computing both the token hashes to include in the "token_hash" parameter and the token hashes computed per such a method to identify revoked access tokens.
Example shows an example with first an access token request from C to the AS, and then an access token response from the AS to C, following the issue of an access token bound to a symmetric PoP key. The access token request specifies the "token_upload" parameter with value 1. That is, C indicates that it requires the token hash corresponding to the access token from the AS, in case the AS successfully uploads the access token to the RS. The access token response specifies the "token_upload" parameter with value 0, which indicates that the AS has successfully uploaded the access token to the RS on behalf of C. Consistent with the value of the "token_upload" parameter in the access token request, the access token response includes the "token_hash" parameter, which specifies the token hash corresponding to the issued access token. The access token response also includes the "cnf" parameter specifying the symmetric PoP key bound to the access token.
Example of Access Token Request-Response Exchange. Following a successful uploading of the access token from the AS to the RS, the access token response includes the "token_upload" parameter as well as the "token_hash" parameter. The "token_hash" parameter conveys the token hash corresponding to the issued access token, which is bound to a symmetric key and was uploaded to the RS by the AS.
to_rs and from_rs This section defines the additional parameters "to_rs" and "from_rs". The "to_rs" parameter can be used in an access token request sent by C to the token endpoint at the AS. The "from_rs" parameter can be used in an access token response, sent by the AS in reply to a request to the token endpoint from C.
  • The "to_rs" parameter is OPTIONAL in an access token request. The presence of this parameter indicates that C wishes the AS to relay the information specified therein to the RS, when the AS uploads the issued access token to the RS per the SDC workflow defined in . This parameter MUST NOT be present if the "token_upload" parameter defined in is not present in the access token request. If present, this parameter specifies the information that C wishes the AS to relay to the RS, when uploading the access token to the RS on behalf of C. If considered together with the access token, this information is expected to consist in what C would have uploaded to the authz-info endpoint at the RS, if uploading the access token per the original workflow. When the access token request is encoded in CBOR, the value of this parameter is encoded as a CBOR byte string. The semantics and encoding of the information specified in this parameter depend on the specific profile of ACE used. defines those for when this parameter is used with the OSCORE profile .
  • The "from_rs" parameter is OPTIONAL in an access token response. The presence of this parameter indicates that the AS has to relay the information specified therein to C, which the AS has received from the RS after having successfully uploaded the access token to the RS per the SDC workflow defined in . This parameter MUST NOT be present if the "token_upload" parameter defined in is not present with value 0 in the access token response. If present, this parameter specifies the information that the AS has to relay to C from the RS, following the successful upload of the access token to the RS on behalf of C. This information is expected to consist in what C would have received in a successful response from the authz-info endpoint at the RS, if uploading the access token per the original workflow. When the access token response is encoded in CBOR, the value of this parameter is encoded as a CBOR byte string. The semantics and encoding of the information specified in this parameter depend on the specific profile of ACE used. defines those for when this parameter is used with the OSCORE profile .
Use with the OSCORE Profile This section defines the semantics and encoding of the information specified in the parameters "to_rs" and "from_rs" when used with the OSCORE profile , thereby effectively enabling the use of the SDC workflow for that profile. The value of the "to_rs" parameter is the binary representation of a CBOR map C_MAP composed of two fields:
  • A field with the CBOR unsigned integer 40 as map key, and with value the nonce N1 generated by C encoded a CBOR byte string (see ).
  • A field with the CBOR unsigned integer 43 as map key, and with value the Recipient ID ID1 generated by C and encoded as a CBOR byte string (see ).
When building the POST request for uploading the access token to the authz-info endpoint at the RS, the AS composes the request payload as specified in . In particular, the CBOR map specified as payload includes:
  • The "access_token" field, with value the access token to upload encoded as a CBOR byte string.
  • The "nonce1" field, with value the same CBOR byte string specified by the field of C_MAP that has the CBOR unsigned integer 40 as map key.
  • The "ace_client_recipientid" field, with value the same CBOR byte string specified by the field of C_MAP that has the CBOR unsigned integer 43 as map key.
In case the upload of the access token to the RS from the AS is successful, the RS replies to the AS with a 2.01 (Created) response, whose payload is a CBOR map RS_MAP that includes:
  • The "nonce2" field, with value the nonce N2 generated by the RS encoded a CBOR byte string (see ).
  • The "ace_server_recipientid" field, with value the Recipient ID ID2 generated by the RS and encoded as a CBOR byte string (see ).
The value of the "from_rs" parameter is the binary representation of a CBOR map composed of two elements:
  • A field with the CBOR unsigned integer 42 as map key, and with value the same CBOR byte string specified by the "nonce2" field of RS_MAP.
  • A field with the CBOR unsigned integer 44 as map key, and with value the same CBOR byte string specified by the "ace_server_recipientid" field of RS_MAP.
When C receives from the AS the successful access token response specifying the "token_upload" parameter with value 0, C can retrieve the nonce N2 and the Recipient ID ID2 from the "from_rs" parameter, just like when retrieving those from a 2.01 (Created) response received from the RS when using the original workflow. shows an example where the OSCORE profile is used, with first an access token request from C to the AS, and then an access token response from the AS to C, following the issue of an access token bound to a symmetric PoP key. The access token request specifies the "token_upload" parameter with value 0. That is, C indicates that it requires neither the access token nor the corresponding token hash from the AS, in case the AS successfully uploads the access token to the RS. Also, the access token request includes the "to_rs" parameter, specifying the values of N1 = 0x018a278f7faab55a and ID1 = 0x1645 intended to the RS. The access token response specifies the "token_upload" parameter with value 0, which indicates that the AS has successfully uploaded the access token to the RS on behalf of C. Consistent with the value of the "token_upload" parameter in the access token request, the access token response includes neither the access token nor its corresponding token hash. The access token response also includes the "cnf" parameter specifying the symmetric PoP key bound to the access token, as an OSCORE_Input_Material object. Also, the access token response includes the "from_rs" parameter, specifying the values of N2 = 0x25a8991cd700ac01 and ID2 = 0x0000 received from the RS and intended to C.
Example of Access Token Request-Response Exchange where the OSCORE Profile is Used. Following a successful uploading of the access token from the AS to the RS, the access token response includes the "token_upload" parameter but not the access token, which is bound to a symmetric key and was uploaded to the RS by the AS. C and the RS exchange N1, ID1, N2, and ID2 via the AS by means of the parameters "to_rs" and "from_rs"
rs_cnf2 and audience2 This section defines the additional parameters "rs_cnf2" and "audience2" for an access token response, sent by the AS in reply to a request to the token endpoint from C.
  • The "rs_cnf2" parameter is OPTIONAL if the token type is "pop", asymmetric keys are used, and the access token is issued for an audience that includes multiple RSs (i.e., a group-audience, see ). Otherwise, the "rs_cnf2" parameter MUST NOT be present. This parameter specifies information about the public keys used by the RSs of a group-audience for authenticating themselves to C, and is used in case the binding between the public keys and the corresponding RS identities are not established through other means. If this parameter is absent, either the RSs in the group-audience do not use a public key, or the AS knows that the RSs can authenticate themselves to C without additional information. If present, this parameter MUST encode a non-empty CBOR array of N elements, where N is the number of RSs in the group-audience for which the access token is issued. Each element of the CBOR array specifies the public key of one RS in the group-audience, and MUST follow the syntax and semantics of the "cnf" claim either from for CBOR-based interactions, or from for JSON-based interactions. It is not required that all the elements of the CBOR array rely on the same confirmation method. Each of the public keys may contain parameters specifying information such as the public key algorithm and use (e.g., by means of the parameters "alg" or "key_ops" in a COSE_Key structure). If such information is specified, a client MUST NOT use a public key that is incompatible with the profile of ACE used or with the PoP algorithm according to that information. An RS MUST reject a proof-of-possession that relies on such a key, and reply with a response code equivalent to the CoAP code 4.00 (Bad Request).
  • The "audience2" parameter is OPTIONAL and specifies the identifiers of the RSs in the group-audience for which the access token is issued. If present, this parameter MUST encode a non-empty CBOR array of N elements, where N is the number of RSs in the group-audience for which the access token is issued. Each element of the CBOR array in the "audience2" parameter MUST be a CBOR text string, with value the identifier of one RS in the group-audience. The element of the CBOR array referring to an RS in the group-audience SHOULD have the same value that would be used to identify that RS through the "audience" parameter of an access token request to the AS (see ) and of an access token response from the AS (see ), when requesting and issuing an access token for that individual RS. The "audience2" parameter is REQUIRED if the "rs_cnf2" parameter is present. In such a case, the i-th element of the CBOR array in the "audience2" parameter MUST be the identifier of the RS whose public key is specified as the i-th element of the CBOR array in the "rs_cnf2" parameter.
Example shows an example of access token response from the AS to C, following the issue of an access token for a group-audience composed of two RSs "rs1" and "rs2", and bound to C's public key as asymmetric PoP key. The access token response includes the access token, as well as the parameters "audience2" and "rs_cnf2". These specify the public key of the two RSs as intended recipients of the access token and the identifiers of those two RSs, respectively.
Example of access token response with an access token bound to an asymmetric key, using the parameters "audience2" and "rs_cnf2".
anchor_cnf This section defines the additional "anchor_cnf" parameter for an access token response, sent by the AS in reply to a request to the token endpoint from C. The "anchor_cnf" parameter is OPTIONAL if the token type is "pop" and asymmetric keys are used. Otherwise, the "anchor_cnf" parameter MUST NOT be present. This parameter specifies information about the public keys of trust anchors, which C can use to validate the public key of the RS/RSs included in the audience for which the access token is issued. This parameter can be used when the access token is issued for an audience including one RS or multiple RSs. If this parameter is absent, either the RS/RSs in the audience do not use a public key, or the AS knows that C can validate the public key of such RS/RSs without additional information (e.g., C has already obtained the required public keys of the involved trust anchors from the AS or through other means). If present, this parameter MUST encode a non-empty CBOR array that MUST be treated as a set, i.e., the order of its elements has no meaning. Each element of the CBOR array specifies the public key of one trust anchor, which can be used to validate the public key of at least one RS included in the audience for which the access token is issued. Each element of the CBOR array MUST follow the syntax and semantics of the "cnf" claim either from for CBOR-based interactions, or from for JSON-based interactions. It is not required that all the elements of the CBOR array rely on the same confirmation method. Each of the public keys specified in the "anchor_cnf" parameter may contain parameters specifying information such as the public key algorithm and use (e.g., by means of the parameters "alg" or "key_ops" in a COSE_Key structure). If such information is specified, a client MUST NOT use a public key that is incompatible with the profile of ACE used, or with the public keys to validate and the way to validate those. The presence of this parameter does not require that the access token response also includes the "rs_cnf" parameter defined in or the "rs_cnf2" parameter defined in of this document. That is, C may be able to obtain the public keys of the RS/RSs for which the access token is issued through other means. When the access token response includes both the "anchor_cnf" parameter and the "audience2" parameter defined in , then C MUST make sure that a public key PK_RS is associated with an RS identified by an element of "audience2", before using any of the public keys specified in "anchor_cnf" to validate PK_RS. When the access token response includes the "anchor_cnf" parameter but not the "audience2" parameter, then C can use any of the public keys specified in "anchor_cnf" to validate the public key PK_RS of any RS in the targeted audience. This allows C to use the access token with an RS that is deployed later on as part of the same audience, which is particularly useful in the case of a group-audience.
Example shows an example of access token response from the AS to C, following the issue of an access token for a group-audience, and bound to C's public key as asymmetric PoP key. The identifier of the group-audience was specified by the "audience" parameter of the access token request to the AS, is specified by the "aud" claim of the issued access token, and is not repeated in the access token response from the AS. The access token response includes the "anchor_cnf" parameter. This specifies the public key of a trust anchor that C can use to validate the public keys of any RS with which the access token is going to be used. The public key of the trust anchor is here conveyed within an X.509 certificate used as public authentication credential for that trust anchor, by means of the CWT confirmation method "x5chain" defined in .
Example of Access Token Response with an access token bound to an asymmetric key, using the "anchor_cnf" parameter.
token_series_id This section defines the additional "token_series_id" parameter. The parameter can be used in an access token request sent by C to the token endpoint at the AS, as well as in the successful access token response sent as reply by the AS.
  • The "token_series_id" parameter is OPTIONAL in an access token request. The presence of this parameter indicates that C wishes to obtain a new access token for dynamically updating its access rights. That is, the new access token is intended to be the next one in an active token series and to supersede the latest access token in that token series. This parameter MUST NOT be present if the requested access token is the first one of a new token series. If present, this parameter specifies the identifier of the token series that the new access token is intended to extend. The identifier does not change throughout the lifetime of the token series, and was provided to C in the successful access token response that the AS sent when issuing the first access token in that token series. When the access token request is encoded in CBOR, the value of this parameter is encoded as a CBOR byte string.
  • The "token_series_id" parameter is OPTIONAL in an access token response. This parameter MUST NOT be present if the issued access token is not the first one of the token series it belongs to. If present, this parameter specifies the identifier of the token series to which the issued access token belongs. When the access token response is encoded in CBOR, the value of this parameter is encoded as a CBOR byte string.
If the AS relies on the "token_series_id" parameter to exchange the identifier of token series with clients, then the following applies.
  • The value assigned to the identifier of a token series MUST be associated with all the access tokens issued by the AS for that token series, and MUST be selected from a pool that the AS exclusively controls. In particular, the triple (TS_ID, C, AUD) MUST uniquely identify a token series and its corresponding access tokens, where TS_ID is the identifier of the token series, while C and AUD are the client and the audience for which the access token is issued, respectively. The AS MUST take into account both ongoing and ended token series for selecting a new TS_ID that complies with the above requirements. Note that the ACE profile is not part of the triple, hence the requirement spans across all the ACE profiles that the AS and its registered clients/RSs support.
  • An issued access token that belongs to a token series MUST include the identifier of that token series. This allows the RS to identify the latest access token in the token series to be superseded by the issued access token. In particular, each of such access tokens MUST include a claim specifying the identifier of the token series to which the access token belongs. When CWTs are used as access tokens, this information MUST be transported in the "token_series_id" claim registered in .
If a profile of ACE relies on a construct that uses different parameters/claims to transport the identifier of a token series, then the new "token_series_id" parameter and "token_series_id" claim MUST NOT be used when using that profile. For example, a number of parameters/claims are already used to transport information that acts de facto as identifier of token series, in the PSK mode of the DTLS profile , in the OSCORE profile , and in the EDHOC and OSCORE profile .
Updated "ace_profile" Parameter This section extends the semantics of the "ace_profile" parameter defined in for the OAuth 2.0 token endpoint at the authorization server. In addition to what is specified in Sections , , and of , the following applies.
  • When sending an access token request to the token endpoint at the AS (see ), C MAY include the "ace_profile" parameter, specifying the identifier of the profile that C wishes to use towards the RS.
  • If the AS receives an access token request that includes the "ace_profile" parameter specifying the identifier of a profile, then the AS proceeds as follows. In case the AS does not issue access tokens per the profile specified in the access token request, or C and the RS do not share that profile, then the AS MUST reject the request and reply with an error response (see ). The error response MUST have a response code equivalent to the CoAP code 4.00 (Bad Request) and MUST include the error code "incompatible_ace_profiles". In case the AS issues an access token to C, the access token MUST be per the profile whose identifier was specified by the "ace_profile" parameter in the access token request. In case the AS replies to C with a successful access token response (see ), then the response MAY include the "ace_profile" parameter. If it is included in the access token response, the "ace_profile" parameter MUST specify the same profile identifier that was specified by the "ace_profile" parameter of the corresponding access token request.
Coordinating on the Exchange of Public Authentication Credentials In some profiles of ACE, it is possible for C and the RS to use public authentication credentials. Depending on the specific profile, the access token request and response exchanged between C and the AS can specify those authentication credentials as transported by value or instead identified by reference. For instance, this is the case in the EDHOC and OSCORE profile and in the DTLS profile as extended in . At some point, the AS (C) might become unable to use a credential identifier as a reference for accessing the authentication credential of C (of the RS) obtained earlier, e.g., due to having deleted the credential from the local storage. This can prevent the AS (C) from successfully processing an incoming access token request (response) that specifies the authentication credential of C (of the RS) as identified by reference. Ultimately, this can prevent the AS from issuing an access token and C from securely accessing protected resources at the RS. Conversely, unbeknown to the AS, C might already be storing the authentication credential of the RS when sending the access token request. In such a situation, the AS would specify the authentication credential of the RS by value in the access token response. However, it would be sufficient for C that the response specified the credential of the RS as identified by reference, or even that the response omitted the credential altogether. In order to allow C and the AS to coordinate on the exchange of the authentication credentials of C and the RS, the rest of this section defines:
  • How the AS can instruct C to specify its public authentication credential by value in the "req_cnf" parameter of an access token request (see ).
  • How C can instruct the AS to specify the public authentication credential(s) of the RS(s) by value or by reference in the "rs_cnf" or "rs_cnf2" parameter of an access token response (see ), or instead to omit the credential(s) from the response.
Instructing C on How to Provide its Authentication Credential When the AS receives an access token request and this includes the "req_cnf" parameter identifying the public authentication credential of C by reference, it might happen that the AS is not able to access the credential by using the specified reference. In such a case, the AS MUST reject the request and reply with an error response (see ). The error response MUST have a response code equivalent to the CoAP code 5.00 (Internal Server Error) and MUST include the error code "unknown_credential_referenced". The error code and its CBOR abbreviation are registered in and , respectively. After receiving such an error response, C can send a new access token request, where the "req_cnf" parameter specifies the authentication credential of C by value.
Instructing the AS on How to Provide the RS's Authentication Credential When C receives an access token response and this includes the "req_cnf" or "req_cnf2" parameter identifying the authentication credential(s) of the RS(s) by reference, it might happen that C is not able to access the authentication credential(s) by using the specified reference(s). Conversely, if the response includes the "rs_cnf" or "rs_cnf2" parameter specifying the authentication credential(s) of the RS(s) by value, it might happen that C has already been storing those credential(s), unbeknown to the AS. In fact, it would have been sufficient that the "rs_cnf" or "rs_cnf2" parameter identified the credential(s) by reference, or that neither parameter was included in the response. The following extends the semantics of the "rs_cnf" parameter defined in , so that C can include the "rs_cnf" parameter in an access token request. When doing so, C instructs the AS about whether and how the successful access token response should specify the authentication credential(s) of the RS(s) belonging to the targeted audience. Per its extended semantics, the "rs_cnf" parameter is also OPTIONAL to include in an access token request for requesting the first access token in a token series, if the token type is "pop" and asymmetric keys are used. Otherwise, the parameter MUST NOT be included in an access token request. When C includes the "rs_cnf" parameter in an access token request, the parameter MUST have one of the following encodings.
  • If the parameter specifies the CBOR simple value true (0xf5), then it instructs the AS to include in the successful access token response the "rs_cnf" or "rs_cnf2" parameter, specifying the authentication credential(s) of the RS(s) by value. In the successful access token response, each pertaining authentication credential MUST be specified by value.
  • If the parameter specifies the CBOR simple value false (0xf4), then it instructs the AS to include in the successful access token response the "rs_cnf" or "rs_cnf2" parameter, specifying the authentication credential(s) of the RS(s) by reference. In the successful access token response, each pertaining authentication credential MUST be specified by reference, or alternatively by value only in case that was not possible.
  • If the parameter specifies the CBOR simple value null (0xf6), then it instructs the AS to omit the "rs_cnf" and "rs_cnf2" parameters from the successful access token response. In the successful access token response, the "rs_cnf" and "rs_cnf2" parameters MUST NOT be included.
If the AS is not able to comply in the first two cases above, then the AS MUST reject the request and reply with an error response. The error response MUST have a response code equivalent to the CoAP code 5.00 (Internal Server Error). Irrespective of what "rs_cnf" specifies in the access token request, C MUST rely on the authentication credential(s) specified by the parameter "rs_cnf" or "rs_cnf2" in the access token response, as those use by the RS(s) to authenticate. If C does not currently store the authentication credential(s) of the RS(s), then C MUST NOT include the "rs_cnf" parameter specifying the CBOR simple value null (0xf6) in an access token request.
Updated Requirements on Profiles compiles a list of requirements on the profiles of ACE. This document amends two of those requirements as follows. The text of the fifth requirement
Specify the security protocol the client and RS must use to protect their communication (e.g., OSCORE or DTLS). This must provide encryption and integrity and replay protection (Section 5.8.4.3).
is replaced by the following text:
Specify the security protocol the client and RS must use to protect their communication (e.g., OSCORE or DTLS). In combination with the used communication protocol, this must provide encryption, integrity and replay protection, and a binding between requests and responses (Section 5.8.4.3 and Section 6.5).
The text of the tenth requirement
Specify the communication and security protocol for interactions between the client and AS. This must provide encryption, integrity protection, replay protection, and a binding between requests and responses (Sections 5 and 5.8).
is replaced by the following text:
Specify the communication and security protocol for interactions between the client and AS. The combined use of those protocols must provide encryption, integrity protection, replay protection, and a binding between requests and responses (Sections 5 and 5.8).
At the time of writing, all the profiles of ACE that are published as RFC (i.e., ) already comply with the two updated requirements as formulated above.
Updated Payload Format of Error Responses This section deprecates the original payload format of error responses conveying an error code, when CBOR is used to encode message payloads in the ACE framework. That format is referred to, e.g., when defining the error responses of Sections and of . Also, this section defines a new payload format that allows such error responses to convey an error code together with further error-specific information, according to the problem-details format specified in . Such error responses MUST have Content-Format set to application/concise-problem-details+cbor. The payload of these error responses MUST be a CBOR map specifying a Concise Problem Details data item (see ). The CBOR map is formatted as follows.
  • It MUST include the Custom Problem Detail entry "ace-error" registered in of this document. This entry is formatted as a CBOR map including only one field, namely "error-code". The map key for "error-code" is the CBOR unsigned integer with value 0. The value of "error-code" is a CBOR integer specifying the error code associated with the occurred error. This value is taken from the "CBOR Value" column of the "OAuth Error Code CBOR Mappings" registry . The new payload format MUST use the field "error-code" in order to convey the same information that the original payload format conveys through the "error" parameter (see, e.g., Sections and of ). The CDDL notation of the "ace-error" entry is given below.
int } ]]>
  • It MAY include further Standard Problem Detail entries or Custom Problem Detail entries (see ). The following Standard Problem Detail entries are of particular relevance for the ACE framework.
    • "detail" (map key -2): its value is a CBOR text string that specifies a human-readable, diagnostic description of the occurred error (see ). The diagnostic text is intended for software engineers as well as for device and network operators, in order to aid debugging and provide context for possible intervention. The diagnostic message SHOULD be logged by the sender of the error response. The entry "detail" is unlikely relevant in an unattended setup where human intervention is not expected. The new payload format MUST use the Standard Problem Detail entry "detail" in order to convey the same information that the original payload format conveys through the "error_description" parameter (see, e.g., Sections and of ).
    • "instance" (map key -3): its value is a URI reference identifying the specific occurrence of the error (see ). The new payload format MUST use the Standard Problem Detail entry "instance" in order to convey the same information that the original payload format conveys through the "error_uri" parameter (see, e.g., Sections and of ).
An example of error response using the problem-details format is shown in .
Example of Error Response with Problem Details.
When the ACE framework is used with CBOR for encoding message payloads, the following applies.
  • It is RECOMMENDED that authorization servers, clients, and resource servers support the payload format defined in this section.
  • Authorization servers, clients, and resource servers that support the payload format defined in this section MUST use it when composing an outgoing error response that conveys an error code.
Security Considerations The same security considerations from the ACE framework for Authentication and Authorization apply to this document, together with those from the specific profile of ACE used, e.g., . When using the problem-details format defined in for error responses, then the privacy and security considerations from Sections and of also apply. Editor's note: add more security considerations.
IANA Considerations This document has the following actions for IANA. Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.
OAuth Parameters Registry IANA is asked to add the following entries to the "OAuth Parameters" registry.
  • Name: token_upload
  • Parameter Usage Location: token request and token response
  • Change Controller: IETF
  • Reference: [RFC-XXXX]

  • Name: token_hash
  • Parameter Usage Location: token response
  • Change Controller: IETF
  • Reference: [RFC-XXXX]

  • Name: to_rs
  • Parameter Usage Location: token request
  • Change Controller: IETF
  • Reference: [RFC-XXXX]

  • Name: from_rs
  • Parameter Usage Location: token response
  • Change Controller: IETF
  • Reference: [RFC-XXXX]

  • Name: rs_cnf2
  • Parameter Usage Location: token response
  • Change Controller: IETF
  • Reference: [RFC-XXXX]

  • Name: audience2
  • Parameter Usage Location: token response
  • Change Controller: IETF
  • Reference: [RFC-XXXX]

  • Name: anchor_cnf
  • Parameter Usage Location: token response
  • Change Controller: IETF
  • Reference: [RFC-XXXX]

  • Name: token_series_id
  • Parameter Usage Location: token request and token response
  • Change Controller: IETF
  • Reference: [RFC-XXXX]
OAuth Parameters CBOR Mappings Registry IANA is asked to add the following entries to the "OAuth Parameters CBOR Mappings" registry, following the procedure specified in .
  • Name: token_upload
  • CBOR Key: TBD (value between 1 and 255)
  • Value Type: unsigned integer
  • Reference: [RFC-XXXX]
  • Original Specification: [RFC-XXXX]

  • Name: token_hash
  • CBOR Key: TBD (value between 1 and 255)
  • Value Type: unsigned integer
  • Reference: [RFC-XXXX]
  • Original Specification: [RFC-XXXX]

  • Name: to_rs
  • CBOR Key: TBD (value between 1 and 255)
  • Value Type: byte string
  • Reference: [RFC-XXXX]
  • Original Specification: [RFC-XXXX]

  • Name: from_rs
  • CBOR Key: TBD (value between 1 and 255)
  • Value Type: byte string
  • Reference: [RFC-XXXX]
  • Original Specification: [RFC-XXXX]

  • Name: rs_cnf2
  • CBOR Key: TBD (value between 1 and 255)
  • Value Type: array
  • Reference: [RFC-XXXX]
  • Original Specification: [RFC-XXXX]

  • Name: audience2
  • CBOR Key: TBD (value between 1 and 255)
  • Value Type: array
  • Reference: [RFC-XXXX]
  • Original Specification: [RFC-XXXX]

  • Name: anchor_cnf
  • CBOR Key: TBD (value between 1 and 255)
  • Value Type: array
  • Reference: [RFC-XXXX]
  • Original Specification: [RFC-XXXX]

  • Name: token_series_id
  • CBOR Key: TBD (value between 1 and 255)
  • Value Type: byte string
  • Reference: [RFC-XXXX]
  • Original Specification: [RFC-XXXX]
JSON Web Token Claims Registry IANA is asked to add the following entries to the "JSON Web Token Claims" registry, following the procedure specified in .
  • Claim Name: token_series_id
  • Claim Description: The identifier of a token series
  • Change Controller: IETF
  • Reference: [RFC-XXXX]
CBOR Web Token (CWT) Claims Registry IANA is asked to add the following entries to the "CBOR Web Token (CWT) Claims" registry, following the procedure specified in .
  • Claim Name: token_series_id
  • Claim Description: The identifier of a token series
  • JWT Claim Name: token_series_id
  • Claim Key: TBD (value between 1 and 255)
  • Claim Value Type: byte string
  • Change Controller: IETF
  • Reference: of [RFC-XXXX]
OAuth Extensions Errors Registry IANA is asked to add the following entries to the "OAuth Extensions Errors" registry within the "OAuth Parameters" registry group.
  • Name: unknown_credential_referenced
  • Usage Location: token error response
  • Protocol Extension: [RFC-XXXX]
  • Change Controller: IETF
  • Reference: of [RFC-XXXX]
OAuth Error Code CBOR Mappings Registry IANA is asked to add the following entries to the "OAuth Error Code CBOR Mappings" registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.
  • Name: unknown_credential_referenced
  • CBOR Value: TBD (value between 1 and 255)
  • Reference: [RFC-XXXX]
  • Original Specification: [RFC-XXXX]
OAuth Parameters In the "OAuth Parameters" registry within the "OAuth Parameters" registry group, IANA is asked to update the entry for "rs_cnf" as follows:
  • The "Parameter Usage Location" column specifies "token request, token response".
  • The "Reference" column specifies "[RFC9201, Section 5][RFC-XXXX, ]".
OAuth Parameters CBOR Mappings In the "OAuth Parameters CBOR Mappings" registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group, IANA is asked to update the entry for "rs_cnf" as follows:
  • The "Value Type" column specifies "True or False or Null or map".
  • The "Reference" column specifies "[RFC9201, Section 3.2][RFC-XXXX, ]".
Custom Problem Detail Keys Registry IANA is asked to register the following entry in the "Custom Problem Detail Keys" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group.
  • Key Value: TBD (value between 0 and 23)
  • Name: ace-error
  • Brief Description: Carry ACE problem details in a Concise Problem Details data item.
  • Change Controller: IETF
  • Reference: of [RFC-XXXX]
References Normative References UTF-8, a transformation format of ISO 10646 ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279. The Base16, Base32, and Base64 Data Encodings This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] The OAuth 2.0 Authorization Framework The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] Naming Things with Hashes This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and binary and human-speakable formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols. The Constrained Application Protocol (CoAP) The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. JSON Web Token (JWT) JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. The JavaScript Object Notation (JSON) Data Interchange Format JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. CBOR Web Token (CWT) CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. The Transport Layer Security (TLS) Protocol Version 1.3 This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs). Concise Binary Object Representation (CBOR) The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. CBOR Object Signing and Encryption (COSE): Structures and Process Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. CBOR Object Signing and Encryption (COSE): Initial Algorithms Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth) This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE-OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. Additional OAuth Parameters for Authentication and Authorization for Constrained Environments (ACE) This specification defines new parameters and encodings for the OAuth 2.0 token and introspection endpoints when used with the framework for Authentication and Authorization for Constrained Environments (ACE). These are used to express the proof-of-possession (PoP) key the client wishes to use, the PoP key that the authorization server has selected, and the PoP key the resource server uses to authenticate to the client. Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) This specification defines a profile of the Authentication and Authorization for Constrained Environments (ACE) framework that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS version 1.2 or later for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource-constrained server can use this protocol to delegate management of authorization information to a trusted host with less-severe limitations regarding processing power and memory. The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token. Concise Problem Details for Constrained Application Protocol (CoAP) APIs This document defines a concise "problem detail" as a way to carry machine-readable details of errors in a Representational State Transfer (REST) response to avoid the need to define new error response formats for REST APIs for constrained environments. The format is inspired by, but intended to be more concise than, the problem details for HTTP APIs defined in RFC 7807. Extension of the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) to Transport Layer Security (TLS) This document updates "Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)" (RFC 9202) by specifying that the profile applies to TLS as well as DTLS. Message Queuing Telemetry Transport (MQTT) and Transport Layer Security (TLS) Profile of Authentication and Authorization for Constrained Environments (ACE) Framework This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework to enable authorization in a publish-subscribe messaging system based on Message Queuing Telemetry Transport (MQTT). Proof-of-Possession keys, bound to OAuth 2.0 access tokens, are used to authenticate and authorize MQTT Clients. The protocol relies on TLS for confidentiality and MQTT server (Broker) authentication. Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE) Ericsson Ericsson RISE RISE This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Ephemeral Diffie-Hellman Over COSE (EDHOC) for achieving mutual authentication between an ACE-OAuth Client and Resource Server, and it binds an authentication credential of the Client to an ACE-OAuth access token. EDHOC also establishes an Object Security for Constrained RESTful Environments (OSCORE) Security Context, which is used to secure communications when accessing protected resources according to the authorization information indicated in the access token. This profile can be used to delegate management of authorization information from a resource-constrained server to a trusted host with less severe limitations regarding processing power and memory. Notification of Revoked Access Tokens in the Authentication and Authorization for Constrained Environments (ACE) Framework RISE AB Ericsson AB CMU SEI CMU SEI This document specifies a method of the Authentication and Authorization for Constrained Environments (ACE) framework, which allows an authorization server to notify clients and resource servers (i.e., registered devices) about revoked access tokens. As specified in this document, the method allows clients and resource servers to access a Token Revocation List on the authorization server by using the Constrained Application Protocol (CoAP), with the possible additional use of resource observation. Resulting (unsolicited) notifications of revoked access tokens complement alternative approaches such as token introspection, while not requiring additional endpoints on clients and resource servers. OAuth Error Code CBOR Mappings IANA Named Information Hash Algorithm IANA Secure Hash Standard NIST Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References The Group Object Security for Constrained RESTful Environments (Group OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework RISE AB RISE AB Ericsson AB This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. The profile uses Group Object Security for Constrained RESTful Environments (Group OSCORE) to provide communication security between a client and one or multiple resource servers that are members of an OSCORE group. The profile securely binds an OAuth 2.0 access token to the public key of the client associated with the private key used by that client in the OSCORE group. The profile uses Group OSCORE to achieve server authentication, as well as proof-of-possession for the client's public key. Also, it provides proof of the client's membership to the OSCORE group by binding the access token to information from the Group OSCORE Security Context, thus allowing the resource server(s) to verify the client's membership upon receiving a message protected with Group OSCORE from the client. Effectively, the profile enables fine-grained access control paired with secure group communication, in accordance with the Zero Trust principles. Additional Formats of Authentication Credentials for the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) RISE AB Ericsson AB This document updates the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE). In particular, it specifies the use of additional formats of authentication credentials for establishing a DTLS session, when peer authentication is based on asymmetric cryptography. Therefore, this document updates RFC 9202. What is defined in this document is seamlessly applicable also if the profile uses Transport Layer Security (TLS) instead, as defined in RFC 9430.
Benefits for ACE Profiles For any profile of ACE, the following holds.
  • The SDC workflow defined in is effectively possible to use. This is beneficial for deployments where the communication leg between C and the RS is constrained, but the communication leg between the AS and RS is not.
  • When the SDC workflow is used, the "token_upload" parameter defined in is used:
    • To inform the AS about C opting in to use the SDC workflow.
    • To request the AS that the follow-up successful access token response will have to include certain information, in case the AS has successfully uploaded the access token to the RS.
    • To inform C that the AS has attempted to upload the issued access token to the RS, specifying whether the uploading has succeeded or failed.
  • When the SDC workflow is used, it remains possible for C to always obtain the issued access token from the AS. That is, by specifying the value 2 for the "token_upload" parameter in the access token request, C will ensure to receive the access token from the AS, even in case the AS successfully uploads the access token to the RS on behalf of C. This is useful in profiles of ACE where C can re-upload the same access token to the RS by itself, e.g., in order to perform a key update like defined for the OSCORE profile .
DTLS Profile When the RPK mode of the DTLS profile is used (see ), it becomes possible for the AS to effectively issue an access token intended to an audience that includes multiple RSs. This is enabled by the parameters "rs_cnf2" and "audience2" defined in , as well as by the "anchor_cnf" parameter defined in . This seamlessly applies also if the profile uses Transport Layer Security (TLS) , as defined in .
EDHOC and OSCORE Profile When the EDHOC and OSCORE profile is used , it becomes possible for the AS to effectively issue an access token intended to an audience that includes multiple RSs. This is enabled by the parameters "rs_cnf2" and "audience2" defined in , as well as by the "anchor_cnf" parameter defined in .
Open Points
SDC Workflow The following discusses open points related to the use of the SDC workflow defined in .
Prevent Ambiguities in the Dynamic Update of Access Rights In some profiles of ACE, C can request a new access token to update its access rights, while preserving the same secure association with the RS. The new access token supersedes the current one stored at the RS, as they are both part of the same token series. When using the original workflow, C uploads the new access token to the RS by protecting the message exchange through the secure association with the RS. This allows the RS to determine that the upload of such access token is for updating the access rights of C. When using the SDC workflow, the AS uploads the new access token to the RS also when an update of access rights for C is to be performed. This message exchange is protected through the secure association between the AS and the RS. In this latter case, even though the access token claim "token_series_id" defined in provides the RS with an explicit indication for recognizing a stored access token as belonging to an ongoing token series, such a process might still lead to ambiguities. For example, the RS might have deleted a stored access token due to memory limitations. This effectively terminates the corresponding token series, which is however impractical for the RS to remember indefinitely. Consequently, if the AS uploads to the RS a new access token belonging to the same token series, the RS would erroneously interpret it to be the first access token of a new series. This can be avoided by relying on a new "updated_rights" parameter, which the AS can include in a POST request to the authz-info endpoint when uploading to the RS an access token for dynamically updating the access rights of C (see ).
Further New Parameters to Consider The following discusses possible, further new parameters that can be defined for addressing the open points raised earlier in .
  • "updated_rights" - When using the SDC workflow and issuing an access token for dynamically updating the access rights of C, the AS specifies this parameter in the request sent to the RS for uploading the access token on behalf of C (see ). This parameter encodes the CBOR simple value true (0xf5).
CDDL Model
CDDL model
Document Updates
Version -03 to -04
  • Updated document title.
  • Defined name for the new workflow.
  • Improved definition of "token series".
  • Revised note on the new workflow suitable for "unaware" clients.
  • Revised criterion for the AS to choose a token series identifier.
  • Extended semantics of the "ace_profile" parameter.
  • Specified means for C and the AS to coordinate on the exchange of public authentication credentials.
  • Removed content on bidirectional access control.
  • Suggested value ranges for codepoints to register.
  • Editorial fixes and improvements.
Version -02 to -03
  • Defined parameter and claim "token_series_id".
  • Defined parameters "to_rs" and "from_rs".
  • Defined use of "to_rs" and "from_rs" in the OSCORE profile.
  • Lowercase use of "client", "resource server", and "authorization server".
  • Fixed naming of parameters/claims for audience.
  • Split elision and comments in the examples in CBOR Diagnostic Notation.
  • SHA-256 is mandatory to implement for computing token hashes.
  • Fixes in the IANA considerations.
  • Removed (parts of) appendices that are not needed anymore.
  • Clarifications and editorial improvements.
Version -01 to -02
  • CBOR diagnostic notation uses placeholders from a CDDL model.
  • Note on the new workflow supporting also non-ACE clients.
  • Revised semantics of the "token_upload" parameter.
  • Defined the new "token_hash" parameter.
  • First definition of bidirectional access control through a single access token.
  • Revised and extended considerations and next steps in appendices.
  • Clarifications and editorial improvements.
Version -00 to -01
  • Definition of the "token series" moved to the "Terminology" section.
  • Clarifications and fixes on using parameters in messages.
  • Amended two of the requirements on profiles of the framework.
  • The client has to opt-in for using the new workflow.
  • Parameter "token_uploaded" renamed to "token_upload".
  • Updated format of error response payload to use RFC 9290.
  • Security considerations inherited from other documents.
  • Editorial fixes and improvements.
Acknowledgments The authors sincerely thank , , and for their comments and feedback. This work was supported by the Sweden's Innovation Agency VINNOVA within the EUREKA CELTIC-NEXT project CYPRESS; and by the H2020 project SIFIS-Home (Grant agreement 952652).