ACE Working Group M. Tiloca Internet-Draft RISE AB Updates: 9200, 9201, 9202, 9203, 9431 (if G. Selander approved) Ericsson AB Intended status: Standards Track 2 November 2026 Expires: 6 May 2027 Short Distribution Chain (SDC) Workflow and New OAuth Parameters for the Authentication and Authorization for Constrained Environments (ACE) Framework draft-ietf-ace-workflow-and-params-09 Abstract The specification RFC 9200 defines the Authentication and Authorization for Constrained Environments (ACE) framework. This document updates the ACE framework and therefore RFC 9200 as follows. (1) It defines the Short Distribution Chain (SDC) workflow that the authorization server (AS) 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 it extends the semantics of the "ace_profile" parameter. (3) For the OAuth 2.0 authz-info endpoint, it defines a new parameter and its encoding. (4) It defines how the client 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; this extends the semantics of the "rs_cnf" parameter for the OAuth 2.0 token endpoint, thus updating RFC 9201. (5) It extends the error handling at the AS, for which it defines a new error code. (6) It deprecates the original payload format of error responses conveying an error code, when Concise Binary Object Representation (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. (7) It amends two of the requirements on profiles of the framework. 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/. Tiloca & Selander Expires 6 May 2027 [Page 1] Internet-Draft New ACE Workflow and Parameters November 2026 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 6 May 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 8 2. The Short Distribution Chain (SDC) Workflow . . . . . . . . . 8 2.1. Token Upload . . . . . . . . . . . . . . . . . . . . . . 11 3. New Parameters . . . . . . . . . . . . . . . . . . . . . . . 13 Tiloca & Selander Expires 6 May 2027 [Page 2] Internet-Draft New ACE Workflow and Parameters November 2026 3.1. token_upload . . . . . . . . . . . . . . . . . . . . . . 13 3.1.1. In the Access Token Request . . . . . . . . . . . . . 13 3.1.2. In the Access Token Response . . . . . . . . . . . . 14 3.1.3. Examples . . . . . . . . . . . . . . . . . . . . . . 17 3.2. token_hash . . . . . . . . . . . . . . . . . . . . . . . 21 3.2.1. Computing the Token Hash . . . . . . . . . . . . . . 22 3.2.2. Example . . . . . . . . . . . . . . . . . . . . . . . 23 3.3. to_rs and from_rs . . . . . . . . . . . . . . . . . . . . 25 3.3.1. to_rs . . . . . . . . . . . . . . . . . . . . . . . . 25 3.3.2. from_rs . . . . . . . . . . . . . . . . . . . . . . . 27 3.3.3. Use with the OSCORE Profile . . . . . . . . . . . . . 28 3.4. rs_cnf2 and audience2 . . . . . . . . . . . . . . . . . . 31 3.4.1. Example . . . . . . . . . . . . . . . . . . . . . . . 33 3.5. anchor_cnf . . . . . . . . . . . . . . . . . . . . . . . 34 3.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 36 3.6. token_series_id . . . . . . . . . . . . . . . . . . . . . 37 3.7. updated_rights . . . . . . . . . . . . . . . . . . . . . 40 3.7.1. Processing at the RS . . . . . . . . . . . . . . . . 41 3.7.2. Follow-up at the AS . . . . . . . . . . . . . . . . . 43 4. Updated ace_profile Parameter . . . . . . . . . . . . . . . . 46 5. Coordinating on the Exchange of Public Authentication Credentials . . . . . . . . . . . . . . . . . . . . . . . 47 5.1. Instructing C on How to Provide its Authentication Credential . . . . . . . . . . . . . . . . . . . . . . . 48 5.2. Instructing the AS on How to Provide the RS's Authentication Credential . . . . . . . . . . . . . . . . 48 6. Failed Verification of Proof of Possession at the AS . . . . 50 7. Updated Payload Format of Error Responses . . . . . . . . . . 51 8. Updated Requirements on Profiles of ACE . . . . . . . . . . . 53 9. LAKE EAD Item for Transporting a Session Identifier . . . . . 54 10. Operational Considerations . . . . . . . . . . . . . . . . . 57 10.1. Logging . . . . . . . . . . . . . . . . . . . . . . . . 57 10.2. Management and Distribution of Keying Material . . . . . 59 10.3. Access Control . . . . . . . . . . . . . . . . . . . . . 60 11. Security Considerations . . . . . . . . . . . . . . . . . . . 60 11.1. Explicit Indication of Update of Access Rights in the SDC Workflow . . . . . . . . . . . . . . . . . . . . . . . . 60 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 12.1. OAuth Parameters Registry . . . . . . . . . . . . . . . 61 12.2. OAuth Parameters CBOR Mappings Registry . . . . . . . . 65 12.3. JSON Web Token Claims Registry . . . . . . . . . . . . . 67 12.4. CBOR Web Token (CWT) Claims Registry . . . . . . . . . . 68 12.5. OAuth Extensions Error Registry . . . . . . . . . . . . 68 12.6. OAuth Error Code CBOR Mappings Registry . . . . . . . . 69 12.7. Custom Problem Detail Keys Registry . . . . . . . . . . 70 12.8. EDHOC External Authorization Data Registry . . . . . . . 70 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 70 13.1. Normative References . . . . . . . . . . . . . . . . . . 70 Tiloca & Selander Expires 6 May 2027 [Page 3] Internet-Draft New ACE Workflow and Parameters November 2026 13.2. Informative References . . . . . . . . . . . . . . . . . 75 Appendix A. Benefits for ACE Profiles . . . . . . . . . . . . . 76 A.1. DTLS Profile . . . . . . . . . . . . . . . . . . . . . . 77 A.2. LAKE and OSCORE Profile . . . . . . . . . . . . . . . . . 77 Appendix B. CDDL Model . . . . . . . . . . . . . . . . . . . . . 77 Appendix C. Document Updates . . . . . . . . . . . . . . . . . . 78 C.1. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 78 C.2. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 78 C.3. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 79 C.4. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 79 C.5. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 80 C.6. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 80 C.7. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 81 C.8. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 81 C.9. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 81 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82 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 ACE 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. The present document updates [RFC9200] as follows. * It defines the Short Distribution Chain (SDC) workflow for the ACE framework (see Section 2 of the present document), 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. Tiloca & Selander Expires 6 May 2027 [Page 4] Internet-Draft New ACE Workflow and Parameters November 2026 The SDC 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 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 Section 3 of the present document). 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, which corresponds 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 [RFC9203] is also described, as 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 [RFC9203] is also described, as effectively enabling the use of the 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 Section 6.9 of [RFC9200]). - "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 [RFC9201] or in the "rs_cnf2" parameter defined in the present document). Tiloca & Selander Expires 6 May 2027 [Page 5] Internet-Draft New ACE Workflow and Parameters November 2026 - "token_series_id", used by the AS to provide C with the binary 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. - "updated_rights", used by the AS to provide the RS with an indication that an access token uploaded per the SDC workflow is not the first one of a new token series, i.e., that the AS has issued the access token for dynamically updating the access rights of C. * It extends the semantics of the "ace_profile" parameter for the OAuth 2.0 token endpoint at the authorization server defined in [RFC9200] (see Section 4 of the present document). * 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 Section 5 of the present document). This extends the semantics of the "rs_cnf" parameter for the OAuth 2.0 token endpoint defined in Section 3.2 of [RFC9201]. Therefore, it updates [RFC9201]. * It extends the error handling at the AS, for which it defines a new error code that the AS can use for error responses sent to the client, after failing to verify the proof of possession of the client's private key when processing an access token request (see Section 6 of the present document). * 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 [RFC9290] (see Section 7 of the present document). In this respect, it also updates the profiles of the ACE framework defined in [RFC9202], [RFC9203], and [RFC9431]. * It amends two of the requirements on profiles of the ACE framework originally compiled in Appendix C of [RFC9200] (see Section 8 of the present document). Tiloca & Selander Expires 6 May 2027 [Page 6] Internet-Draft New ACE Workflow and Parameters November 2026 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 related to 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. The CoAP definition, which is "[a]n entity participating in the CoAP protocol" [RFC7252], is not used in this document. 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 with other access token identifiers possibly used, such as the 'cti' (CWT ID) claim of CWTs [RFC8392]. Tiloca & Selander Expires 6 May 2027 [Page 7] Internet-Draft New ACE Workflow and Parameters November 2026 This document uses the acronym LAKE, expanded to Lightweight Authenticated Key Exchange, to denote the protocol specified as EDHOC in [RFC9528]. Identifiers defined literally in [RFC9528] or in IANA registries (e.g., the names of the EDHOC registries themselves) are unchanged. 1.2. Notations CBOR [RFC8949] and CDDL [RFC8610] are used 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 13 of Appendix B. For example, {e'audience2' : ["rs1", "rs2"]} stands for {54 : ["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 13 of Appendix B. Finally, please delete this note. 2. The Short Distribution Chain (SDC) Workflow As defined in Section 4 of [RFC9200], the ACE framework relies on its basic protocol workflow shown in Figure 1. 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 is successfully verified, authenticated, and authorized, the AS replies to the client with an access token response (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, consistent 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 Tiloca & Selander Expires 6 May 2027 [Page 8] Internet-Draft New ACE Workflow and Parameters November 2026 specific profile of ACE used, such as [RFC9202], [RFC9203], [RFC9431], [I-D.ietf-ace-edhoc-oscore-profile], or [I-D.ietf-ace-group-oscore-profile]. 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 the alternative Short Distribution Chain (SDC) workflow shown in Figure 2, which MAY be supported by the AS. Unlike in the original workflow defined in [RFC9200], 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. That is, 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. Tiloca & Selander Expires 6 May 2027 [Page 9] Internet-Draft New ACE Workflow and Parameters November 2026 +--------+ +----------------------------+ | |---(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 Short Distribution Chain (SDC) Workflow. 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 Section 3.1.1, this indication is provided to the AS by means of the "token_upload" parameter included in the access token request. 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 informs 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. Tiloca & Selander Expires 6 May 2027 [Page 10] Internet-Draft New ACE Workflow and Parameters November 2026 As defined in Section 3.1.2, this information is provided 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 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 like in the original workflow. The SDC 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 SDC 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. 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. That is, they 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. 2.1. Token Upload When using the original workflow defined in [RFC9200], there are two typical cases concerning the upload of the access token to the RS from C. Tiloca & Selander Expires 6 May 2027 [Page 11] Internet-Draft New ACE Workflow and Parameters November 2026 * The first case consists in the upload of the first access token in a token series. While details depend on the specific profile of ACE used, such an access token is typically uploaded through an unprotected POST request to the authz-info endpoint. * The second case consists in the upload of an access token that is not the first of its token series, i.e., the AS has issued the access token for dynamically updating the access rights of C. The intent is also for C and the RS to preserve the same secure communication association that they currently share and that is associated with the token series in question. Such an access token is uploaded through a POST request to the authz-info endpoint, which is protected by means of the secure communication association that is shared between C and the RS. If the new access token is accepted by the RS, the new access token supersedes the one currently stored for the token series in question, and it becomes associated with the corresponding secure communication association that is shared between C and the RS. However, if the AS uploads the access token to the RS on behalf of C as per the SDC workflow, the upload of the access token always rely on a protected POST request from the AS to the authz-info endpoint. In particular, the request is protected with the secure communication association shared between the AS and the RS. When receiving a POST request to the authz-info endpoint that is specifically protected through the secure communication association shared with the AS, the RS proceeds as follows. In particular, the RS leverages the explicit indication provided by the AS through the "updated_rights" parameter defined in Section 3.7, which is included in the request in the case of dynamic update of access rights. * If the POST request does not include the "updated_rights" parameter, the access token in question is the first one in a token series. Consequently, the RS processes the request and the access token therein like it would when receiving the request from C and according to the specific profile of ACE used. * If the POST request includes the "updated_rights" parameter encoding a specific value, the access token in question is not the first one in a token series, i.e., it is meant to dynamically update the access rights of C, while preserving the same secure communication association that is shared between C and the RS. The POST request and its processing at the RS in this case are defined in Section 3.7. Tiloca & Selander Expires 6 May 2027 [Page 12] Internet-Draft New ACE Workflow and Parameters November 2026 3. 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 (see Section 5.8 of [RFC9200]) and for the OAuth 2.0 authz-info endpoint at the RS (see Section 5.10.1 of [RFC9200]). 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 (see Section 5.8.1 of [RFC9200]), as well as in the access token response sent as a reply by the AS (see Section 5.8.2 of [RFC9200]). 3.1.1. In the Access Token Request The "token_upload" parameter is OPTIONAL to include in an access token request. The presence of this parameter indicates that C opts in to use the SDC 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 access token response will have to include certain information, in the case that the AS has successfully uploaded the issued access token to the RS. * 0: The access token response will have to include neither the access token nor its corresponding token hash. Note that it is not useful to specify the value 0 if C wishes to use the method defined in [RFC9770] for receiving notifications about revoked access tokens from the AS. In such case, C needs to specify one of the two alternative values 1 or 2 defined below. * 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. Tiloca & Selander Expires 6 May 2027 [Page 13] Internet-Draft New ACE Workflow and Parameters November 2026 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. 3.1.2. In the Access Token Response The "token_upload" parameter MUST be included in an access token response, if both the following conditions apply. Otherwise, the "token_upload" parameter MUST NOT be included. * The corresponding access token request from C included the "token_upload" parameter, with value 0, 1, or 2. * The AS has attempted to upload an access token to the RS as per the SDC workflow, irrespective of the result of the token upload. The following considers three possible cases, with reference to the issued access token pertaining to the access token response: * CASE_1 - The issued access token is the first one of a new token series, aligned with the access token request that asked to issue the first access token of a new token series. * CASE_2 - The issued access token is not the first one in a token series, aligned with the access token request that asked to dynamically update the access rights of C, i.e., to issue a new access token of an existing token series. Section 3.7 further describes this case. * CASE_3 - The issued access token is the first one of a new token series, although the access token request asked to dynamically update the access rights of C, i.e., to issue a new access token of an existing token series. The new token series to which the issued access token belongs is created by the AS "on the fly", when receiving the specific error code "missing_old_token" from the RS (see Section 3.7.1 and Section 3.7.2), after uploading an access token intended for updating the access rights of C as indicated in the access token request. In this case, the AS does not upload the issued access token at the RS, and it provides the access token to C in the access token response. Section 3.7.2.1 further describes this case. Tiloca & Selander Expires 6 May 2027 [Page 14] Internet-Draft New ACE Workflow and Parameters November 2026 When the "token_upload" parameter is included 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 CASE_1 or CASE_2 applies and the token upload at the RS was successful, then the "token_upload" parameter MUST encode the value 0. * If CASE_1 or CASE_2 applies and the token upload at the RS was not successful, then the "token_upload" parameter MUST encode the value 1. * If CASE_3 applies, then the "token_upload" parameter MUST encode the value 2. When the access token targets a group-audience (see Section 6.9 of [RFC9200]), the same as above holds, with the following differences: * If CASE_1 or CASE_2 applies, the access token response includes the "token_upload" parameter encoding the value 0 and thus indicates that the token upload was successful, if and only if the token upload was successful at each RS in the group-audience. * In the case that the token upload fails at an RS in the group- audience, the AS MUST continue uploading the access token at the remaining RSs in the group-audience, with the following exception: if the access token is uploaded together with the "updated_rights" parameter (see Section 3.7) and the token upload fails with the AS receiving an error response that includes the error code "missing_old_token" (see Section 3.7.1 and Section 3.7.2), then the AS MUST NOT upload the access token to any remaining RS in the group-audience and it creates a new token series "on the fly" (see Section 3.7.2.1), i.e., CASE_3 applies. In the case that the "token_upload" parameter encodes the value 1 or 2, the access token response MUST include the "access_token" parameter specifying the issued access token. Instead, in the case that the "token_upload" parameter encodes the value 0, 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. Tiloca & Selander Expires 6 May 2027 [Page 15] Internet-Draft New ACE Workflow and Parameters November 2026 * 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. When C receives an access token response that includes the "token_upload" parameter encoding the value 2 (see Section 3.7.2.1), the AS is explicitly telling C that: * The dynamic update of access rights that was asked through the access token request did not succeed. * The RS does not store an old access token belonging to the token series that C asked to extend. Profiles of ACE typically prescribe that, in such case, the RS does not have anymore the secure communication association that was previously shared with C and bound to such old access token. * The issued access token is the first one of a new token series. Consequently, C takes the next steps with the RS according to the profile of ACE used, e.g., C establishes a secure communication association with the RS and bound to the issued access token of the new token series. When the access token targets a group-audience, the RS that does not store an old access token is the RS that replied to the AS with an error response including the error code "missing_old_token", which results in the AS creating a new token series "on the fly" (see above). In such case, C takes the next steps with all the RSs in the group-audience according to the profile of ACE used, e.g., C establishes a secure communication association with each RS in the group-audience and bound to the issued access token of the new token series. Tiloca & Selander Expires 6 May 2027 [Page 16] Internet-Draft New ACE Workflow and Parameters November 2026 3.1.3. 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 the case that 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. Tiloca & Selander Expires 6 May 2027 [Page 17] Internet-Draft New ACE Workflow and Parameters November 2026 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, 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 2. That is, C indicates that it requires the access token from the AS, even in the case that the AS successfully uploads the access token to the RS. Tiloca & Selander Expires 6 May 2027 [Page 18] Internet-Draft New ACE Workflow and Parameters November 2026 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' } } } Tiloca & Selander Expires 6 May 2027 [Page 19] Internet-Draft New ACE Workflow and Parameters November 2026 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 the case that 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. Tiloca & Selander Expires 6 May 2027 [Page 20] Internet-Draft New ACE Workflow and Parameters November 2026 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 an access token response sent by the AS (see Section 5.8.2 of [RFC9200]), in reply to an access token request sent to the token endpoint by C. Tiloca & Selander Expires 6 May 2027 [Page 21] Internet-Draft New ACE Workflow and Parameters November 2026 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 MUST be included in an access token response, if both the following conditions apply. Otherwise, it MUST NOT be included. * The corresponding access token request included the "token_upload" parameter with value 1 (see Section 3.1.1). * The access token response includes the "token_upload" parameter with value 0 (see Section 3.1.2). 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 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. Tiloca & Selander Expires 6 May 2027 [Page 22] Internet-Draft New ACE Workflow and Parameters November 2026 - 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 that would be 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 specific hash function used MUST be collision resistant on byte strings and MUST be selected from the "Named Information Hash Algorithm Registry" [Hash.Algorithms]. 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 Section 4 of [RFC9770], 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 [RFC9770], 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 that 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 the case that 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 Tiloca & Selander Expires 6 May 2027 [Page 23] Internet-Draft New ACE Workflow and Parameters November 2026 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. Tiloca & Selander Expires 6 May 2027 [Page 24] Internet-Draft New ACE Workflow and Parameters November 2026 3.3. to_rs and from_rs The rest of this section defines the additional parameters "to_rs" (see Section 3.3.1) and "from_rs" (see Section 3.3.2). The "to_rs" parameter can be used in an access token request sent by C to the token endpoint at the AS (see Section 5.8.1 of [RFC9200]). The "from_rs" parameter can be used in an access token response sent by the AS (see Section 5.8.2 of [RFC9200]), in reply to an access token request sent to the token endpoint by C. The semantics and encoding of the information specified in the two parameters depend on the specific profile of ACE and application used. For instance, when using the OSCORE profile [RFC9203], C and RS can use the two parameters to exchange the expected nonces and identifiers via the AS. Section 3.3.3 describes how the two parameters are used when the OSCORE profile is used, thereby effectively enabling the use of the SDC workflow for that profile. 3.3.1. to_rs The "to_rs" parameter is OPTIONAL to include 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 Section 2. The "to_rs" parameter MUST NOT be included if the "token_upload" parameter defined in Section 3.1 is not included in the access token request. Also, this parameter MUST NOT be included if the requested access token is not the first one of a new token series, i.e., if C is asking the AS for a new access token in the same token series that dynamically updates access rights. The information specified in the "to_rs" parameter consists in what C would provide to the RS in addition to the access token, if the original workflow was used and a POST request encoded in CBOR was sent to the authz-info endpoint at the RS. When composing the parameter "to_rs", C considers the same information and MUST wrap it in a data structure STRUCT, by using the same method that it employs when using the original workflow. For example, with reference to the OSCORE profile of ACE [RFC9203], such a method composes STRUCT as a CBOR map, which has to be sent as payload of a request with Content-Format "application/ace+cbor". Tiloca & Selander Expires 6 May 2027 [Page 25] Internet-Draft New ACE Workflow and Parameters November 2026 After that, C builds a CBOR byte string STR, whose value is the binary representation of STRUCT. If and only if the request to the authz-info endpoint has to be sent with a Content-Format ct different from the one employed in the profile of ACE used, then C MUST tag the CBOR byte string STR (see Section 3.4 of [RFC8949]). The tag number TN MUST be the one associated with the Content-Format ct and is determined according to the technique described in Appendix B of [RFC9277]. For example, the Content-Format "application/ace+cbor" has Content-Format ID 19 and therefore has 1668546836 as its associated tag number. When the access token request is encoded in CBOR, the value of the "to_rs" parameter is the (tagged) CBOR byte string STR. When the access token request is encoded in JSON, the value of the "to_rs" parameter is a text string, which encodes the binary representation of the (tagged) CBOR byte string STR in base64url without padding (see Section 5 of [RFC4648]). If the "to_rs" parameter is included, the AS proceeds as follows when composing the POST request to send to the authz-info endpoint on behalf of C: 1. The AS sets the Content-Format of the request to be either: * the one employed in the profile of ACE used, if the CBOR byte string STR conveyed by the "to_rs" parameter is not tagged; or, otherwise, * the one associated with the tag number TN of the tagged CBOR byte string STR conveyed by the "to_rs" parameter. 2. The AS retrieves the structure STRUCT from STR and extends STRUCT by adding the issued access token, consistent with the profile of ACE used and the Content-Format determined at the previous step. For example, when using the OSCORE profile of ACE [RFC9203] and thus the Content-Format to use is "application/ace+cbor", STRUCT is a CBOR map and the access token is included therein as an entry that has: as map key, 1 encoded as a CBOR integer; as map value, a CBOR byte string whose value is the binary representation of the access token. Clearly, performing the two steps above requires the AS to understand the structure STRUCT and its semantics. In turn, such an understanding builds on the AS supporting the profile of ACE used and the Content-Format to use as determined at Step 1. In the expected Tiloca & Selander Expires 6 May 2027 [Page 26] Internet-Draft New ACE Workflow and Parameters November 2026 cases, the AS is realistically able to perform the two steps. If the AS finds itself unable to perform the two steps, then the AS would simply not upload the access token to the RS on behalf of C. In such a case, the AS replies to C with an access token response, which includes the "access_token" parameter specifying the issued access token and does not include the "token_upload" parameter (see Section 3.1). Tagging the CBOR byte string as defined above ensures that the AS can relay the information specified in the "to_rs" parameter as intended by C, i.e., by sending to the authz-info endpoint a POST request that has the correct Content-Format and conveys the correct payload. As a case in point, using the DTLS profile of ACE [RFC9202] typically results in a POST request to the authz-info endpoint with Content- Format "application/cwt", as per Section 5.10 of [RFC9200]. However, the DTLS profile of ACE can be combined with application profiles of [RFC9594]. In such a case, the POST request might convey both the access token and additional parameters from C (e.g., "sign_info" defined in Section 3.3 of [RFC9594]), which requires the request to have Content-Format "application/ace+cbor" (see Section 3.3 of [RFC9594]). 3.3.2. from_rs The "from_rs" parameter is OPTIONAL to include in an access token response. The presence of this parameter indicates that the AS is relaying 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 Section 2. The "from_rs" parameter MUST be included in an access token response if both the following conditions apply. Otherwise, it MUST NOT be included. * The corresponding access token request included the "token_upload" parameter (see Section 3.1.1). * The access token response includes the "token_upload" parameter with value 0 (see Section 3.1.2). That is, the AS has successfully uploaded the issued access token to the RS, as per the SDC workflow. The information specified in the "from_rs" parameter consists in what C would receive from the RS, if the original workflow was used and the RS sent a successful response encoded in CBOR, in reply to a POST request to the authz-info endpoint. Tiloca & Selander Expires 6 May 2027 [Page 27] Internet-Draft New ACE Workflow and Parameters November 2026 When composing the parameter "from_rs", the AS builds a CBOR byte string STR as follows: * If the successful response from the authz-info endpoint does not include a payload, then STR is the empty CBOR byte string (0x40); otherwise, * The value of STR is the payload of the successful response from the authz-info endpoint. If and only if the response specifies a given Content-Format ct (i.e., by means of the CoAP Content-Format Option), then the AS MUST tag the CBOR byte string STR (see Section 3.4 of [RFC8949]). The tag number TN MUST be the one associated with the Content- Format ct and is determined according to the technique described in Appendix B of [RFC9277]. When the access token response is encoded in CBOR, the value of the "from_rs" parameter is the (tagged) CBOR byte string STR. When the access token response is encoded in JSON, the value of the "from_rs" parameter is a text string, which encodes the binary representation of the (tagged) CBOR byte string STR in base64url without padding (see Section 5 of [RFC4648]). When C receives from the AS the access token response specifying the "token_upload" parameter with value 0, C retrieves from the "from_rs" parameter the information relayed by the AS, just like when retrieving that information from a successful response with Content- Format ct that C receives from the RS when using the original workflow. In particular, if the CBOR byte string STR is not the empty CBOR byte string (0x40), C considers as the Content-Format ct either: * the one employed in the profile of ACE used, if the CBOR byte string STR conveyed by the "from_rs" parameter is not tagged; or, otherwise, * the one associated with the tag number TN of the tagged CBOR byte string STR conveyed by the "from_rs" parameter. 3.3.3. Use with the OSCORE Profile This section describes how to use the parameters "to_rs" and "from_rs" when the OSCORE profile of ACE [RFC9203] is used. Tiloca & Selander Expires 6 May 2027 [Page 28] Internet-Draft New ACE Workflow and Parameters November 2026 Within the access token request from C to the AS, the value of the "to_rs" parameter is a CBOR byte string, whose value is the binary representation of a CBOR map C_MAP composed of two fields: * A field with the CBOR integer 40 as map key and with value the nonce N1 generated by C, encoded as a CBOR byte string (see Section 4.1 of [RFC9203]). * A field with the CBOR integer 43 as map key and with value the Recipient ID ID1 generated by C, 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 sets the Content-Format of the request to "application/ace+cbor" and 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 and with the CBOR integer 1 as map key. * The "nonce1" field, with value the same CBOR byte string specified by the field of C_MAP that has the CBOR 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 integer 43 as map key. If 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, which has Content-Format "application/ace+cbor" and whose payload is a CBOR map RS_MAP that includes: * The "nonce2" field, with value the nonce N2 generated by the RS, encoded as 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, encoded as a CBOR byte string (see Section 4.2 of [RFC9203]). Within the access token response from the AS to C, the value of the "from_rs" parameter is a CBOR byte string, whose value is the binary representation of a CBOR map composed of two elements: * A field with the CBOR integer 42 as map key and with value the same CBOR byte string specified by the "nonce2" field of RS_MAP. Tiloca & Selander Expires 6 May 2027 [Page 29] Internet-Draft New ACE Workflow and Parameters November 2026 * A field with the CBOR 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 access token response specifying the "token_upload" parameter with value 0, C retrieves the nonce N2 and the Recipient ID ID2 from the "from_rs" parameter, just like when retrieving those from the payload of a 2.01 (Created) response received from the RS when using the original 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 the case that 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 (see Section 3.2.1 of [RFC9203]). 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. Tiloca & Selander Expires 6 May 2027 [Page 30] Internet-Draft New ACE Workflow and Parameters November 2026 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 : 2 / coap_oscore /, / 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". The two parameters can be used in an access token response sent by the AS (see Section 5.8.2 of [RFC9200]), in reply to an access token request sent to the token endpoint by C. Tiloca & Selander Expires 6 May 2027 [Page 31] Internet-Draft New ACE Workflow and Parameters November 2026 * The "rs_cnf2" parameter is OPTIONAL to include in an access token response, 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 included. Also, the "rs_cnf2" parameter MUST NOT be included if the issued access token is not the first one of a new token series. This parameter specifies information about the public keys used by the RSs of the group-audience for authenticating themselves to C. It is used in the case that 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 included, this parameter MUST encode a non-empty array of N elements, where N is the number of RSs in the group-audience for which the access token is issued. The array is encoded as a CBOR array or a JSON array, depending on whether the access token response is encoded in CBOR or JSON, respectively. Each element of the array specifies the public key of an RS in the group-audience, and it 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 array rely on the same confirmation method. Any of the public keys may be provided together with information such as the public key algorithm and use (e.g., specified by means of the parameters "alg" and "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 MUST reply with a response code equivalent to the CoAP code 4.00 (Bad Request). * The "audience2" parameter is OPTIONAL to include in an access token response, and it specifies the identifiers of the RSs in the group-audience for which the access token is issued. The "audience2" parameter MUST NOT be included if the issued access token is not the first one of a new token series. Tiloca & Selander Expires 6 May 2027 [Page 32] Internet-Draft New ACE Workflow and Parameters November 2026 If included, this parameter MUST encode a non-empty array of N elements, where N is the number of RSs in the group-audience for which the access token is issued. The array is encoded as a CBOR array or a JSON array, depending on whether the access token response is encoded in CBOR or JSON, respectively. Each element of the array in the "audience2" parameter specifies the identifier of an RS in the group-audience. The value of each element of the array is encoded as a CBOR text string or a JSON string, depending on whether the access token response is encoded in CBOR or JSON, respectively. The element of the 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 MUST be included if the "rs_cnf2" parameter is included. In such a case, the i-th element of the array in the "audience2" parameter MUST be the identifier of the RS whose public key is specified by the i-th element of the 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, namely "rs1" and "rs2", and bound to C's public key as an asymmetric PoP key. The access token response includes the access token as well as the parameters "audience2" and "rs_cnf2". These parameters specify the public keys of the two RSs as the intended recipients of the access token and the identifiers of those two RSs, respectively. Tiloca & Selander Expires 6 May 2027 [Page 33] Internet-Draft New ACE Workflow and Parameters November 2026 Access token response Header: Created (Code=2.01) Content-Format: 19 (application/ace+cbor) Max-Age: 3600 Payload: { / access_token / 1 : h'd08343a1...4819', / (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. The parameter can be used in an access token response sent by the AS (see Section 5.8.2 of [RFC9200]), in reply to an access token request sent to the token endpoint by C. Tiloca & Selander Expires 6 May 2027 [Page 34] Internet-Draft New ACE Workflow and Parameters November 2026 The "anchor_cnf" parameter is OPTIONAL to include in an access token response, if the token type is "pop" and asymmetric keys are used. Otherwise, the "anchor_cnf" parameter MUST NOT be included. Also, the "anchor_cnf" parameter MUST NOT be included if the issued access token is not the first one of a new token series. 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 included, this parameter MUST encode a non-empty array that MUST be treated as a set, i.e., the order of its elements has no meaning. Each element of the 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. The array is encoded as a CBOR array or a JSON array, depending on whether the access token response is encoded in CBOR or JSON, respectively. Each element of the 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 array rely on the same confirmation method. Any of the public keys conveyed in the "anchor_cnf" parameter may be provided together with information such as the public key algorithm and use (e.g., specified by means of the parameters "alg" and "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 the present 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. Tiloca & Selander Expires 6 May 2027 [Page 35] Internet-Draft New ACE Workflow and Parameters November 2026 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. The particular way that C uses to verify such an association as well as the particular relationships between the identifiers of group- audiences and the identifiers of RSs specified in the "audience2" parameter are application specific. 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. Specifically when the access token is issued for a group-audience G_Aud and the access token response includes the "anchor_cnf" parameter but not the "audience2" parameter, the following applies in order to prevent C from erroneously believing that G_Aud includes a given RS that is not included therein. Unless a public key PK_Anchor specified within the "anchor_cnf" parameter comprises or is accompanied by information about the RSs included in G_Aud, PK_Anchor MUST be uniquely associated with G_Aud. In particular, PK_Anchor MUST NOT be usable to successfully validate the public key of an RS that is not included in G_Aud. 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 an 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. By means of the CWT confirmation method "x5chain" defined in [I-D.ietf-ace-edhoc-oscore-profile], the public key of the trust anchor is here conveyed within an X.509 certificate [RFC5280] used as the public authentication credential for that trust anchor. Tiloca & Selander Expires 6 May 2027 [Page 36] Internet-Draft New ACE Workflow and Parameters November 2026 Access token response Header: Created (Code=2.01) Content-Format: 19 (application/ace+cbor) Max-Age: 3600 Payload: { / access_token / 1 : h'd08343a1...4819', / (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 (see Section 5.8.1 of [RFC9200]), as well as in the access token response sent as a reply by the AS (see Section 5.8.2 of [RFC9200]). The following refers to the base64url encoding without padding (see Section 5 of [RFC4648]). Tiloca & Selander Expires 6 May 2027 [Page 37] Internet-Draft New ACE Workflow and Parameters November 2026 * The "token_series_id" parameter is OPTIONAL to include 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. The "token_series_id" parameter MUST NOT be included in an access token request, if the requested access token is the first one of a new token series. If included, this parameter specifies the binary identifier of the token series that the new access token is intended to extend. The identifier does not change throughout the duration of the token series and was provided to C in the 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, this parameter is a CBOR byte string, with value the identifier of the token series. When the access token request is encoded in JSON, this parameter has as value the base64url-encoded text string that encodes the identifier of the token series. * The "token_series_id" parameter is OPTIONAL to include in an access token response. The "token_series_id" parameter MUST NOT be included in an access token response, if the issued access token is not the first one of a new token series. If included, this parameter specifies the binary identifier of the token series to which the issued access token belongs. When the access token response is encoded in CBOR, this parameter is a CBOR byte string, with value the identifier of the token series. When the access token request is encoded in JSON, this parameter has as value the base64url-encoded text string that encodes the identifier of the token series. 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. Tiloca & Selander Expires 6 May 2027 [Page 38] Internet-Draft New ACE Workflow and Parameters November 2026 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 requirements above. Note that the ACE profile used 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, such claim can be the "token_series_id" claim registered in Section 12.4, which has the same semantics as the "token_series_id" parameter of an access token response encoded in CBOR. When JWTs are used as access tokens, such claim can be the "token_series_id" claim registered in Section 12.3, which has the same semantics as the "token_series_id" parameter of an access token response encoded in JSON. 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 as de facto identifier of token series, in the PSK mode of the DTLS profile [RFC9202], in the OSCORE profile [RFC9203], and in the LAKE and OSCORE profile [I-D.ietf-ace-edhoc-oscore-profile]. Tiloca & Selander Expires 6 May 2027 [Page 39] Internet-Draft New ACE Workflow and Parameters November 2026 3.7. updated_rights This section defines the additional "updated_rights" parameter. The parameter can be used in a POST request sent by the AS to the authz- info endpoint at the RS (see Section 5.10.1 of [RFC9200]), when the AS uploads an access token to the RS per the SDC workflow defined in Section 2 of the present document. The "updated_rights" parameter MUST NOT be included in the POST request to the authz-info endpoint sent by C per the original workflow defined in [RFC9200]. The "updated_rights" parameter MUST be included in the POST request sent by the AS to the authz-info endpoint at the RS, if the uploaded access token is not the first one of a new token series, i.e., if the AS has issued the access token for dynamically updating the access rights of C. Otherwise, the "updated_rights" parameter MUST NOT be included. When including the "updated_rights" parameter, the following applies: * If the POST request is encoded in CBOR, the request MUST have media type "application/ace+cbor" and its payload MUST be formatted as a CBOR map. In particular, the CBOR map MUST include the "updated_rights" parameter encoding the CBOR simple value true (0xf5) and the "access_token" parameter specifying the access token. * If the POST request is encoded in JSON, the request MUST have media type "application/ace+json" and its payload MUST be formatted as a JSON object. In particular, the JSON object MUST include the "updated_rights" parameter with value true and the "access_token" parameter specifying the access token. Note that this request deviates from the POST request defined in [RFC9200], although such a deviation can already occur in some profiles of ACE (e.g., see Section 4.1 of [RFC9203]) or in application profiles of [RFC9594]. Figure 10 shows an example where the AS uploads an access token at the RS on behalf of C, by sending a POST request encoded in CBOR to the authz-info endpoint at the RS. In this example, the access token dynamically updates the access rights of C by extending an existing token series, hence the request payload also conveys the "updated_rights" parameter encoding the CBOR simple value true (0xf5). Tiloca & Selander Expires 6 May 2027 [Page 40] Internet-Draft New ACE Workflow and Parameters November 2026 AS-to-RS token upload request Header: POST (Code=0.02) Uri-Host: "rs.example.com" Uri-Path: "authz-info" Content-Format: 19 (application/ace+cbor) Payload: { / access_token / 1 : h'd08343a1...4819', / (full CWT elided for brevity) / e'updated_rights' : true } Figure 10: Example of AS-to-RS POST Request to the authz-info endpoint. The access token dynamically updates the access rights of C by extending an existing token series, hence the request conveys the "updated_rights" parameter with value true (0xf6). The following focuses on interactions with the authz-info endpoint at the RS where messages are encoded in CBOR. The same as described below holds in the case that such messages are encoded in JSON and have media type "application/ace+json", with the difference that the "updated_rights" parameter with value true can be present within a JSON object conveyed by a POST request to the authz-info endpoint. 3.7.1. Processing at the RS When the RS receives a protected POST request to the authz-info endpoint from the AS and the request does not convey the "updated_rights" parameter, the RS is ensured that the access token conveyed in the request is the first one of a new token series, which the RS processes accordingly (see Section 2.1). When the RS receives a protected POST request to the authz-info endpoint from the AS and the request conveys the "updated_rights" parameter encoding the CBOR simple value true (0xf5), the RS is ensured that the access token conveyed in the request is not the first one of a new token series. Taking advantage of such explicit indication requires the RS to support the Content-Format "application/ace+cbor" and the "updated_rights" parameter. Tiloca & Selander Expires 6 May 2027 [Page 41] Internet-Draft New ACE Workflow and Parameters November 2026 If the RS does not support the Content-Format "application/ace+cbor", the RS rejects the POST request from the AS and replies with an error response that has a response code equivalent to the CoAP code 4.15 (Unsupported Content-Format). Note that, irrespective of the profile of ACE used, the RS supports the Content-Format "application/ ace+cbor" if it implements token introspection as defined in Section 5.9 of [RFC9200]. If the RS supports the Content-Format "application/ace+cbor" but does not support the "updated_rights" parameter, the RS rejects the POST request from the AS and replies with an error response that has a response code equivalent to the CoAP code 4.00 (Bad Request). In the case that a POST request to the authz-info endpoint includes the "updated_rights" parameter, the RS supports the parameter, and any of the following conditions applies, then the RS MUST reject the request and MUST reply with an error response that has a response code equivalent to the CoAP code 4.00 (Bad Request): * The request is not protected. * The AS is not successfully verified as the originator of the request. * The "updated_rights" parameter does not encode the CBOR simple value true (0xf5). If none of the error conditions above applies and the request is valid, then the RS leverages the "updated_rights" parameter encoding the CBOR simple value true (0xf5) as an indication from the AS that the access token conveyed in the POST request, namely T_NEW, is not the first one of its token series. That is, the access token is meant to dynamically update the access rights of C, while preserving the same secure communication association that is shared between C and the RS. In this case, the RS uses lookup information specified within T_NEW to determine whether it stores an access token T_OLD associated with C and belonging to the same token series of T_NEW. Such lookup information includes an identifier of the token series to which both T_NEW and T_OLD belong, and it can further comprise additional information elements pertaining to the specific profile of ACE used (e.g., the authentication credential of C that is bound to the access tokens of the token series). Tiloca & Selander Expires 6 May 2027 [Page 42] Internet-Draft New ACE Workflow and Parameters November 2026 By leveraging such lookup information, the RS checks whether it stores an access token T_OLD that belongs to the same token series of T_NEW, like it would when receiving the request from C and according to the specific profile of ACE used. If the RS is currently storing such an old access token T_OLD and successfully validates the access token T_NEW, then the new access token T_NEW supersedes T_OLD, i.e., the RS MUST replace the authorization information specified in T_OLD with that specified in T_NEW, and it MUST associate T_NEW with the same secure communication association with which T_OLD was associated. Finally, the RS replies to the AS with a successful response that has a response code equivalent to the CoAP code 2.01 (Created). Instead, if the RS is not currently storing such an old access token T_OLD, then the RS MUST reject the POST request from the AS and MUST reply with an error response that has a response code equivalent to the CoAP code 5.00 (Internal Server Error). The error response is analogous to error responses sent by the AS (see Section 5.8.3 of [RFC9200]) and MUST include the error code "missing_old_token". The error code and its CBOR abbreviation are registered in Section 12.5 and Section 12.6, respectively. The explicit indication provided by the "updated_rights" parameter prevents possible ambiguous situations, where the RS might erroneously believe that the access token conveyed in the POST request is the first one of a new token series (e.g., following the deletion of stored access tokens due to memory limitations). This is further discussed in Section 11.1. 3.7.2. Follow-up at the AS After sending to the authz-info endpoint a protected POST request that conveys the access token T_NEW and the "updated_rights" parameter encoding the CBOR simple value true (0xf5), the AS proceeds as follows when receiving a response from the RS. * If the AS receives a successful response, the AS MUST reply to C with an access token response, consistent with the issue of the access token T_NEW. The access token response includes the "token_upload" parameter encoding the value 0 (see Section 3.1.2). Also, the access token response includes the "access_token" parameter, or the "token_hash" parameter, or none of those, depending on the value of the "token_upload" parameter in the corresponding access token request. Tiloca & Selander Expires 6 May 2027 [Page 43] Internet-Draft New ACE Workflow and Parameters November 2026 * If the AS receives an error response that includes the error code "missing_old_token" (see Section 3.7.1), the AS MUST proceed as defined in Section 3.7.2.1. * If the AS receives any other error response, the AS MUST reply to C with an access token response, consistent with the issue of the access token T_NEW. The access token response includes the "access_token" parameter specifying the access token T_NEW and the "token_upload" parameter encoding the value 1 (see Section 3.1.2). The AS MUST ignore the error code "missing_old_token", if the POST request did not convey the "updated_rights" parameter encoding the CBOR simple value true (0xf5). In the case that the access token T_NEW targets a group-audience (see Section 6.9 of [RFC9200]), what is specified in Section 3.1.2 about the token upload at the RSs in the group-audience applies to T_NEW. In particular, the AS replies to C with an access token response after the token upload of T_NEW terminates as per what is defined in Section 3.1.2. 3.7.2.1. New Token Series Created on the Fly As defined in Section 3.7.1, the RS replies to the AS with an error response that includes the error code "missing_old_token", if the RS cannot find the old access token T_OLD to be superseded by the access token T_NEW that the AS uploaded to the authz-info endpoint. Profiles of ACE typically prescribe that, in such case, the RS does not have anymore the secure communication association that was previously shared with C and bound to T_OLD. Therefore, if the AS simply completes the issue of T_NEW and provides it to C, this would result in C sending a protected POST request including T_NEW to the authz-info endpoint at the RS, according to the original workflow. However, since the RS does not store T_OLD and does not have the corresponding secure communication association used by C to protect the POST request, the RS would reply to C with an unprotected error response. After that, C would finally send a new access token request to the token endpoint at the AS, asking for a new access token of a new token series. Instead, under the specific circumstance in question, the procedure defined below avoids that C and the RS perform such an inefficient and unsuccessful exchange. In the interest of performing this procedure, an AS that supports the SDC workflow MUST store the access token request that results in issuing the first access token of a token series, until the token series ends. Tiloca & Selander Expires 6 May 2027 [Page 44] Internet-Draft New ACE Workflow and Parameters November 2026 After having uploaded T_NEW to the RS and received an error response that includes the error code "missing_old_token", the AS MUST create a new token series "on the fly", as defined below. The rest of this section uses the following notation: * REQ_STORED: the access token request that resulted in the AS issuing the first access token of the token series to which T_OLD and T_NEW belong. * REQ_RECEIVED: the access token request that resulted in the AS composing T_NEW and attempting to upload it at the RS with no success. The AS performs the following steps. 1. The AS retrieves REQ_STORED from its local storage. 2. The AS composes a new access token request REQ_BUILT that is equal to REQ_STORED retrieved at Step 1, with the following differences: * The "scope" parameter is present in REQ_BUILT if and only if the "scope" parameter is present in the access token request REQ_RECEIVED. If present, the "scope" parameter in REQ_BUILT specifies the same scope that is specified by the "scope" parameter within REQ_RECEIVED. * The parameters "token_upload" (see Section 3.1), "to_rs" (see Section 3.3.1), and "cnonce" (see Section 5.8.4.4 of [RFC9200]) are not included in REQ_BUILT. 3. The AS revokes the access tokens T_OLD and T_NEW, thus ending the token series they belong to. The AS can rely on the method defined in [RFC9770] to notify about the revoked access tokens. Then, the AS deletes REQ_STORED from its local storage. 4. The AS processes REQ_BUILT as if it was received from C. If the AS successfully processes REQ_BUILT, the AS issues an access token T_NEXT as the first access token of a new token series. Like for T_NEW, also T_NEXT is issued to C, for the same targeted audience, and per the same profile of ACE. Like any other access token request that results in starting a new token series, the AS stores REQ_BUILT throughout the duration of the new token series to which T_NEXT belongs. Tiloca & Selander Expires 6 May 2027 [Page 45] Internet-Draft New ACE Workflow and Parameters November 2026 5. The AS replies to REQ_RECEIVED with an access token response consistent with the issue of T_NEXT as the first access token of a new token series. In particular, the following applies to the access token response: * The "access_token" parameter is present and specifies the access token T_NEXT. * The "token_upload" parameter is present and encodes the value 2 (see Section 3.1.2). * The "scope" parameter is present if and only if: i) it was present in REQ_BUILT and the access rights granted to C are different from the requested ones; or ii) it was not present in REQ_BUILT and the access rights granted to C are different from the default ones. If the "scope" parameter is not present, then the granted access rights are those requested by the "scope" parameter in REQ_BUILT if present therein, or the default access rights otherwise. The granted access rights are specified by the issued access token T_NEXT. 4. Updated ace_profile Parameter This section extends the semantics of the "ace_profile" parameter defined in [RFC9200] for the OAuth 2.0 token endpoint at the AS. In addition to what is specified in Sections 5.8.1, 5.8.2, and 5.8.4.3 of [RFC9200], the following applies. * When sending an access token request to the token endpoint at the AS (see Section 5.8.1 of [RFC9200]), C MAY include the "ace_profile" parameter, specifying the identifier of the profile that C wishes to use towards the RS. The "ace_profile" parameter MUST NOT be included in an access token request, if the requested access token is not the first one of a new token series. * If the AS receives an access token request for requesting the first access token of a new token series and the request includes the "ace_profile" parameter specifying the identifier of a profile, then the AS proceeds as follows. Tiloca & Selander Expires 6 May 2027 [Page 46] Internet-Draft New ACE Workflow and Parameters November 2026 In the case that 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 MUST reply with an error response (see Section 5.8.3 of [RFC9200]). 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 the case that 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 the case that the AS replies to C with an access token response (see Section 5.8.2 of [RFC9200]), then the response MAY include the "ace_profile" parameter. If it is included in the access token response, the "ace_profile" parameter MUST encode the same profile identifier that was specified by the "ace_profile" parameter of the corresponding access token request. The "ace_profile" parameter MUST NOT be included in the access token response, if the issued access token is not the first one of a new token series. 5. 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 LAKE and OSCORE profile [I-D.ietf-ace-edhoc-oscore-profile] and in the DTLS profile [RFC9202] as extended in [I-D.ietf-ace-authcred-dtls-profile]. 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 its 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 Tiloca & Selander Expires 6 May 2027 [Page 47] Internet-Draft New ACE Workflow and Parameters November 2026 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 Section 5.1). * 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 Section 5.2), or instead to omit the credential(s) from the access token response. 5.1. 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 MUST reply with an error response (see Section 5.8.3 of [RFC9200]). 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 Section 12.5 and Section 12.6, 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. 5.2. 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). Tiloca & Selander Expires 6 May 2027 [Page 48] Internet-Draft New ACE Workflow and Parameters November 2026 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 Section 3.2 of [RFC9201], 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 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 when requesting the first access token in a token series, if the token type is "pop" and asymmetric keys are used. In any other case, the parameter MUST NOT be included in an access token request. When C includes the "rs_cnf" parameter in an access token request encoded in CBOR, 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 access token response the "rs_cnf" or "rs_cnf2" parameter, specifying the authentication credential(s) of the RS(s) by value. In the 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 access token response the "rs_cnf" or "rs_cnf2" parameter, specifying the authentication credential(s) of the RS(s) by reference. In the access token response, each pertaining authentication credential MUST be specified by reference, or alternatively by value only if that was not possible for the AS to attain. * 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 access token response. In the access token response, the "rs_cnf" and "rs_cnf2" parameters MUST NOT be included. Tiloca & Selander Expires 6 May 2027 [Page 49] Internet-Draft New ACE Workflow and Parameters November 2026 If the access token request is encoded in JSON, the same as above applies, with the difference that the "rs_cnf" parameter specifies as appropriate the corresponding JSON values true, false, or null. If the AS is not able to comply in the first two cases above, then the AS MUST reject the request and MUST 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, the parameter "rs_cnf" or "rs_cnf2" in the access token response specifies the authentication credential(s) used by the RS(s) to authenticate. In the case that C includes the "rs_cnf" parameter in the access token request and C does not currently store the authentication credential(s) of the RS(s) in the targeted audience, then the following applies: * The "rs_cnf" parameter MUST NOT specify the CBOR simple value null (0xf6) if the access token request is encoded in CBOR, or the value null if the access token request is encoded in JSON. * The "rs_cnf" parameter SHOULD NOT specify the CBOR simple value false (0xf4) if the access token request is encoded in CBOR, or the value false if the access token request is encoded in JSON. Exceptions apply if C is confident that it can later acquire and validate the authentication credential(s) of the RS(s) by other means, e.g., by using the references provided by the AS for retrieval from a trusted repository. 6. Failed Verification of Proof of Possession at the AS When sending an access token request to the AS (see Section 5.8.1 of [RFC9200]), a client can include the "req_cnf" parameter defined in Section 3.1 of [RFC9201] in order to provide the AS with a specific PoP key to bind to the requested access token. Typically, the PoP key in question is the client's public key. In such a case, as per Section 3.1 of [RFC9201], the AS has to verify proof of possession of the client's private key, i.e., that the client is indeed in possession of the private key corresponding to the public key conveyed in the "req_cnf" parameter. The AS might have previously achieved proof of possession of the private key in question, e.g., from previous interactions with the client or through out-of-band means. Alternatively, a profile of ACE might define how the AS verifies a PoP evidence that the client Tiloca & Selander Expires 6 May 2027 [Page 50] Internet-Draft New ACE Workflow and Parameters November 2026 computes and provides to the AS by means of a parameter included in the access token request (e.g., see [I-D.ietf-ace-group-oscore-profile]). Irrespective of the method used, if the AS fails to verify the proof of possession of the client's private key, then the AS MUST reject the access token request and MUST reply with an error response (see Section 5.8.3 of [RFC9200]). The error response MUST have a response code equivalent to the CoAP code 4.00 (Bad Request) and MUST include the error code "failed_pop_verification". The error code and its CBOR abbreviation are registered in Section 12.5 and Section 12.6, respectively. 7. 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: * It MUST include the Custom Problem Detail entry "ace-error" registered in Section 12.7 of this document. This entry is formatted as a CBOR map including only one field, namely "error-code". The map key for the "error-code" field is the CBOR integer with value 0. The value of the "error-code" field 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 [OAuth.Error.Code.CBOR.Mappings]. The "error-code" field conveys the same information that the original payload format conveys through the "error" parameter (see, e.g., Sections 5.8.3 and 5.9.3 of [RFC9200]). The CDDL notation [RFC8610] of the "ace-error" entry is given below. Tiloca & Selander Expires 6 May 2027 [Page 51] Internet-Draft New ACE Workflow and Parameters November 2026 ace-error = { &(error-code: 0) => int } * It MAY include further Standard Problem Detail entries or Custom Problem Detail entries (see [RFC9290]). 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 Section 2 of [RFC9290]). The diagnostic text is intended for software engineers as well as for device and network operators in order to aid in debugging and provide context for possible intervention. The diagnostic message SHOULD be logged by the sender of the error response. The "detail" entry is unlikely to be relevant in an unattended setup where human intervention is not expected. When the Standard Problem Detail entry "detail" is included, it conveys the same information that the original payload format conveys through the "error_description" parameter (see, e.g., Sections 5.8.3 and 5.9.3 of [RFC9200]). - "instance" (map key -3): its value is a URI reference identifying the specific occurrence of the error (see Section 2 of [RFC9290]). When the Standard Problem Detail entry "instance" is included, it conveys the same information that the original payload format conveys through the "error_uri" parameter (see, e.g., Sections 5.8.3 and 5.9.3 of [RFC9200]). An example of an 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 / } } Tiloca & Selander Expires 6 May 2027 [Page 52] Internet-Draft New ACE Workflow and Parameters November 2026 Figure 11: 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. 8. Updated Requirements on Profiles of ACE 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). Tiloca & Selander Expires 6 May 2027 [Page 53] Internet-Draft New ACE Workflow and Parameters November 2026 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. 9. LAKE EAD Item for Transporting a Session Identifier The Lightweight Authenticated Key Exchange (LAKE) protocol [RFC9528] defines the transport of additional External Authorization Data (EAD) within an optional EAD field of the LAKE messages (see Section 3.8 of [RFC9528]). An EAD field is composed of one or multiple EAD items, each of which specifies an identifying 'ead_label' encoded as a CBOR integer and an optional 'ead_value' encoded as a CBOR byte string. When using the LAKE and OSCORE profile of ACE defined in [I-D.ietf-ace-edhoc-oscore-profile], C and the RS run the LAKE protocol to establish an OSCORE Security Context [RFC8613], which is used to secure communications when C accesses protected resources at the RS, according to the authorization information indicated in an access token. Specifically, the access token is bound to C's authentication credential AUTH_CRED_C that C uses during the LAKE session for authenticating itself to the RS. Per the LAKE and OSCORE profile, the first access token of a token series is specified by C to the RS during a LAKE session between the two peers. To this end, Section 4.1 of [I-D.ietf-ace-edhoc-oscore-profile] defines the EAD item ACE-OAuth Access Token for specifying an access token by value in the EAD field of a LAKE message from C to the RS. This section defines an alternative EAD item for specifying an access token by reference, through its associated LAKE session identifier. The name of the EAD item is Session ID, for which the CDDL grammar is shown in Figure 12. ead_session_id = ( ead_label : e'ead_session_id_label', ead_value : session_id ) session_id = bstr Figure 12: LAKE EAD Item Session ID. In particular: * ead_label is the integer value TBD registered in Section 12.8. Tiloca & Selander Expires 6 May 2027 [Page 54] Internet-Draft New ACE Workflow and Parameters November 2026 * ead_value is a CBOR byte string equal to the value of the "session_id" field within the LAKE_Information object specified by the "lake_info" parameter of the access token response from the AS, when issuing the first access token of a token series (see Section 3.3 of [I-D.ietf-ace-edhoc-oscore-profile]). Note to RFC Editor: Please replace TBD with the value registered for Session ID in Section 12.8, then delete this note. This EAD item is critical, i.e., it is used only with the negative value of its ead_label, indicating that the receiving RS must progress the protocol using the access token associated with the identifier specified in the ead_value and with the AUTH_CRED_C used in the LAKE session, or else abort the LAKE session (see Section 3.8 of [RFC9528]) The EAD Item Session ID is useful in two circumstances: * When using the SDC workflow defined in Section 2, C can indicate to the AS that it does not want to receive the issued access token (i.e., the access token request specifies the "token_upload" parameter with value 0 or 1), in the case that the AS successfully uploads the access token to the RS (i.e., the access token response specifies the "token_upload" parameter with value 0). Even in such a case where C does not obtain the issued access token, C obtains the "session_id" associated with the access token and specified in the access token response. Consequently, C can still specify the access token by reference during the LAKE session with the RS, by using the EAD item Session ID. * After having completed a LAKE session with the RS and while still storing a valid access token, C might choose to re-run LAKE with the RS. For example, the LAKE session or the derived OSCORE Security Context might have become invalid, or C receives unprotected error responses from the RS and determines that the RS has deleted the Security Context (e.g., due to memory limitations). As another example, C could want to update its current secure communication association with the RS by establishing a new OSCORE Security Context, specifically through a new LAKE session to leverage the exchange of ephemeral keys. Even in such a case where C can specify the access token by value, it is possible for C to instead specify the access token by reference during the LAKE session with the RS, by using the EAD item Session ID as a way to reduce communication overhead. Tiloca & Selander Expires 6 May 2027 [Page 55] Internet-Draft New ACE Workflow and Parameters November 2026 The EAD item Session ID is used only when uploading the first access token of a token series, but not for the dynamic update of access rights (see Section 4.7 of [I-D.ietf-ace-edhoc-oscore-profile]). Analogously to the EAD item ACE-OAuth Access Token defined in Section 4.1 of [I-D.ietf-ace-edhoc-oscore-profile] and consistent with what is defined in Section 4.2 of [I-D.ietf-ace-edhoc-oscore-profile], the EAD item Session ID is used to specify the access token by reference as follows: * If the LAKE forward message flow is used (see Section 4.3 of [I-D.ietf-ace-edhoc-oscore-profile]), the EAD item is included in the EAD_3 field of LAKE message_3. As per Section 4.3.3 of [I-D.ietf-ace-edhoc-oscore-profile], the EAD_3 field must not include multiple EAD items specifying the access token. * Instead, if the LAKE reverse message flow is used (see Section 4.4 of [I-D.ietf-ace-edhoc-oscore-profile]), the EAD item is included in the EAD_4 field of LAKE message_4. As per Section 4.4.5 of [I-D.ietf-ace-edhoc-oscore-profile], the EAD_4 field must not include multiple EAD items specifying the access token. A client or resource server MUST support the EAD item Session ID if it both supports the SDC workflow and implements the LAKE and OSCORE profile of ACE. Consequently, C is ensured that the RS supports the EAD item Session ID when C receives an access token response specifying the "token_upload" parameter with value 0 and not including the "access_token" parameter, following the issue of an access token for accessing protected resources at the RS. Besides that, C can learn about the RS' support for the EAD item through indications from the AS within the LAKE_Information object specified by the "lake_info" parameter of the access token response, or by using other means such as, for example, those defined in [I-D.ietf-lake-app-profiles]. Example: assuming that ead_label is 2 and that the value of the "session_id" field within the LAKE_Information object specified by the "lake_info" parameter of the access token response from the AS is equal to h'01fc', the critical EAD item is as follows: -2, h'01fc' Note to RFC Editor: Please replace the value of the ead_label with the value registered for Session ID in Section 12.8, then delete this note. Tiloca & Selander Expires 6 May 2027 [Page 56] Internet-Draft New ACE Workflow and Parameters November 2026 10. Operational Considerations This section compiles the operational considerations that hold for this document. 10.1. Logging When performing its normal operations, an AS is expected to produce timestamped logs about the following: * The reception and processing outcome of an access token request, e.g., in terms of its failure/success and issuance of an access token. * The outcome of uploading an issued access token at one or multiple RSs on behalf of the requesting client, as per the SDC workflow. * Events pertaining the lifecycle of issued access tokens (e.g., their issuance, expiration, and potential revocation) and the lifecycle of the token series to which those access tokens belong to. * The registration and deregistration of clients and RSs at the AS. Similarly, when performing its normal operations, it is desirable that an RS produces timestamped logs about the following, to the extent afforded by its available memory, computing, and energy resources: * The reception and processing outcome of an access token, e.g., in terms of its failure/success. * Events pertaining the lifecycle of processed access tokens (e.g., their rejection, acceptance, storing, and deletion). * Failed accesses to protected resources due to missing/insufficient access rights for the requesting client per the stored access tokens. Requests at the AS (e.g., from a client requesting an access token) or at the RS (e.g., for uploading an access token or for accessing a protected resource) can be effectively characterized by the transport-specific information of the request, together with the secure communication association shared with the requester as applicable. Tiloca & Selander Expires 6 May 2027 [Page 57] Internet-Draft New ACE Workflow and Parameters November 2026 Although log entries are produced by the AS/RS, the storage, management, controlled sharing, and disposal of logs could be entrusted to a designated storage point that can be the AS/RS itself or instead a separate trusted entity. Besides what is compiled above, the AS/RS could produce additional information to log. Further details about what the AS/RS logs, with what granularity, and based on what triggering events and conditions are application-specific and left to operators to define. The AS/RS MUST NOT log any secret or confidential information pertaining to its operations. For example, this includes cryptographic secrets pertaining to (the establishment of) secure communication associations and keying material derived thereof, including own private keys associated with authentication credentials used for establishing secure communication associations. It is up to the application to specify for how long a log entry is retained from the time of its creation and until its deletion. Different retention policies could be enforced, for example, depending on what log entries pertain to (e.g., the successful/failed issuance (processing) of an access token at the AS (RS)), or on the secure communication association shared with the specific requester. For a given set of log entries that are grouped together according to certain criteria, the oldest log entries are expected to be those deleted first. It is out of the scope of this document what specific semantics and data model are used by the AS/RS for producing and processing the logs. Specific semantics and data models can be defined by applications and future specifications. It is expected that the logs produced are made available for secure access by authorized external management applications and operators. In particular, logged information could be retrieved in the following ways. * By accessing logs at the designated storage point through polling. This can occur in an occasional, regular, or event-driven way. * Through notifications sent by the designated storage point according to an operator-defined frequency. * Through notifications asynchronously sent by the designated storage point, throttling them in order to prevent congestion and duplication and to not create attack vectors. Tiloca & Selander Expires 6 May 2027 [Page 58] Internet-Draft New ACE Workflow and Parameters November 2026 From the perspective of an individual management application or network operator, knowledge gained from the logged information can be useful for managing the installation, enforcement, revision, and retirement of access policies at the AS, as well as for identifying clients or RSs for which troubleshooting, upgrade, re-enrollment, eviction, or decommissioning should be considered. Some of the logged information can be privacy-sensitive. This especially holds for the metadata about clients and RSs, i.e., their addressing information and, when applicable, (identifiers of) their authentication credentials that are used to authenticate with the other parties when establishing and using a secure communication association. If external management applications and operators obtain such metadata, they become able to track a given client or RS, as to its interactions with one or multiple other clients, RSs, and/ or ASes. Therefore, the logged information that is effectively provided to external management applications and operators SHOULD be redacted by the designated storage point, by omitting any privacy-sensitive information element that could enable or facilitate the impairment of clients' and RSs' privacy, e.g., by tracking those as they interact with other parties. Exceptions could apply, e.g., if the designated storage point can verify that the management application or operator in question is specifically authorized to obtain such privacy- sensitive information and appropriately entitled to obtain it according to enforced privacy policies. 10.2. Management and Distribution of Keying Material The approach used to manage and distribute keying material depend on the specific profile of ACE used, for example [RFC9202][RFC9203][I-D.ietf-ace-edhoc-oscore-profile]. In turn, the approach used depends on the specific security protocol used between clients, RSs, and ASes, which is also specified by the profile of ACE used. Appendix C of [RFC9200] compiles the list of requirements on profiles of ACE, two of which are amended in Section 8 of the present document. Irrespective of the specific profile used, clients, RSs, and ASes that communicate with one another have to use a secure communication association and be mutually authenticated (see Section 5 of [RFC9200]). Tiloca & Selander Expires 6 May 2027 [Page 59] Internet-Draft New ACE Workflow and Parameters November 2026 10.3. Access Control The enforcement of access control at RSs is the main goal of the ACE framework. The enforcement of access control at the AS relies on the authenticated interaction of a client/RS at the AS. For example, this applies to a client sending an access token request to the token endpoint at the AS (see Section 5.8.1 of [RFC9200]), or to an RS sending a token introspection request to the introspect endpoint at the AS to perform token introspection (see Section 5.9 of [RFC9200]). For a client/RS, the secure communication association shared with the AS is bound to its active registration at the AS, which the AS maintains together with related information until a possible deregistration occurs (e.g., due to a decommissioning of the client/ RS). The registration process at the AS is out of scope for this document as well for the ACE framework (see Section 5.5 of [RFC9200]). 11. Security Considerations The same security considerations from the ACE framework [RFC9200] apply to this document, together with those from the specific profile of ACE used. When using the problem-details format defined in [RFC9290] for error responses, the privacy and security considerations from Sections 4 and 5 of [RFC9290] also apply. Furthermore, the following considerations apply. 11.1. Explicit Indication of Update of Access Rights in the SDC Workflow According to some profiles of ACE, C can request a new access token to dynamically update its access rights, while preserving the current secure communication association shared with the RS. In such case, the new access token is intended to supersede the current one stored at the RS, as they both belong to the same token series. When using the original workflow of ACE defined in [RFC9200], C uploads the new access token at the RS by protecting the message exchange through the current secure communication association shared with the RS and bound to the access token to be superseded. In fact, the use of such secure communication association allows the RS to determine that the upload of the new access token is specifically intended to updating the access rights of C. Tiloca & Selander Expires 6 May 2027 [Page 60] Internet-Draft New ACE Workflow and Parameters November 2026 When using the SDC workflow defined in this document, the AS can upload the new access token at the RS on behalf of C, i.e., also in the case where the access token is issued to dynamically update the access rights of C. In particular, the message exchange between the AS and the RS is protected by means of a secure communication association shared between the AS and the RS, irrespective of the client for which the access token is issued. The new access token certainly provides the RS with information for recognizing the stored access token to be superseded, e.g., the "token_series_id" claim defined in Section 3.6 or a different information element that the profile used relies on for other reasons. However, depending on the profile used, the new access token might not unambiguously indicate that it is specifically intended to extend an ongoing token series. Therefore, the upload of the new access token from the AS might lead to ambiguities. For example, the RS might have deleted a stored access token due to memory limitations. Although this effectively terminates the corresponding token series, such event is however impractical for the RS to remember indefinitely. Consequently, if the AS uploads at the RS a new access token belonging to that token series, it is possible that the RS accepts that access token and erroneously believes it to be the first one in a new token series, which contradicts the correct information available at the AS about the token series. The occurrence of such contradiction is prevented by means of the "updated_rights" parameter (see Section 3.7), which the AS includes in a POST request to the authz-info endpoint at the RS only when uploading an access token for dynamically updating the access rights of C. 12. 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. 12.1. OAuth Parameters Registry IANA is asked to add the following entries to the "OAuth Parameters" registry [OAuth.Parameters] within the "OAuth Parameters" registry group. * Name: token_upload * Parameter Usage Location: token request, token response Tiloca & Selander Expires 6 May 2027 [Page 61] Internet-Draft New ACE Workflow and Parameters November 2026 * 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 Tiloca & Selander Expires 6 May 2027 [Page 62] Internet-Draft New ACE Workflow and Parameters November 2026 * 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, token response * Change Controller: IETF * Reference: [RFC-XXXX] * Name: updated_rights * Parameter Usage Location: as-rs request * Change Controller: IETF * Reference: [RFC-XXXX] In the same registry, IANA is asked to update the entries for the following OAuth parameters identified by their name, so that the content of the "Parameter Usage Location" column and of the "Reference" column is as below: * access_token - Parameter Usage Location: authorization response, token response, as-rs request Tiloca & Selander Expires 6 May 2027 [Page 63] Internet-Draft New ACE Workflow and Parameters November 2026 - Reference: [RFC6749][RFC-XXXX] * rs_cnf - Parameter Usage Location: token request, token response - Reference: [RFC9201, Section 5][RFC-XXXX, Section 5.2] * nonce1 - Parameter Usage Location: client-rs request, as-rs request - Reference: [RFC9203][RFC-XXXX] * nonce2 - Parameter Usage Location: rs-client response, rs-as response - Reference: [RFC9203][RFC-XXXX] * ace_client_recipientid - Parameter Usage Location: client-rs request, as-rs request - Reference: [RFC9203][RFC-XXXX] * ace_server_recipientid - Parameter Usage Location: rs-client response, rs-as response - Reference: [RFC9203][RFC-XXXX] * sign_info - Parameter Usage Location: client-rs request, rs-client response, as-rs request, rs-as response - Reference: [RFC9594][RFC-XXXX] * kdcchallenge - Parameter Usage Location: rs-client response, rs-as response - Reference: [RFC9594][RFC-XXXX] * ecdh_info Tiloca & Selander Expires 6 May 2027 [Page 64] Internet-Draft New ACE Workflow and Parameters November 2026 - Parameter Usage Location: client-rs request, rs-client response, as-rs request, rs-as response - Reference: [RFC-ietf-ace-key-groupcomm-oscore-21][RFC-XXXX] * kdc_dh_creds - Parameter Usage Location: client-rs request, rs-client response, as-rs request, rs-as response - Reference: [RFC-ietf-ace-key-groupcomm-oscore-21][RFC-XXXX] Note to RFC Editor: In the last two entries above, please replace the occurrences of "RFC-ietf-ace-key-groupcomm-oscore-21" with the RFC number of that specification and delete this paragraph. 12.2. OAuth Parameters CBOR Mappings Registry IANA is asked to add the following entries to the "OAuth Parameters CBOR Mappings" registry [OAuth.Parameters.CBOR.Mappings] within the "Authentication and Authorization for Constrained Environments (ACE)" registry group, following the procedure specified in [RFC9200]. * 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 Tiloca & Selander Expires 6 May 2027 [Page 65] Internet-Draft New ACE Workflow and Parameters November 2026 * CBOR Key: TBD (value between 1 and 255) * Value Type: byte string or #6.(bstr) * Reference: [RFC-XXXX] * Original Specification: [RFC-XXXX] * Name: from_rs * CBOR Key: TBD (value between 1 and 255) * Value Type: byte string or #6.(bstr) * 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 Tiloca & Selander Expires 6 May 2027 [Page 66] Internet-Draft New ACE Workflow and Parameters November 2026 * 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] * Name: updated_rights * CBOR Key: TBD (value between 1 and 255) * Value Type: True * Reference: [RFC-XXXX] * Original Specification: [RFC-XXXX] In the same registry, IANA is asked to update the entry for the OAuth parameter with name "rs_cnf", so that the content of the "Value Type" column and of the "Reference" column is as below: * Value Type: True or False or Null or map * Reference: [RFC9201, Section 3.2][RFC-XXXX, Section 5.2] 12.3. JSON Web Token Claims Registry IANA is asked to add the following entry to the "JSON Web Token Claims" registry [JSON.Web.Token.Claims] within the "JSON Web Token (JWT)" registry group, following the procedure specified in [RFC7519]. Tiloca & Selander Expires 6 May 2027 [Page 67] Internet-Draft New ACE Workflow and Parameters November 2026 * Claim Name: token_series_id * Claim Description: The identifier of a token series * Change Controller: IETF * Reference: [RFC-XXXX] 12.4. CBOR Web Token (CWT) Claims Registry IANA is asked to add the following entry to the "CBOR Web Token (CWT) Claims" registry [CWT.Claims] within the "CBOR Web Token (CWT) Claims" registry group, 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 (value between 1 and 255) * Claim Value Type: byte string * Change Controller: IETF * Reference: [RFC-XXXX, Section 3.6] 12.5. OAuth Extensions Error Registry IANA is asked to add the following entries to the "OAuth Extensions Error Registry" [OAuth.Extensions.Error] within the "OAuth Parameters" registry group. * Name: missing_old_token * Usage Location: authz-info error response * Protocol Extension: [RFC-XXXX] * Change Controller: IETF * Reference: [RFC-XXXX, Section 3.7.2.1] * Name: unknown_credential_referenced Tiloca & Selander Expires 6 May 2027 [Page 68] Internet-Draft New ACE Workflow and Parameters November 2026 * Usage Location: token error response * Protocol Extension: [RFC-XXXX] * Change Controller: IETF * Reference: [RFC-XXXX, Section 5] * Name: failed_pop_verification * Usage Location: token error response * Protocol Extension: [RFC-XXXX] * Change Controller: IETF * Reference: [RFC-XXXX, Section 6] 12.6. OAuth Error Code CBOR Mappings Registry IANA is asked to add the following entries to the "OAuth Error Code CBOR Mappings" registry [OAuth.Error.Code.CBOR.Mappings] within the "Authentication and Authorization for Constrained Environments (ACE)" registry group. * Name: missing_old_token * CBOR Value: TBD (value between 1 and 255) * Reference: [RFC-XXXX] * Original Specification: [RFC-XXXX] * Name: unknown_credential_referenced * CBOR Value: TBD (value between 1 and 255) * Reference: [RFC-XXXX] * Original Specification: [RFC-XXXX] * Name: failed_pop_verification Tiloca & Selander Expires 6 May 2027 [Page 69] Internet-Draft New ACE Workflow and Parameters November 2026 * CBOR Value: TBD (value between 1 and 255) * Reference: [RFC-XXXX] * Original Specification: [RFC-XXXX] 12.7. Custom Problem Detail Keys Registry IANA is asked to register the following entry in the "Custom Problem Detail Keys" registry [Custom.Problem.Detail.Keys] within the "Constrained RESTful Environments (CoRE) Parameters" registry group. * Key Value: TBD (value between 0 and 23) * Name: ace-error * Brief Description: Carry ACE [RFC9200] problem details in a Concise Problem Details data item. * Change Controller: IETF * Reference: [RFC-XXXX, Section 7] 12.8. EDHOC External Authorization Data Registry IANA is asked to add the following entry to the "EDHOC External Authorization Data" registry [EDHOC.External.Authorization.Data] within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group. * Name: Session ID * Label: TBD (value between 1 and 23) * Description: The identifier of a LAKE session * Reference: [RFC-XXXX], Section 9 13. References 13.1. Normative References [Custom.Problem.Detail.Keys] IANA, "Custom Problem Detail Keys", . Tiloca & Selander Expires 6 May 2027 [Page 70] Internet-Draft New ACE Workflow and Parameters November 2026 [CWT.Claims] IANA, "CBOR Web Token (CWT) Claims", . [EDHOC.External.Authorization.Data] IANA, "EDHOC External Authorization Data", . [Hash.Algorithms] IANA, "Named Information Hash Algorithm Registry", . [I-D.ietf-ace-edhoc-oscore-profile] Selander, G., Mattsson, J. P., Tiloca, M., and R. Höglund, "Lightweight Authenticated Key Exchange (LAKE) and Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework", Work in Progress, Internet-Draft, draft-ietf-ace-edhoc-oscore- profile-12, 22 October 2026, . [JSON.Web.Token.Claims] IANA, "JSON Web Token Claims", . [OAuth.Error.Code.CBOR.Mappings] IANA, "OAuth Error Code CBOR Mappings", . [OAuth.Extensions.Error] IANA, "OAuth Extensions Error Registry", . [OAuth.Parameters] IANA, "OAuth Parameters", . Tiloca & Selander Expires 6 May 2027 [Page 71] Internet-Draft New ACE Workflow and Parameters November 2026 [OAuth.Parameters.CBOR.Mappings] IANA, "OAuth Parameters CBOR Mappings", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [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, April 2013, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, . Tiloca & Selander Expires 6 May 2027 [Page 72] Internet-Draft New ACE Workflow and Parameters November 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . [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, June 2019, . [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, March 2020, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, August 2022, . [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, August 2022, . [RFC9201] Seitz, L., "Additional OAuth Parameters for Authentication and Authorization for Constrained Environments (ACE)", RFC 9201, DOI 10.17487/RFC9201, August 2022, . Tiloca & Selander Expires 6 May 2027 [Page 73] Internet-Draft New ACE Workflow and Parameters November 2026 [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, August 2022, . [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, August 2022, . [RFC9277] Richardson, M. and C. Bormann, "On Stable Storage for Items in Concise Binary Object Representation (CBOR)", RFC 9277, DOI 10.17487/RFC9277, August 2022, . [RFC9290] Fossati, T. and C. Bormann, "Concise Problem Details for Constrained Application Protocol (CoAP) APIs", RFC 9290, DOI 10.17487/RFC9290, October 2022, . [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, July 2023, . [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, July 2023, . [RFC9528] Selander, G., Preuß Mattsson, J., and F. Palombini, "Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528, DOI 10.17487/RFC9528, March 2024, . Tiloca & Selander Expires 6 May 2027 [Page 74] Internet-Draft New ACE Workflow and Parameters November 2026 [RFC9770] Tiloca, M., Palombini, F., Echeverria, S., and G. Lewis, "Notification of Revoked Access Tokens in the Authentication and Authorization for Constrained Environments (ACE) Framework", RFC 9770, DOI 10.17487/RFC9770, June 2025, . [RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026, . [SHA-256] NIST, "Secure Hash Standard", NIST FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4 , August 2015, . 13.2. Informative References [I-D.ietf-ace-authcred-dtls-profile] Tiloca, M. and J. P. Mattsson, "Additional Formats of Authentication Credentials for the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)", Work in Progress, Internet-Draft, draft-ietf-ace-authcred-dtls- profile-04, 6 July 2026, . [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-07, 6 July 2026, . [I-D.ietf-lake-app-profiles] Tiloca, M. and R. Höglund, "Coordinating the Use of Application Profiles for the Lightweight Authenticated Key Exchange (LAKE) Protocol", Work in Progress, Internet- Draft, draft-ietf-lake-app-profiles-07, 26 October 2026, . Tiloca & Selander Expires 6 May 2027 [Page 75] Internet-Draft New ACE Workflow and Parameters November 2026 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, . [RFC9594] Palombini, F. and M. Tiloca, "Key Provisioning for Group Communication Using Authentication and Authorization for Constrained Environments (ACE)", RFC 9594, DOI 10.17487/RFC9594, September 2024, . Appendix A. Benefits for ACE Profiles For any profile of ACE, the following holds. * The SDC workflow defined in Section 2 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 Section 3.1 is used: - To inform the AS about C opting in to use the SDC workflow. - To request the AS that the follow-up access token response includes certain information, if the AS has successfully uploaded the access token to the RS. - To inform C that the AS has attempted to upload the 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 if 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 [RFC9203]. Tiloca & Selander Expires 6 May 2027 [Page 76] Internet-Draft New ACE Workflow and Parameters November 2026 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) [RFC9846] as defined in [RFC9430]. A.2. LAKE and OSCORE Profile When the LAKE 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. CDDL Model This section is to be removed before publishing as an RFC. ; OAuth Parameters CBOR Mappings token_upload = 49 token_hash = 50 to_rs = 51 from_rs = 52 rs_cnf2 = 53 audience2 = 54 anchor_cnf = 55 token_series_id_param = 56 updated_rights = 57 ; CBOR Web Token (CWT) Claims token_series_id_claim = 42 ; CWT Confirmation Methods x5chain = 24 ; Custom Problem Detail Keys Registry ace-error = 2 ; EDHOC External Authorization Data ead_session_id_label = 2 Tiloca & Selander Expires 6 May 2027 [Page 77] Internet-Draft New ACE Workflow and Parameters November 2026 Figure 13: CDDL model Appendix C. Document Updates This section is to be removed before publishing as an RFC. C.1. Version -08 to -09 * Renamed EDHOC to LAKE as appropriate. * Fixed use of "token_upload" values in access token response. * Used normative language on the AS creating a token series on the fly. * Guidance and requirements against possible group-audience mixup when using the "anchor_cnf" parameter. * Added example of AS-to-RS token upload using the "updated_rights" parameter. * SDC workflow with a group-audience: after a failed upload, the AS continues uploading the access token to any remaining RS (unless the error code "missing_old_token" is received). * Added "Operational Considerations" section. * Updated security considerations. * Editorial fixes and improvements. C.2. Version -07 to -08 * Extended creation of "token_upload" to support the creation of token series "on-the-fly" if need be. * Defined successful/failed token upload from the AS when the token targets a group-audience. * Defined EDHOC EAD item Session ID. * Clarifications: - Relation between "token_upload" and use of RFC 9770. - Values to avoid for "rs_cnf" in an access token request in some contexts. Tiloca & Selander Expires 6 May 2027 [Page 78] Internet-Draft New ACE Workflow and Parameters November 2026 * IANA considerations: - Added references to IANA registries. - Added updates to recently registered OAuth parameters. * Fully decoupled the "to_rs" parameter from the "from_rs" parameter. * Editorial fixes and improvements. C.3. Version -06 to -07 * Updated requirements for using "rs_cnf" in an access token request. * More precise requirements on including/omitting parameters in access token request and response. * Specified parameter encoding when messages are encoded in JSON. * Moved content on dynamic update of access rights to the section about the "updated_rights" parameter. * Clarifications: - Access token responses are successful by definition. - Successful response in general vs. response with 2.01 code. - Explained the case where the RS has forgotten the access token to supersede. * IANA considerations: update entry for "access_token" in the "OAuth Parameters" registry. * Editorial fixes and improvements. C.4. Version -05 to -06 * Defined dynamic update of access rights in the SDC workflow. * Defined the new "updated_rights" parameter. * Clarified practical requirements at the AS for processing the "to_rs" parameter. Tiloca & Selander Expires 6 May 2027 [Page 79] Internet-Draft New ACE Workflow and Parameters November 2026 * IANA considerations: update in the "Parameter Usage Location" column for some entries of the "OAuth Parameters" registry. * Adjusted abbreviations in the CDDL model to avoid collisions. * Removed appendix with placeholder ideas. * Editorial fixes and improvements. C.5. Version -04 to -05 * Error handling and error code for failed PoP verification at the AS. * Extended definition of the parameters "to_rs" and "from_rs". * Fixes and presentation improvements in the IANA considerations. * Updated references. * Revised order of some sections. * Editorial fixes and improvements. C.6. 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. Tiloca & Selander Expires 6 May 2027 [Page 80] Internet-Draft New ACE Workflow and Parameters November 2026 C.7. 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. C.8. 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. C.9. Version -00 to -01 * Definition of the "token series" moved to the "Terminology" section. * Clarifications and fixes on using parameters in messages. Tiloca & Selander Expires 6 May 2027 [Page 81] Internet-Draft New ACE Workflow and Parameters November 2026 * 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 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-164 40 Kista Sweden Email: marco.tiloca@ri.se Göran Selander Ericsson AB Torshamnsgatan 23 SE-164 40 Kista Sweden Email: goran.selander@ericsson.com Tiloca & Selander Expires 6 May 2027 [Page 82]