Short Distribution Chain (SDC) Workflow and New OAuth Parameters for the Authentication and Authorization for Constrained Environments (ACE) Framework

1.1. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Readers are expected to be familiar with the terms and concepts described in the ACE framework for Authentication and Authorization [RFC9200][RFC9201], as well as with terms and concepts related to CBOR Web Tokens (CWTs) [RFC8392] and CWT Confirmation Methods [RFC8747].¶

The terminology for entities in the considered architecture is defined in OAuth 2.0 [RFC6749]. In particular, this includes client (C), resource server (RS), and authorization server (AS).¶

Readers are also expected to be familiar with the terms and concepts related to CoAP [RFC7252], Concise Data Definition Language (CDDL) [RFC8610], CBOR [RFC8949], JavaScript Object Notation (JSON) [RFC8259], and COSE [RFC9052][RFC9053].¶

Note that the term "endpoint" is used here following its OAuth definition [RFC6749], aimed at denoting resources such as /token and /introspect at the AS, and /authz-info at the RS. 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 to other access token identifiers possibly used, such as the 'cti' (CWT ID) claim of CBOR Web Tokens (CWTs) [RFC8392].¶

CBOR [RFC8949] and CDDL [RFC8610] are used in this document. CDDL predefined type names, especially bstr for CBOR byte strings and tstr for CBOR text strings, are used extensively in this document.¶

Examples throughout this document are expressed in CBOR diagnostic notation as defined in Section 8 of [RFC8949] and Appendix G of [RFC8610]. Diagnostic notation comments are often used to provide a textual representation of the parameters' keys and values.¶

In the CBOR diagnostic notation used in this document, constructs of the form e'SOME_NAME' are replaced by the value assigned to SOME_NAME in the CDDL model shown in Figure 11 of Appendix C. For example, {e'audience2' : ["rs1", "rs2"]} stands for {53 : ["rs1", "rs2"]}.¶

Note to RFC Editor: Please delete the paragraph immediately preceding this note. Also, in the CBOR diagnostic notation used in this document, please replace the constructs of the form e'SOME_NAME' with the value assigned to SOME_NAME in the CDDL model shown in Figure 11 of Appendix C. Finally, please delete this note.¶

3.1. token_upload

This section defines the additional "token_upload" parameter. The parameter can be used in an access token request sent by C to the token endpoint at the AS, as well as in the successful access token response sent as reply by the AS.¶

• The "token_upload" parameter is OPTIONAL in an access token request. The presence of this parameter indicates that C opts in to use the 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 successful access token response will have to include certain information, in case the AS has successfully uploaded the access token to the RS.¶

  • 0: The access token response will have to include neither the access token nor its corresponding token hash.¶

  • 1: The access token response will have to include the token hash corresponding to the access token, but not the access token.¶

  • 2: The access token response will have to include the access token, but not the corresponding token hash.¶

  If the AS supports the SDC workflow and the access token request includes the "token_upload" parameter with value 0, 1, or 2, then the AS MAY use the SDC workflow to upload the access token to the RS on behalf of C. Otherwise, following that access token request, the AS MUST NOT use the SDC workflow.¶

• The "token_upload" parameter is REQUIRED in a successful access token response with response code 2.01 (Created), if both the following conditions apply. Otherwise, the "token_upload" parameter MUST NOT be present.¶

  • The corresponding access token request included the "token_upload" parameter, with value 0, 1, or 2.¶

  • The AS has attempted to upload the issued access token to the RS as per the SDC workflow, irrespective of the result of the token upload.¶

  When the "token_upload" parameter is present in the access token response, it can take one of the following integer values. When the access token response is encoded in CBOR, those values are encoded as CBOR unsigned integers.¶

  • If the token upload to the RS was not successful, then the "token_upload" parameter MUST specify the value 1.¶

    In this case, the access token response MUST include the "access_token" parameter specifying the issued access token.¶

  • If the token upload at the RS was successful, then the "token_upload" parameter MUST specify the value 0.¶

    In this case, the access token response can include additional parameters as defined below, depending on the value of the "token_upload" parameter in the corresponding access token request.¶

    • If the "token_upload" parameter in the access token request specified the value 0, then the access token response MUST NOT include the "access_token" parameter and MUST NOT include the "token_hash" parameter defined in Section 3.2.¶

    • If the "token_upload" parameter in the access token request specified the value 1, then the access token response MUST NOT include the "access_token" parameter and MUST include the "token_hash" parameter defined in Section 3.2, specifying the hash corresponding to the issued access token and computed as defined in Section 3.2.¶

    • If the "token_upload" parameter in the access token request specified the value 2, then the access token response MUST include the "access_token" parameter specifying the issued access token and MUST NOT include the "token_hash" parameter defined in Section 3.2.¶

   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'
       }
     }
   }

   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'
       }
     }
   }

   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'
       }
     }
   }

3.2. token_hash

This section defines the additional "token_hash" parameter. The parameter can be used in a successful access token response sent as reply by the AS to C.¶

The following refers to the base64url encoding without padding (see Section 5 of [RFC4648]) and denotes as "binary representation" of a text string the corresponding UTF-8 encoding [RFC3629], which is the implied charset used in JSON (see Section 8.1 of [RFC8259]).¶

The "token_hash" parameter is REQUIRED in a successful access token response with response code 2.01 (Created), if both the following conditions apply. Otherwise, the "token_hash" parameter MUST NOT be present.¶

• The corresponding access token request included the "token_upload" parameter with value 1.¶

• The access token response includes the "token_upload" parameter with value 0. That is, the AS has successfully uploaded the issued access token to the RS, as per the 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.¶

   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'
       }
     }
   }

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. The "from_rs" parameter can be used in an access token response sent by the AS, in reply to a request to the token endpoint from C.¶

The 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 of ACE [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 of ACE is used, thereby effectively enabling the use of the SDC workflow for that profile.¶

   Access token request

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


   Access token response

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

3.4. rs_cnf2 and audience2

This section defines the additional parameters "rs_cnf2" and "audience2" for an access token response, sent by the AS in reply to a request to the token endpoint from C.¶

• The "rs_cnf2" parameter is OPTIONAL if the token type is "pop", asymmetric keys are used, and the access token is issued for an audience that includes multiple RSs (i.e., a group-audience, see Section 6.9 of [RFC9200]). Otherwise, the "rs_cnf2" parameter MUST NOT be present.¶

  This parameter specifies information about the public keys used by the RSs of a group-audience for authenticating themselves to C. It is used in case the binding between the public keys and the corresponding RS identities are not established through other means. If this parameter is absent, either the RSs in the group-audience do not use a public key, or the AS knows that the RSs can authenticate themselves to C without additional information.¶

  If present, this parameter MUST encode a non-empty CBOR array of N elements, where N is the number of RSs in the group-audience for which the access token is issued. Each element of the CBOR array specifies the public key of one RS in the group-audience, and MUST follow the syntax and semantics of the "cnf" claim either from Section 3.1 of [RFC8747] for CBOR-based interactions, or from Section 3.1 of [RFC7800] for JSON-based interactions. It is not required that all the elements of the CBOR array rely on the same confirmation method.¶

  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 and specifies the identifiers of the RSs in the group-audience for which the access token is issued.¶

  If present, this parameter MUST encode a non-empty CBOR array of N elements, where N is the number of RSs in the group-audience for which the access token is issued. Each element of the CBOR array in the "audience2" parameter MUST be a CBOR text string, with value the identifier of one RS in the group-audience.¶

  The element of the CBOR array referring to an RS in the group-audience SHOULD have the same value that would be used to identify that RS through the "audience" parameter of an access token request to the AS (see Section 5.8.1 of [RFC9200]) and of an access token response from the AS (see Section 5.8.2 of [RFC9200]), when requesting and issuing an access token for that individual RS.¶

  The "audience2" parameter is REQUIRED if the "rs_cnf2" parameter is present. In such a case, the i-th element of the CBOR array in the "audience2" parameter MUST be the identifier of the RS whose public key is specified as the i-th element of the CBOR array in the "rs_cnf2" parameter.¶

   Access token response

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

3.5. anchor_cnf

This section defines the additional "anchor_cnf" parameter for an access token response, sent by the AS in reply to a request to the token endpoint from C.¶

The "anchor_cnf" parameter is OPTIONAL if the token type is "pop" and asymmetric keys are used. Otherwise, the "anchor_cnf" parameter MUST NOT be present.¶

This parameter specifies information about the public keys of trust anchors, which C can use to validate the public key of the RS/RSs included in the audience for which the access token is issued. This parameter can be used when the access token is issued for an audience including one RS or multiple RSs.¶

If this parameter is absent, either the RS/RSs in the audience do not use a public key, or the AS knows that C can validate the public key of such RS/RSs without additional information (e.g., C has already obtained the required public keys of the involved trust anchors from the AS or through other means).¶

If present, this parameter MUST encode a non-empty CBOR array that MUST be treated as a set, i.e., the order of its elements has no meaning. Each element of the CBOR array specifies the public key of one trust anchor, which can be used to validate the public key of at least one RS included in the audience for which the access token is issued. Each element of the CBOR array MUST follow the syntax and semantics of the "cnf" claim either from Section 3.1 of [RFC8747] for CBOR-based interactions, or from Section 3.1 of [RFC7800] for JSON-based interactions. It is not required that all the elements of the CBOR array rely on the same confirmation method.¶

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 this document. That is, C may be able to obtain the public keys of the RS/RSs for which the access token is issued through other means.¶

When the access token response includes both the "anchor_cnf" parameter and the "audience2" parameter defined in Section 3.4, then C MUST make sure that a public key PK_RS is associated with an RS identified by an element of "audience2", before using any of the public keys specified in "anchor_cnf" to validate PK_RS.¶

When the access token response includes the "anchor_cnf" parameter but not the "audience2" parameter, then C can use any of the public keys specified in "anchor_cnf" to validate the public key PK_RS of any RS in the targeted audience. This allows C to use the access token with an RS that is deployed later on as part of the same audience, which is particularly useful in the case of a group-audience.¶

   Access token response

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

3.6. token_series_id

This section defines the additional "token_series_id" parameter. The parameter can be used in an access token request sent by C to the token endpoint at the AS as well as in the successful access token response sent as reply by the AS.¶

• The "token_series_id" parameter is OPTIONAL in an access token request. The presence of this parameter indicates that C wishes to obtain a new access token for dynamically updating its access rights. That is, the new access token is intended to be the next one in an active token series and to supersede the latest access token in that token series. This parameter MUST NOT be present if the requested access token is the first one of a new token series.¶

  If present, this parameter specifies the identifier of the token series that the new access token is intended to extend. The identifier does not change throughout the lifetime of the token series and was provided to C in the successful access token response that the AS sent when issuing the first access token in that token series. When the access token request is encoded in CBOR, the value of this parameter is encoded as a CBOR byte string.¶

• The "token_series_id" parameter is OPTIONAL in an access token response. This parameter MUST NOT be present if the issued access token is not the first one of the token series it belongs to.¶

  If present, this parameter specifies the identifier of the token series to which the issued access token belongs. When the access token response is encoded in CBOR, the value of this parameter is encoded as a CBOR byte string.¶

If the AS relies on the "token_series_id" parameter to exchange the identifier of token series with clients, then the following applies.¶

• The value assigned to the identifier of a token series MUST be associated with all the access tokens issued by the AS for that token series and MUST be selected from a pool that the AS exclusively controls.¶

  In particular, the triple (TS_ID, C, AUD) MUST uniquely identify a token series and its corresponding access tokens, where TS_ID is the identifier of the token series, while C and AUD are the client and the audience for which the access token is issued, respectively. The AS MUST take into account both ongoing and ended token series for selecting a new TS_ID that complies with the above requirements.¶

  Note that the ACE profile is not part of the triple, hence the requirement spans across all the ACE profiles that the AS and its registered clients/RSs support.¶

• An issued access token that belongs to a token series MUST include the identifier of that token series. This allows the RS to identify the latest access token in the token series to be superseded by the issued access token.¶

  In particular, each of such access tokens MUST include a claim specifying the identifier of the token series to which the access token belongs. When CWTs are used as access tokens, this information MUST be transported in the "token_series_id" claim registered in Section 10.4.¶

If a profile of ACE relies on a construct that uses different parameters/claims to transport the identifier of a token series, then the new "token_series_id" parameter and "token_series_id" claim MUST NOT be used when using that profile.¶

For example, a number of parameters/claims are already used to transport information that acts de facto as identifier of token series, in the PSK mode of the DTLS profile [RFC9202], in the OSCORE profile [RFC9203], and in the EDHOC and OSCORE profile [I-D.ietf-ace-edhoc-oscore-profile].¶

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 10.5 and Section 10.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).¶

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 [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 successful access token response should specify the authentication credential(s) of the RS(s) belonging to the targeted audience.¶

Per its extended semantics, the "rs_cnf" parameter is also OPTIONAL to include in an access token request for requesting the first access token in a token series, if the token type is "pop" and asymmetric keys are used. Otherwise, the parameter MUST NOT be included in an access token request.¶

When C includes the "rs_cnf" parameter in an access token request, the parameter MUST have one of the following encodings.¶

• If the parameter specifies the CBOR simple value true (0xf5), then it instructs the AS to include in the successful access token response the "rs_cnf" or "rs_cnf2" parameter, specifying the authentication credential(s) of the RS(s) by value.¶

  In the successful access token response, each pertaining authentication credential MUST be specified by value.¶

• If the parameter specifies the CBOR simple value false (0xf4), then it instructs the AS to include in the successful access token response the "rs_cnf" or "rs_cnf2" parameter, specifying the authentication credential(s) of the RS(s) by reference.¶

  In the successful access token response, each pertaining authentication credential MUST be specified by reference, or alternatively by value only in case that was not possible.¶

• If the parameter specifies the CBOR simple value null (0xf6), then it instructs the AS to omit the "rs_cnf" and "rs_cnf2" parameters from the successful access token response.¶

  In the successful access token response, the "rs_cnf" and "rs_cnf2" parameters MUST NOT be included.¶

If the AS is not able to comply in the first two cases above, then the AS MUST reject the request and 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, C MUST rely on the authentication credential(s) specified by the parameter "rs_cnf" or "rs_cnf2" in the access token response, as those that are used by the RS(s) to authenticate.¶

If C does not currently store the authentication credential(s) of the RS(s), then C MUST NOT include the "rs_cnf" parameter specifying the CBOR simple value null (0xf6) in an access token request.¶

10.1. OAuth Parameters Registry

IANA is asked to add the following entries to the "OAuth Parameters" registry within the "OAuth Parameters" registry group.¶

• Name: token_upload¶

• Parameter Usage Location: token request and token response¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

• Name: token_hash¶

• Parameter Usage Location: token response¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

• Name: to_rs¶

• Parameter Usage Location: token request¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

• Name: from_rs¶

• Parameter Usage Location: token response¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

• Name: rs_cnf2¶

• Parameter Usage Location: token response¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

• Name: audience2¶

• Parameter Usage Location: token response¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

• Name: anchor_cnf¶

• Parameter Usage Location: token response¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

• Name: token_series_id¶

• Parameter Usage Location: token request and token response¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

In the same registry, IANA is asked to update the entry for "rs_cnf" to be as follows:¶

• The "Parameter Usage Location" column specifies "token request, token response".¶

• The "Reference" column specifies "[RFC9201, Section 5][RFC-XXXX, Section 5.2]".¶

10.2. OAuth Parameters CBOR Mappings Registry

IANA is asked to add the following entries to the "OAuth Parameters CBOR Mappings" registry 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¶

• CBOR Key: TBD (value between 1 and 255)¶

• Value Type: Null or byte string or #6.<uint>(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.<uint>(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¶

• 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]¶

In the same registry, IANA is asked to update the entry for "rs_cnf" to be as follows:¶

• The "Value Type" column specifies "True or False or Null or map".¶

• The "Reference" column specifies "[RFC9201, Section 3.2][RFC-XXXX, Section 5.2]".¶

10.3. JSON Web Token Claims Registry

IANA is asked to add the following entry to the "JSON Web Token Claims" registry within the "JSON Web Token (JWT)" registry group, following the procedure specified in [RFC7519].¶

• Claim Name: token_series_id¶

• Claim Description: The identifier of a token series¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

10.4. CBOR Web Token (CWT) Claims Registry

IANA is asked to add the following entry to the "CBOR Web Token (CWT) Claims" registry 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: Section 3.6 of [RFC-XXXX]¶

10.5. OAuth Extensions Error Registry

IANA is asked to add the following entries to the "OAuth Extensions Error Registry" within the "OAuth Parameters" registry group.¶

• Name: unknown_credential_referenced¶

• Usage Location: token error response¶

• Protocol Extension: [RFC-XXXX]¶

• Change Controller: IETF¶

• Reference: Section 5 of [RFC-XXXX]¶

• Name: failed_pop_verification¶

• Usage Location: token error response¶

• Protocol Extension: [RFC-XXXX]¶

• Change Controller: IETF¶

• Reference: Section 6 of [RFC-XXXX]¶

10.6. OAuth Error Code CBOR Mappings Registry

IANA is asked to add the following entries to the "OAuth Error Code CBOR Mappings" registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.¶

• Name: unknown_credential_referenced¶

• CBOR Value: TBD (value between 1 and 255)¶

• Reference: [RFC-XXXX]¶

• Original Specification: [RFC-XXXX]¶

• Name: failed_pop_verification¶

• CBOR Value: TBD (value between 1 and 255)¶

• Reference: [RFC-XXXX]¶

• Original Specification: [RFC-XXXX]¶

10.7. Custom Problem Detail Keys Registry

IANA is asked to register the following entry in the "Custom Problem Detail Keys" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group.¶

• Key Value: TBD (value between 0 and 23)¶

• Name: ace-error¶

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

• Change Controller: IETF¶

• Reference: Section 7 of [RFC-XXXX]¶

11.1. Normative References

[ACE.OAuth.Error.Code.CBOR.Mappings]

IANA, "OAuth Error Code CBOR Mappings", <https://www.iana.org/assignments/ace/ace.xhtml#oauth-error-code-cbor-mappings>.

[I-D.ietf-ace-edhoc-oscore-profile]

Selander, G., Mattsson, J. P., Tiloca, M., and R. Höglund, "Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE)", Work in Progress, Internet-Draft, draft-ietf-ace-edhoc-oscore-profile-08, 7 July 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-ace-edhoc-oscore-profile-08>.

[IANA.Hash.Algorithms]

IANA, "Named Information Hash Algorithm Registry", <https://www.iana.org/assignments/named-information/named-information.xhtml>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC3629]

Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/rfc/rfc3629>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.

[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, <https://www.rfc-editor.org/rfc/rfc5280>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

[RFC6920]

Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, <https://www.rfc-editor.org/rfc/rfc6920>.

[RFC7252]

Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/rfc/rfc7252>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[RFC7800]

Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, <https://www.rfc-editor.org/rfc/rfc7800>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

[RFC8392]

Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.

[RFC8446]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/rfc/rfc8446>.

[RFC8610]

Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

[RFC8747]

Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Tschofenig, "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 2020, <https://www.rfc-editor.org/rfc/rfc8747>.

[RFC8949]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/rfc/rfc8949>.

[RFC9052]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://www.rfc-editor.org/rfc/rfc9052>.

[RFC9053]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, August 2022, <https://www.rfc-editor.org/rfc/rfc9053>.

[RFC9200]

Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022, <https://www.rfc-editor.org/rfc/rfc9200>.

[RFC9201]

Seitz, L., "Additional OAuth Parameters for Authentication and Authorization for Constrained Environments (ACE)", RFC 9201, DOI 10.17487/RFC9201, August 2022, <https://www.rfc-editor.org/rfc/rfc9201>.

[RFC9202]

Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and L. Seitz, "Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)", RFC 9202, DOI 10.17487/RFC9202, August 2022, <https://www.rfc-editor.org/rfc/rfc9202>.

[RFC9203]

Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, "The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework", RFC 9203, DOI 10.17487/RFC9203, August 2022, <https://www.rfc-editor.org/rfc/rfc9203>.

[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, <https://www.rfc-editor.org/rfc/rfc9277>.

[RFC9290]

Fossati, T. and C. Bormann, "Concise Problem Details for Constrained Application Protocol (CoAP) APIs", RFC 9290, DOI 10.17487/RFC9290, October 2022, <https://www.rfc-editor.org/rfc/rfc9290>.

[RFC9430]

Bergmann, O., Preuß Mattsson, J., and G. Selander, "Extension of the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) to Transport Layer Security (TLS)", RFC 9430, DOI 10.17487/RFC9430, July 2023, <https://www.rfc-editor.org/rfc/rfc9430>.

[RFC9431]

Sengul, C. and A. Kirby, "Message Queuing Telemetry Transport (MQTT) and Transport Layer Security (TLS) Profile of Authentication and Authorization for Constrained Environments (ACE) Framework", RFC 9431, DOI 10.17487/RFC9431, July 2023, <https://www.rfc-editor.org/rfc/rfc9431>.

[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, <https://www.rfc-editor.org/rfc/rfc9770>.

[SHA-256]

NIST, "Secure Hash Standard", NIST FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4 , August 2015, <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf>.

11.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-01, 3 March 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-ace-authcred-dtls-profile-01>.

[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-04, 3 March 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-ace-group-oscore-profile-04>.

[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, <https://www.rfc-editor.org/rfc/rfc9594>.

A.1. DTLS Profile

When the RPK mode of the DTLS profile is used (see Section 3.2 of [RFC9202]), it becomes possible for the AS to effectively issue an access token intended to an audience that includes multiple RSs.¶

This is enabled by the parameters "rs_cnf2" and "audience2" defined in Section 3.4 as well as by the "anchor_cnf" parameter defined in Section 3.5. This seamlessly applies also if the profile uses Transport Layer Security (TLS) [RFC8446] as defined in [RFC9430].¶

A.2. EDHOC and OSCORE Profile

When the EDHOC and OSCORE profile is used [I-D.ietf-ace-edhoc-oscore-profile], it becomes possible for the AS to effectively issue an access token intended to an audience that includes multiple RSs.¶

This is enabled by the parameters "rs_cnf2" and "audience2" defined in Section 3.4 as well as by the "anchor_cnf" parameter defined in Section 3.5.¶

B.1. SDC Workflow

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

B.2. Further New Parameters to Consider

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

• "updated_rights" - When using the SDC workflow and issuing an access token for dynamically updating the access rights of C, the AS specifies this parameter in the request sent to the RS for uploading the access token on behalf of C (see Appendix B.1.1). This parameter encodes the CBOR simple value true (0xf5).¶

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

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

D.3. Version -02 to -03

• Defined parameter and claim "token_series_id".¶

• Defined parameters "to_rs" and "from_rs".¶

• Defined use of "to_rs" and "from_rs" in the OSCORE profile.¶

• Lowercase use of "client", "resource server", and "authorization server".¶

• Fixed naming of parameters/claims for audience.¶

• Split elision and comments in the examples in CBOR Diagnostic Notation.¶

• SHA-256 is mandatory to implement for computing token hashes.¶

• Fixes in the IANA considerations.¶

• Removed (parts of) appendices that are not needed anymore.¶

• Clarifications and editorial improvements.¶

D.4. Version -01 to -02

• CBOR diagnostic notation uses placeholders from a CDDL model.¶

• Note on the new workflow supporting also non-ACE clients.¶

• Revised semantics of the "token_upload" parameter.¶

• Defined the new "token_hash" parameter.¶

• First definition of bidirectional access control through a single access token.¶

• Revised and extended considerations and next steps in appendices.¶

• Clarifications and editorial improvements.¶

D.5. Version -00 to -01

• Definition of the "token series" moved to the "Terminology" section.¶

• Clarifications and fixes on using parameters in messages.¶

• Amended two of the requirements on profiles of the framework.¶

• The client has to opt-in for using the new workflow.¶

• Parameter "token_uploaded" renamed to "token_upload".¶

• Updated format of error response payload to use RFC 9290.¶

• Security considerations inherited from other documents.¶

• Editorial fixes and improvements.¶