Internet-Draft Alternative ACE Workflow and Parameters October 2024
Tiloca & Selander Expires 24 April 2025 [Page]
Workgroup:
ACE Working Group
Internet-Draft:
draft-ietf-ace-workflow-and-params-03
Updates:
9200, 9202, 9203, 9431 (if approved)
Published:
Intended Status:
Standards Track
Expires:
Authors:
M. Tiloca
RISE AB
G. Selander
Ericsson AB

Alternative Workflow and OAuth Parameters for the Authentication and Authorization for Constrained Environments (ACE) Framework

Abstract

This document updates the Authentication and Authorization for Constrained Environments Framework (ACE, RFC 9200) as follows. First, it defines a new, alternative workflow that the authorization server can use for uploading an access token to a resource server on behalf of the client. Second, it defines new parameters and encodings for the OAuth 2.0 token endpoint at the authorization server. Third, it defines a method for the ACE framework to enforce bidirectional access control by means of a single access token. Fourth, it amends two of the requirements on profiles of the framework. Finally, it deprecates the original payload format of error responses that convey an error code, when CBOR is used to encode message payloads. For such error responses, it defines a new payload format aligned with RFC 9290, thus updating in this respect also the profiles of ACE defined in RFC 9202, RFC 9203, and RFC 9431.

About This Document

This note is to be removed before publishing as an RFC.

Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-ace-workflow-and-params/.

Discussion of this document takes place on the Authentication and Authorization for Constrained Environments (ace) Working Group mailing list (mailto:ace@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ace/. Subscribe at https://www.ietf.org/mailman/listinfo/ace/.

Source for this draft and an issue tracker can be found at https://github.com/ace-wg/ace-workflow-and-params.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 24 April 2025.

▲

Table of Contents

1. Introduction

The Authentication and Authorization for Constrained Environments (ACE) framework [RFC9200] 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 [RFC6749], the Constrained Application Protocol (CoAP) [RFC7252] for message transfer, Concise Binary Object Representation (CBOR) [RFC8949] for compact encoding, and CBOR Object Signing and Encryption (COSE) [RFC9052][RFC9053] 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 [RFC9200] as follows.

1.1. 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 [RFC2119] [RFC8174] 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 [RFC9200][RFC9201], as well as with terms and concepts related to CBOR Web Tokens (CWTs) [RFC8392] and CWT Confirmation Methods [RFC8747].

The terminology for entities in the considered architecture is defined in OAuth 2.0 [RFC6749]. 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 [RFC7252], Concise Data Definition Language (CDDL) [RFC8610], CBOR [RFC8949], JavaScript Object Notation (JSON) [RFC8259], and COSE [RFC9052][RFC9053].

Note that the term "endpoint" is used here following its OAuth definition [RFC6749], 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: the set comprising all the access tokens issued by the same AS for the same pair (client, resource server). 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) [RFC8392].

CBOR [RFC8949] and CDDL [RFC8610] 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 Section 8 of [RFC8949] and Appendix G of [RFC8610]. 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 Figure 12 of Appendix C. 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 Figure 12 of Appendix C. Finally, please delete this note.

2. New ACE Workflow

As defined in Section 4 of [RFC9200], the ACE framework considers what is shown in Figure 1 as its basic protocol workflow.

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., [RFC9202][RFC9203][RFC9431][I-D.ietf-ace-edhoc-oscore-profile][I-D.ietf-ace-group-oscore-profile][RFC9431].

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).

+--------+                               +---------------+
|        |---(A)-- Token Request ------->|               |
|        |                               | 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    |
|        |                               |              |
+--------+                               +--------------+
Figure 1: ACE Basic Protocol Workflow.

This section defines a new, alternative protocol workflow shown in Figure 2, which MAY be supported by the AS. Unlike in the original protocol workflow, 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.

+--------+                               +----------------------------+
|        |---(A)-- Token Request ------->|                            |
|        |                               |       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 --|                            |
|        |                               |                            |
+--------+                               +----------------------------+
Figure 2: ACE Alternative Protocol Workflow.

More specifically, the new workflow consists of the following steps.

The new workflow has no ambition to replace the original workflow defined in [RFC9200]. 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 new workflow, all the communications between the AS and the RS MUST be protected, consistent with Sections 5.8.4.3 and 6.5 of [RFC9200]. 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.

Note that the new workflow is also suitable for deployments where devices meant to access protected resources at the RS are not required or expected to be actual ACE clients. That is, consistent with the intended access policies, the AS can be configured to automatically issue access tokens for such devices and upload those access tokens to the RS. This means that those devices 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.

3. New ACE Parameters

The rest of this section defines a number of additional parameters and encodings for the OAuth 2.0 token endpoint at the AS.

3.1. 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 new, alternative ACE workflow defined in Section 2, 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 new ACE workflow and the Access Token Request includes the "token_upload" parameter with value 0, 1, or 2, then the AS MAY use the new ACE 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 new ACE 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 new ACE 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 Section 3.2.

      • 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 Section 3.2, specifying the hash corresponding to the issued access token and computed as defined in Section 3.2.

      • 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 Section 3.2.

3.1.1. Examples

Figure 3 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.

   Access Token Request

   Header: POST (Code=0.02)
   Uri-Host: "as.example.com"
   Uri-Path: "token"
   Content-Format: 19 (application/ace+cbor)
   Payload:
   {
     / audience /  5 : "tempSensor4711",
     / scope /     9 : "read",
     e'token_upload' : 0
   }


   Access Token Response

   Header: Created (Code=2.01)
   Content-Format: 19 (application/ace+cbor)
   Max-Age: 3560
   Payload:
   {
     e'token_upload' : 0,
     / expires_in / 2 : 3600,
     / cnf /        8 : {
       / COSE_Key / 1 : {
         / kty / 1 : 4 / Symmetric /,
         / kid / 2 : h'3d027833fc6267ce',
         / k /  -1 : h'73657373696f6e6b6579'
       }
     }
   }
Figure 3: 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.

Figure 4 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.

   Access Token Request

   Header: POST (Code=0.02)
   Uri-Host: "as.example.com"
   Uri-Path: "token"
   Content-Format: 19 (application/ace+cbor)
   Payload:
   {
     / audience /  5 : "tempSensor4711",
     / scope /     9 : "read",
     e'token_upload' : 2
   }


   Access Token Response

   Header: Created (Code=2.01)
   Content-Format: 19 (application/ace+cbor)
   Max-Age: 3560
   Payload:
   {
        e'token_upload' : 0,
     / access_token / 1 : h'd08343a1...4819',
       / (full CWT elided for brevity;
          CWT contains the symmetric PoP key in the "cnf" claim) /
     / expires_in /   2 : 3600,
     / cnf /          8 : {
       / COSE_Key / 1 : {
         / kty / 1 : 4 / Symmetric /,
         / kid / 2 : h'3d027833fc6267ce',
         / k /  -1 : h'73657373696f6e6b6579'
       }
     }
   }
Figure 4: 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.

Figure 5 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.

   Access Token Request

   Header: POST (Code=0.02)
   Uri-Host: "as.example.com"
   Uri-Path: "token"
   Content-Format: 19 (application/ace+cbor)
   Payload:
   {
     / audience /  5 : "tempSensor4711",
     / scope /     9 : "read",
     e'token_upload' : 0
   }


   Access Token Response

   Header: Created (Code=2.01)
   Content-Format: 19 (application/ace+cbor)
   Max-Age: 3560
   Payload:
   {
        e'token_upload' : 1,
     / access_token / 1 : h'd08343a1...4819',
       / (full CWT elided for brevity;
          CWT contains the symmetric PoP key in the "cnf" claim) /
     / expires_in /   2 : 3600,
     / cnf /          8 : {
       / COSE_Key / 1 : {
         / kty / 1 : 4 / Symmetric /,
         / kid / 2 : h'3d027833fc6267ce',
         / k /  -1 : h'73657373696f6e6b6579'
       }
     }
   }
Figure 5: 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.

3.2. 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 Section 5 of [RFC4648]), and denotes as "binary representation" of a text string the corresponding UTF-8 encoding [RFC3629], which is the implied charset used in JSON (see Section 8.1 of [RFC8259]).

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 new ACE 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 Section 3.2.1.

3.2.1. 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 Section 6 of [RFC6920]. 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 [Named.Information.Hash.Algorithm]. Consistent with the compliance requirements in Section 2 of [RFC6920], the hash function sha-256 as specified in [SHA-256] is mandatory to implement.

The computation of token hashes defined above is aligned with that specified for the computation of token hashes in [I-D.ietf-ace-revoked-token-notification], 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 [I-D.ietf-ace-revoked-token-notification], 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.

3.2.2. Example

Figure 6 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.

   Access Token Request

   Header: POST (Code=0.02)
   Uri-Host: "as.example.com"
   Uri-Path: "token"
   Content-Format: 19 (application/ace+cbor)
   Payload:
   {
     / audience /  5 : "tempSensor4711",
     / scope /     9 : "read",
     e'token_upload' : 1
   }


   Access Token Response

   Header: Created (Code=2.01)
   Content-Format: 19 (application/ace+cbor)
   Max-Age: 3560
   Payload:
   {
      e'token_upload' : 0,
        e'token_hash' : h'0153269057e12fe2b74ba07c892560a2d7
                          53877eb62ff44d5a19002530ed97ffe4',
     / expires_in / 2 : 3600,
     / cnf /        8 : {
       / COSE_Key / 1 : {
         / kty / 1 : 4 / Symmetric /,
         / kid / 2 : h'3d027833fc6267ce',
         / k /  -1 : h'73657373696f6e6b6579'
       }
     }
   }
Figure 6: 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.

3.3. 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 new ACE workflow defined in Section 2. This parameter MUST NOT be present if the "token_upload" parameter defined in Section 3.1 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 ACE 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. Section 3.3.1 defines those for when this parameter is used with the OSCORE profile [RFC9203].

  • 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 new ACE workflow defined in Section 2. This parameter MUST NOT be present if the "token_upload" parameter defined in Section 3.1 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 ACE 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. Section 3.3.1 defines those for when this parameter is used with the OSCORE profile [RFC9203].

3.3.1. 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 [RFC9203], thereby effectively enabling the use of the new ACE 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 Section 4.1 of [RFC9203]).

  • 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 Section 4.1 of [RFC9203]).

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 Section 4.1 of [RFC9203]. 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 Section 4.2 of [RFC9203]).

  • The "ace_server_recipientid" field, with value the Recipient ID ID2 generated by the RS and encoded as a CBOR byte string (see Section 4.2 of [RFC9203]).

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 ACE workflow.

Figure 7 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.

   Access Token Request

   Header: POST (Code=0.02)
   Uri-Host: "as.example.com"
   Uri-Path: "token"
   Content-Format: 19 (application/ace+cbor)
   Payload:
   {
     / audience /  5 : "tempSensor4711",
     / scope /     9 : "read",
     e'token_upload' : 0,
            e'to_rs' : h'a2182848018a278f7faab55a182b421645'
   }


   Access Token Response

   Header: Created (Code=2.01)
   Content-Format: 19 (application/ace+cbor)
   Max-Age: 3560
   Payload:
   {
        e'token_upload' : 0,
             e'from_rs' : h'a2182a4825a8991cd700ac01182c420000',
     / ace_profile / 38 : / coap_oscore / 2,
       / expires_in / 2 : 3600,
       / cnf /        8 : {
         / osc / 4 : {
           / id / 0 : h'01',
           / ms / 2 : h'f9af838368e353e78888e1426bd94e6f'
         }
       }
   }
Figure 7: 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"

3.4. 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 Section 6.9 of [RFC9200]). 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 Section 3.1 of [RFC8747] for CBOR-based interactions, or from Section 3.1 of [RFC7800] 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 Section 5.8.1 of [RFC9200]) and of an Access Token Response from the AS (see Section 5.8.2 of [RFC9200]), 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.

3.4.1. Example

Figure 8 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.

   Access Token Response

   Header: Created (Code=2.01)
   Content-Format: 19 (application/ace+cbor)
   Max-Age: 3600
   Payload:
   {
     / access_token / 1 : b64'SlAV32hk...12',
       / (full CWT elided for brevity;
          CWT contains the client's RPK in the "cnf" claim) /
     / expires_in /   2 : 3600,
           e'audience2' : ["rs1", "rs2"],
             e'rs_cnf2' : [
               {
                 / COSE_Key / 1 : {
                   / kty /  1 : 2 / EC2 /,
                   / crv / -1 : 1 / P-256 /,
                   / x /   -2 : h'bbc34960526ea4d32e940cad2a234148
                                  ddc21791a12afbcbac93622046dd44f0',
                   / y /   -3 : h'4519e257236b2a0ce2023f0931f1f386
                                  ca7afda64fcde0108c224c51eabf6072'
                 }
               },
               {
                 / COSE_Key / 1 : {
                   / kty /  1 : 2 / EC2 /,
                   / crv / -1 : 1 / P-256 /,
                   / x /   -2 : h'ac75e9ece3e50bfc8ed6039988952240
                                  5c47bf16df96660a41298cb4307f7eb6',
                   / y /   -3 : h'6e5de611388a4b8a8211334ac7d37ecb
                                  52a387d257e6db3c2a93df21ff3affc8'
                 }
               }
             ]
   }
Figure 8: Example of Access Token Response with an access token bound to an asymmetric key, using the parameters "audience2" and "rs_cnf2".

3.5. 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 Section 3.1 of [RFC8747] for CBOR-based interactions, or from Section 3.1 of [RFC7800] 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 [RFC9201] or the "rs_cnf2" parameter defined in Section 3.4 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 Section 3.4, 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.

3.5.1. Example

Figure 9 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 [I-D.ietf-ace-edhoc-oscore-profile].

   Access Token Response

   Header: Created (Code=2.01)
   Content-Format: 19 (application/ace+cbor)
   Max-Age: 3600
   Payload:
   {
     / access_token / 1 : b64'SlAV32hk...12',
       / (full CWT elided for brevity;
          CWT contains the client's RPK in the "cnf" claim) /
     / expires_in /   2 : 3600,
          e'anchor_cnf' : [
            {
              e'x5chain' : h'308201363081dea003020102020301f50d30
                             0a06082a8648ce3d04030230163114301206
                             035504030c0b524643207465737420434130
                             1e170d3230303130313030303030305a170d
                             3231303230323030303030305a3022312030
                             1e06035504030c1730312d32332d34352d46
                             462d46452d36372d38392d41423059301306
                             072a8648ce3d020106082a8648ce3d030107
                             03420004b1216ab96e5b3b3340f5bdf02e69
                             3f16213a04525ed44450b1019c2dfd3838ab
                             ac4e14d86c0983ed5e9eef2448c6861cc406
                             547177e6026030d051f7792ac206a30f300d
                             300b0603551d0f040403020780300a06082a
                             8648ce3d04030203470030440220445d798c
                             90e7f500dc747a654cec6cfa6f037276e14e
                             52ed07fc16294c84660d02205a33985dfbd4
                             bfdd6d4acf3804c3d46ebf3b7fa62640674f
                             c0354fa056dbaea6'
            }
          ]
   }
Figure 9: Example of Access Token Response with an access token bound to an asymmetric key, using the "anchor_cnf" parameter.

3.6. 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 uniquely associated with the access tokens issued by the AS for that token series, and MUST be selected from a pool that the AS exclusively controls.

  • 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 Section 8.4.

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 [RFC9202], in the OSCORE profile [RFC9203], and in the EDHOC and OSCORE profile [I-D.ietf-ace-edhoc-oscore-profile].

3.7. rev_audience

This section defines the additional "rev_audience" 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 "rev_audience" parameter is OPTIONAL in an Access Token Request. The presence of this parameter indicates that C wishes the requested access token to specify additional access rights. These are intended for the access token's audience to access protected resources at C as the access token's reverse audience.

    This parameter specifies such a reverse audience as a text string identifier of C. When the Access Token Request is encoded in CBOR, the value of this parameter is encoded as a CBOR text string.

  • The "rev_audience" parameter is OPTIONAL in an Access Token Response. If present, it has the same meaning and encoding that it has in the Access Token Request.

Fundamentally, this parameter has the same semantics of the "audience" parameter used in the ACE framework, with the difference that it conveys an identifier of C as a host of protected resources to access, according to the access rights granted as reverse scope to the audience of the access token issued by the AS.

The use of this parameter is further detailed in Section 4.

3.8. rev_scope

This section defines the additional "rev_scope" 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 "rev_scope" parameter is OPTIONAL in an Access Token Request. The presence of this parameter indicates that C wishes the requested access token to specify additional access rights. These are intended for the access token's audience to access protected resources at C as the access token's reverse audience.

    This parameter specifies such access rights as a reverse scope. When the Access Token Request is encoded in CBOR, the value of this parameter is encoded as a CBOR text string or a CBOR byte string.

  • The "rev_scope" parameter is OPTIONAL in an Access Token Response. If present, this parameter specifies the access rights that the AS has actually granted as a reverse scope to the access token's audience, for accessing protected resources at C as the access token's reverse audience.

Fundamentally, this parameter has the same semantics of the "scope" parameter used in the ACE framework, with the difference that it conveys the access rights requested/granted as reverse scope for/to the audience of the access token issued by the AS.

The use of this parameter is further detailed in Section 4.

4. Bidirectional Access Control

In some deployments, two devices DEV1 and DEV2 might wish to access each other's protected resources. This can clearly be achieved by means of two separate access tokens, each of which is used to enforce access control in one direction. That is:

This section defines how to enforce such a bidirectional access control by means of a single access token, which is requested by and issued to a device DEV1 acting as ACE client. In particular:

Like for the original case with a single access control direction, the access token is uploaded to the ACE RS DEV2, which processes the access token as per Section 5.10 of [RFC9200] and according to the profile of ACE used by DEV1 and DEV2.

The protocol workflow is detailed in the following Section 4.1 and Section 4.2, in case only one authorization server or two authorization servers are involved, respectively.

4.1. Scenario with One Authorization Server

As shown in Figure 10, this section considers a scenario with a single authorization server AS. Both devices DEV1 and DEV2 are registered at AS, and each of them with permissions to access protected resources at the other device. In the following, DEV1 acts as ACE client by requesting an access token from AS.

- DEV1 is registered as: - Device authorized to access DEV2; and - Device that can be accessed by DEV2 - DEV2 is registered as: AS - Device that can be accessed by DEV1; and - Device authorized to access DEV1 DEV2 DEV1 RS C
Figure 10: Bidirectional access control with one Authorization Server.

4.1.1. Access Token Request

As to the Access Token Request that DEV1 sends to AS, the following applies.

  • The "audience" and "scope" parameters are used as defined in [RFC9200], and according to the profile of ACE used by DEV1 and DEV2.

    In particular, "audience" specifies an identifier of DEV2, while "scope" specifies access rights that DEV1 wishes to obtain for accessing protecting resources at DEV2.

    That is, the two parameters pertain to the primary direction of access control.

  • The "req_cnf" parameter defined in [RFC9201] can be included. When present, it specifies the key that DEV1 wishes to bind to the requested access token.

  • The "rev_audience" and "rev_scope" parameters defined in Section 3.7 and Section 3.8 can be included.

    In particular, "rev_audience" specifies an identifier of DEV1, while "rev_scope" specifies access rights that DEV1 wishes for DEV2 to obtain for accessing protecting resources at DEV1.

    That is, the two parameters pertain to the secondary direction of access control.

If DEV1 wishes that the requested access token also provides DEV2 with access rights pertaining to the secondary direction of access control, then the Access Token Request has to include at least one of the two parameters "rev_audience" and "rev_scope".

4.1.2. Access Token Response

When receiving an Access Token Request that includes at least one of the two parameters "rev_audience" and "rev_scope", AS processes it as defined in Section 5.2 of [RFC9200], with the following additions:

  • If the Access Token Request includes the "rev_scope" parameter but not the "rev_audience" parameter, then AS assumes the identifier of DEV1 to be the default one, if any is defined.

  • If the Access Token Request includes the "rev_audience" parameter but not the "rev_scope" parameter, then AS assumes the access rights requested for DEV2 to access DEV1 to be the default ones, if any are defined.

  • AS checks whether the access rights requested for DEV2 as reverse scope can be at least partially granted, in accordance with the installed access policies pertaining to the access to protected resources at DEV1 from DEV2.

    That is, AS performs the same evaluation that it would perform if DEV2 sent an Access Token Request as an ACE client, with the intent to access protected resources at DEV1 as an ACE RS.

    It is REQUIRED that such evaluation succeeds, in order for AS to issue an access token and reply to DEV1 with a successful Access Token Response.

As to the successful Access Token Response that AS sends to DEV1, the following applies.

  • The "audience" and "scope" parameters are used as defined in [RFC9200], and according to the profile of ACE used by DEV1 and DEV2.

    In particular, "audience" specifies an identifier of DEV2, while "scope" specifies the access rights that AS has granted to DEV1 for accessing protecting resources at DEV2.

    The "scope" parameter has to be present if: i) it was present in the Access Token Request, and the access rights granted to DEV1 are different from the requested ones; or ii) it was not present in the Access Token Request, and the access rights granted to DEV1 are different from the default ones.

    If the "scope" parameter is not present, then the granted access rights are the same as those requested by the "scope" parameter in the Access Token Request if present therein, or the default access rights otherwise.

  • The "rs_cnf" parameter defined in [RFC9201] can be included. When present, it specifies information about the public key that DEV2 uses to authenticate.

  • The "rev_audience" parameter defined in Section 3.7 can be included, and specifies an identifier of DEV1.

    If the "rev_audience" parameter is present in the Access Token Response and it was also present in the Access Token Request, then the parameter in the Access Token Response MUST have the same value specified by the parameter in the Access Token Request.

  • The "rev_scope" parameter defined in Section 3.8 can be included, and specifies access rights that AS has granted to DEV2 for accessing protecting resources at DEV1.

    The "rev_scope" parameter MUST be present if: i) it was present in the Access Token Request, and the access rights granted to DEV2 are different from the requested ones; or ii) it was not present in the Access Token Request, and the access rights granted to DEV2 are different from the default ones.

    If the "rev_scope" parameter is not present, then the access rights granted to DEV2 are the same as those requested by the "rev_scope" parameter in the Access Token Request if present therein, or the default access rights otherwise.

The issued access token MUST include information about the reverse audience and reverse scope pertaining to the secondary access control direction. In particular:

  • The access token MUST contain a claim specifying the identifier of DEV1.

    If the Access Token Response includes the "rev_audience" parameter, then the claim specifies the same information conveyed by that parameter.

    If this is not the case, then the claim specifies the same information conveyed by the "rev_audience" parameter of the Access Token Request, if included therein, or the default identifier of DEV1 otherwise.

    When CWTs are used as access tokens, this information MUST be transported in the "rev_aud" claim registered in Section 8.4.

  • The access token MUST contain a claim specifying the access rights that AS has granted to DEV2 for accessing protecting resources at DEV1.

    If the Access Token Response includes the "rev_scope" parameter, then the claim specifies the same information conveyed by that parameter.

    If this is not the case, then the claim specifies the same information conveyed by the "rev_scope" parameter of the Access Token Request, if included therein, or the default access rights for DEV2 to access DEV1 otherwise.

    When CWTs are used as access tokens, this information MUST be transported in the "rev_scope" claim, registered in Section 8.4.

4.1.3. Access to Protected Resources

As to the secure communication association between DEV1 and DEV2, its establishment and maintenance does not deviate from what is defined in the profile of ACE used by DEV1 and DEV2.

Furthermore, communications between DEV1 and DEV2 MUST rely on such secure communication association for both directions of access control, i.e., when DEV1 accesses protected resources at DEV2 and vice versa.

After having received a successful Access Token Response from AS, DEV1 MUST maintain and enforce the information about the access rights granted to DEV2 and pertaining to the secondary access control direction.

In particular, DEV1 MUST prevent DEV2 from accessing protected resources at DEV1, in case access requests from DEV2 are not authorized as per the reverse scope specified by the issued access token, or after having purged the issued access token (e.g., following its expiration of revocation).

4.3. Practical Considerations

When enforcing bidirectional access control by means of a single access token, the following considerations hold.

  • The access token can be uploaded to the ACE RS DEV2 by the ACE client per the original ACE workflow, or by the AS that has issued the access token per the new ACE workflow defined in Section 2.

  • Since the access token is requested by the ACE client DEV1, only DEV1 can request for a new access token in the same token series, in order to dynamically update the access rights concerning its own access to protected resources hosted by DEV2 (on the primary access control direction) and/or the access rights concerning the access of DEV2 to access protected resources hosted by DEV1 (on the secondary access control direction).

5. Updated Requirements on Profiles

Appendix C of [RFC9200] 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., [RFC9202][RFC9203][RFC9431]) already comply with the two updated requirements as formulated above.

6. 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 5.8.3 and 5.9.3 of [RFC9200].

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 [RFC9290].

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 Section 2 of [RFC9290]). The CBOR map is formatted as follows.

   ace-error = {
     &(error-code: 0) => int
   }

An example of error response using the problem-details format is shown in Figure 11.

Header: Bad Request (Code=4.00)
Content-Format: 257 (application/concise-problem-details+cbor)
Payload:
{
  / title /  -1 : "Incompatible ACE profile",
  / detail / -2 : "The RS supports only the OSCORE profile",
    e'ace-error': {
      / error_code / 0: 8 / incompatible_ace_profiles /
    }
}
Figure 11: Example of Error Response with Problem Details.

When the ACE framework is used with CBOR for encoding message payloads, the following applies.

7. Security Considerations

The same security considerations from the ACE framework for Authentication and Authorization [RFC9200] apply to this document, together with those from the specific profile of ACE used, e.g., [RFC9202][RFC9203][RFC9431][I-D.ietf-ace-edhoc-oscore-profile][I-D.ietf-ace-group-oscore-profile][RFC9431].

When using the problem-details format defined in [RFC9290] for error responses, then the privacy and security considerations from Sections 4 and 5 of [RFC9290] also apply.

Editor's note: add more security considerations.

8. 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.

8.1. 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]


  • Name: "rev_audience"

  • Parameter Usage Location: token request and token response

  • Change Controller: IETF

  • Reference: [RFC-XXXX]


  • Name: "rev_scope"

  • Parameter Usage Location: token request and token response

  • Change Controller: IETF

  • Reference: [RFC-XXXX]

8.2. 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 [RFC9200].

  • Name: "token_upload"

  • CBOR Key: TBD

  • Value Type: unsigned integer

  • Reference: [RFC-XXXX]

  • Original Specification: [RFC-XXXX]


  • Name: "token_hash"

  • CBOR Key: TBD

  • Value Type: unsigned integer

  • Reference: [RFC-XXXX]

  • Original Specification: [RFC-XXXX]


  • Name: "to_rs"

  • CBOR Key: TBD

  • Value Type: byte string

  • Reference: [RFC-XXXX]

  • Original Specification: [RFC-XXXX]


  • Name: "from_rs"

  • CBOR Key: TBD

  • Value Type: byte string

  • Reference: [RFC-XXXX]

  • Original Specification: [RFC-XXXX]


  • Name: "rs_cnf2"

  • CBOR Key: TBD

  • Value Type: array

  • Reference: [RFC-XXXX]

  • Original Specification: [RFC-XXXX]


  • Name: "audience2"

  • CBOR Key: TBD

  • Value Type: array

  • Reference: [RFC-XXXX]

  • Original Specification: [RFC-XXXX]


  • Name: "anchor_cnf"

  • CBOR Key: TBD

  • Value Type: array

  • Reference: [RFC-XXXX]

  • Original Specification: [RFC-XXXX]


  • Name: "token_series_id"

  • CBOR Key: TBD

  • Value Type: byte string

  • Reference: [RFC-XXXX]

  • Original Specification: [RFC-XXXX]


  • Name: "rev_audience"

  • CBOR Key: TBD

  • Value Type: text string

  • Reference: [RFC-XXXX]

  • Original Specification: [RFC-XXXX]


  • Name: "rev_scope"

  • CBOR Key: TBD

  • Value Type: text string or byte string

  • Reference: [RFC-XXXX]

  • Original Specification: [RFC-XXXX]

8.3. 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 [RFC7519].

  • Claim Name: "token_series_id"

  • Claim Description: The identifier of a token series

  • Change Controller: IETF

  • Reference: [RFC-XXXX]


  • Claim Name: "rev_aud"

  • Claim Description: The reverse audience of an access token

  • Change Controller: IETF

  • Reference: [RFC-XXXX]


  • Claim Name: "rev_scope"

  • Claim Description: The reverse scope of an access token

  • Change Controller: IETF

  • Reference: [RFC-XXXX]

8.4. 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 [RFC8392].

  • Claim Name: "token_series_id"

  • Claim Description: The identifier of a token series

  • JWT Claim Name: "token_series_id"

  • Claim Key: TBD

  • Claim Value Type: byte string

  • Change Controller: IETF

  • Reference: Section 4 of [RFC-XXXX]


  • Claim Name: "rev_aud"

  • Claim Description: The reverse audience of an access token

  • JWT Claim Name: "rev_aud"

  • Claim Key: TBD

  • Claim Value Type: text string

  • Change Controller: IETF

  • Reference: Section 4 of [RFC-XXXX]


  • Claim Name: "rev_scope"

  • Claim Description: The reverse scope of an access token

  • JWT Claim Name: "rev_scope"

  • Claim Key: TBD

  • Claim Value Type: text string or byte string

  • Change Controller: IETF

  • Reference: Section 4 of [RFC-XXXX]

8.5. 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

  • Name: ace-error

  • Brief Description: Carry ACE [RFC9200] problem details in a Concise Problem Details data item.

  • Change Controller: IETF

  • Reference: Section 6 of [RFC-XXXX]

9. References

9.1. Normative References

[ACE.OAuth.Error.Code.CBOR.Mappings]
IANA, "OAuth Error Code CBOR Mappings", <https://www.iana.org/assignments/ace/ace.xhtml#oauth-error-code-cbor-mappings>.
[I-D.ietf-ace-edhoc-oscore-profile]
Selander, G., Mattsson, J. P., Tiloca, M., and R. Höglund, "Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE)", Work in Progress, Internet-Draft, draft-ietf-ace-edhoc-oscore-profile-06, , <https://datatracker.ietf.org/doc/html/draft-ietf-ace-edhoc-oscore-profile-06>.
[I-D.ietf-ace-revoked-token-notification]
Tiloca, M., Palombini, F., Echeverria, S., and G. Lewis, "Notification of Revoked Access Tokens in the Authentication and Authorization for Constrained Environments (ACE) Framework", Work in Progress, Internet-Draft, draft-ietf-ace-revoked-token-notification-09, , <https://datatracker.ietf.org/doc/html/draft-ietf-ace-revoked-token-notification-09>.
[Named.Information.Hash.Algorithm]
IANA, "Named Information Hash Algorithm", <https://www.iana.org/assignments/named-information/named-information.xhtml>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3629]
Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, , <https://www.rfc-editor.org/rfc/rfc3629>.
[RFC4648]
Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, , <https://www.rfc-editor.org/rfc/rfc4648>.
[RFC6749]
Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, , <https://www.rfc-editor.org/rfc/rfc6749>.
[RFC6920]
Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, , <https://www.rfc-editor.org/rfc/rfc6920>.
[RFC7252]
Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, , <https://www.rfc-editor.org/rfc/rfc7252>.
[RFC7519]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, , <https://www.rfc-editor.org/rfc/rfc7519>.
[RFC7800]
Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, , <https://www.rfc-editor.org/rfc/rfc7800>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8259]
Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, , <https://www.rfc-editor.org/rfc/rfc8259>.
[RFC8392]
Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, , <https://www.rfc-editor.org/rfc/rfc8392>.
[RFC8446]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, , <https://www.rfc-editor.org/rfc/rfc8446>.
[RFC8610]
Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, , <https://www.rfc-editor.org/rfc/rfc8610>.
[RFC8747]
Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Tschofenig, "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, , <https://www.rfc-editor.org/rfc/rfc8747>.
[RFC8949]
Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, , <https://www.rfc-editor.org/rfc/rfc8949>.
[RFC9052]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, , <https://www.rfc-editor.org/rfc/rfc9052>.
[RFC9053]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, , <https://www.rfc-editor.org/rfc/rfc9053>.
[RFC9200]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, , <https://www.rfc-editor.org/rfc/rfc9200>.
[RFC9201]
Seitz, L., "Additional OAuth Parameters for Authentication and Authorization for Constrained Environments (ACE)", RFC 9201, DOI 10.17487/RFC9201, , <https://www.rfc-editor.org/rfc/rfc9201>.
[RFC9202]
Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and L. Seitz, "Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)", RFC 9202, DOI 10.17487/RFC9202, , <https://www.rfc-editor.org/rfc/rfc9202>.
[RFC9203]
Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, "The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework", RFC 9203, DOI 10.17487/RFC9203, , <https://www.rfc-editor.org/rfc/rfc9203>.
[RFC9290]
Fossati, T. and C. Bormann, "Concise Problem Details for Constrained Application Protocol (CoAP) APIs", RFC 9290, DOI 10.17487/RFC9290, , <https://www.rfc-editor.org/rfc/rfc9290>.
[RFC9430]
Bergmann, O., Preuß Mattsson, J., and G. Selander, "Extension of the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) to Transport Layer Security (TLS)", RFC 9430, DOI 10.17487/RFC9430, , <https://www.rfc-editor.org/rfc/rfc9430>.
[RFC9431]
Sengul, C. and A. Kirby, "Message Queuing Telemetry Transport (MQTT) and Transport Layer Security (TLS) Profile of Authentication and Authorization for Constrained Environments (ACE) Framework", RFC 9431, DOI 10.17487/RFC9431, , <https://www.rfc-editor.org/rfc/rfc9431>.
[SHA-256]
NIST, "Secure Hash Standard", FIPS 180-3 , , <http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf>.

9.2. Informative References

[I-D.ietf-ace-group-oscore-profile]
Tiloca, M., Höglund, R., and F. Palombini, "The Group Object Security for Constrained RESTful Environments (Group OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework", Work in Progress, Internet-Draft, draft-ietf-ace-group-oscore-profile-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-ace-group-oscore-profile-02>.

Appendix A. Benefits for ACE Profiles

For any profile of ACE, the following holds.

A.1. DTLS Profile

When the RPK mode of the DTLS profile is used (see Section 3.2 of [RFC9202]), 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 Section 3.4, as well as by the "anchor_cnf" parameter defined in Section 3.5. This seamlessly applies also if the profile uses Transport Layer Security (TLS) [RFC8446], as defined in [RFC9430].

A.2. EDHOC and OSCORE Profile

When the EDHOC and OSCORE profile is used [I-D.ietf-ace-edhoc-oscore-profile], 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 Section 3.4, as well as by the "anchor_cnf" parameter defined in Section 3.5.

Appendix B. Open Points

B.1. New Workflow

The following discusses open points related to the use of the new ACE workflow defined in Section 2.

B.1.1. 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 ACE 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 new ACE 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 Section 3.6 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 Appendix B.2).

B.2. Further New Parameters to Consider

The following discusses possible, further new parameters that can be defined for addressing the open points raised earlier in Appendix B.

  • "updated_rights" - When using the new ACE 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 Appendix B.1.1). This parameter encodes the CBOR simple value true (0xf5).

Appendix C. CDDL Model

This section is to be removed before publishing as an RFC.

; OAuth Parameters CBOR Mappings
token_upload = 48
token_hash = 49
to_rs = 50
from_rs = 51
rs_cnf2 = 52
audience2 = 53
anchor_cnf = 54
token_series_id_param = 55
rev_audience = 56
rev_scope_param = 57

; CBOR Web Token (CWT) Claims
token_series_id_claim = 42
rev_aud = 43
rev_scope_claim = 44

; CWT Confirmation Methods
x5chain = 5

; Custom Problem Detail Keys Registry
ace-error = 2
Figure 12: CDDL model

Appendix D. Document Updates

This section is to be removed before publishing as an RFC.

D.1. 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.

D.2. 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.

D.3. 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 alternative 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 Christian Amsüss, Rikard Höglund, and Dave Robin 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).

Authors' Addresses

Marco Tiloca
RISE AB
Isafjordsgatan 22
SE-16440 Kista
Sweden
Göran Selander
Ericsson AB
Torshamnsgatan 23
SE-16440 Stockholm Kista
Sweden