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

3.1.1. Examples

Figure 3 shows an example of Access Token Response from the AS to C, following the issue of an access token bound to a symmetric PoP key. The Access Token Response specifies the parameter "token_uploaded" with value "true", which indicates that the AS has successfully uploaded the access token to the RS on behalf of C.¶

Consistently, the Access Token Response does not include the access token, while it still includes the parameter "cnf" specifying the symmetric PoP key bound to the access token.¶

   2.01 Created
   Content-Format: application/ace+cbor
   Max-Age: 3560
   Payload:
   {
     "token_uploaded" : true,
     "expires_in" : 3600,
     "cnf" : {
       "COSE_Key" : {
         "kty" : 1,
         "kid" : h'3d027833fc6267ce',
         "k" : h'73657373696f6e6b6579'
       }
     }
   }

Figure 4 shows another example of Access Token Response from the AS to C, also following the issue of an access token bound to a symmetric PoP key. In this example, the Access Token Response includes the parameter "token_uploaded" with value "false", which indicates that the AS has failed to upload the access token to the RS on behalf of C. The Access Token Response also includes the access token and the parameter "cnf" 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.¶

   2.01 Created
   Content-Format: application/ace+cbor
   Max-Age: 3560
   Payload:
   {
     "access_token" : h'd08343a1'/...
      (remainder of CWT omitted for brevity;
      CWT contains the symmetric PoP key in the "cnf" claim)/,
     "token_uploaded" : false,
     "expires_in" : 3600,
     "cnf" : {
       "COSE_Key" : {
         "kty" : 1,
         "kid" : h'3d027833fc6267ce',
         "k" : h'73657373696f6e6b6579'
       }
     }
   }

3.2.1. Example

Figure 5 shows an example of Access Token Response from the AS to C, following the issue of an access token bound to C's public key as asymmetric PoP key. The Access Token Response includes the access token, as well as the parameters "rs_cnf2" and "subject_ids". These specify the public key of two RSs as intended recipients of the access token and the URIs identifying those two RSs, respectively.¶

   2.01 Created
   Content-Format: application/ace+cbor
   Max-Age: 3600
   Payload:
   {
     "access_token" : b64'SlAV32hk'/...
      (remainder of CWT omitted for brevity;
      CWT contains the client's RPK in the "cnf" claim)/,
     "expires_in" : 3600,
     "rs_cnf2" : [
       {
         "COSE_Key" : {
           "kty" : 2,
           "crv" : 1,
           "x" : h'bbc34960526ea4d32e940cad2a234148
                   ddc21791a12afbcbac93622046dd44f0',
           "y" : h'4519e257236b2a0ce2023f0931f1f386
                   ca7afda64fcde0108c224c51eabf6072'
         }
       },
       {
         "COSE_Key" : {
           "kty" : 2,
           "crv" : 1,
           "x" : h'ac75e9ece3e50bfc8ed6039988952240
                   5c47bf16df96660a41298cb4307f7eb6',
           "y" : h'6e5de611388a4b8a8211334ac7d37ecb
                   52a387d257e6db3c2a93df21ff3affc8'
         }
       }
     ],
     "subject_ids" : [
       "coaps://rs1.example.com",
       "coaps://rs2.example.com"
     ]
   }

B.1.1. Allow the Dynamic Update of Access Rights

In some profiles of ACE, C can request a new access token to update its access rights, while preserving the same secure association with the RS. The new access token supersedes the current one stored at the RS, as they are both part of the same "token series".¶

A token series comprises all the access tokens issued by the same AS for the same pair (Client, Resource Server). Specific profiles can provide a more specialized definition, e.g., by further taking into account the public authentication credentials of C and the RS.¶

When using the original ACE workflow, C uploads the new access token to the RS by protecting the message exchange through the secure association with the RS. This allows the RS to determine that the upload of such access token is for updating the access rights of C.¶

When using the new ACE workflow, the AS uploads the new access token to the RS also when an update of access rights for C is to be performed. This message exchange would be protected through the secure association between the AS and RS. However, this secure association does not help the RS retrieve the stored access token to supersede, as that is rather bound to the secure association with C.¶

In order for the new ACE workflow to also allow the dynamic update of access rights, it is required that the new access token updating the access rights of C includes an explicit indication for the RS. Such an indication can point the RS to the token series in question (hence to the current access token to supersede), irrespective of the secure association used to protect the token uploading.¶

In some profiles of ACE, such an indication is in fact already present in issued access tokens:¶

• In the PSK mode of the DTLS profile [RFC9202], the token series is indicated by the parameter "kid" within the claim "cnf" of the new access token. This has the same value of the parameter "kid" in the COSE_Key within the claim "cnf" from the first access token of the token series.¶
• In the OSCORE profile [RFC9203], the token series is indicated by the parameter "kid" within the claim "cnf" of the new access token. This has the same value of the parameter "id" in the OSCORE_Input_Material object within the claim "cnf" from the first access token of the token series.¶

• In the EDHOC and OSCORE profile [I-D.ietf-ace-edhoc-oscore-profile], the token series is indicated by the parameter "kid" within the claim "cnf" of the new access token. This has the same value of the parameter "id" in the EDHOC_Information object within the claim "cnf" from the first access token of the token series.¶

  Note: version -01 of the EDHOC and OSCORE profile says that an update of access rights is not possible when using the new workflow. However, it is actually possible as discussed above.¶

In the three cases above, the update of access rights is possible because there is a value used as de facto "token series ID". This value does not change throughout the lifetime of a token series, and it is used to associate the new access token with the previous one in the same series to be superseded.¶

Such a token series ID is required to have a unique value from a namespace/pool that the AS exclusively control. This is in fact what happens in the profiles of ACE above, where the AS is the entity creating the mentioned objects or COSE Key included in the first access token of a token series.¶

However, this may generally not hold and it is not what happens in other known cases, i.e., the DTLS profile in RPK mode [RFC9203] and the Group OSCORE profile [I-D.tiloca-ace-group-oscore-profile]. At the moment, the dynamic update of access rights is not possible for those, neither in the original nor in the new ACE workflow.¶

In order to make the update of access rights possible also for such cases, as well as both in the original and in the new ACE workflow, those cases can rely on a new parameter and claim "token_series_id" (see Appendix B.2.2), which specifies a unique identifier of the token series which an access token belongs to.¶

As to existing profiles of ACE, the above has no intention to change the current behavior when the update of access rights occurs, irrespective of the used ACE workflow and especially when using the original workflow.¶

If future profiles rely on a construction where the AS creates the object or key included in the claim "cnf" of the first access token in a token series, and a unique ID generated by the AS is included in such object or key, then that ID must be used as de facto "token series ID", rather than the new parameter "token_series_id".¶

B.1.2. Allow the Re-uploading of the Access Token

After the AS has successfully uploaded the access token to the RS when using the new ACE workflow, C does not obtain the access token altogether. It follows that C cannot re-upload the Access Token to the RS by itself, e.g., in order to perform a key update like defined for the OSCORE profile [RFC9203].¶

Even in such a case, the token re-uploading can be allowed by relying on a new parameter "token_hash", which the AS provides to C and specifies the hash of the access token (see Appendix B.2.2).¶

Then, C can practically "re-upload" the access token to the RS, by sending a request to the authz-info endpoint that includes the parameter "token_hash" instead of the parameter "access_token". Such a request may include further parameters, depending on what is defined for the used transport profile.¶

If the RS still stores the access token in question, then the RS can identify it by means of the received token hash, and take the same actions that would have been taken in case the full access token was re-uploaded to the authz-info endpoint.¶

B.1.3. Ensure Applicability to Any ACE Profile

Some profiles of ACE require that C and the RS generate information to be exchanged when uploading the access token. For example:¶

• In the OSCORE profile [RFC9203], C and RS are required to exchange the nonces N1 and N2, when uploading to the RS the first access token of a token series, as well as when re-uploading any access token (e.g., in order to perform a key update).¶
• In the EDHOC and OSCORE profile [I-D.ietf-ace-edhoc-oscore-profile], C and the RS are required to exchange the nonces N1 and N2, when re-uploading any access token in order to perform a key update through the function EDHOC_KeyUpdate (see Appendix I of [I-D.ietf-lake-edhoc]).¶

Evidently, using the new ACE workflow prevents C and the RS from directly performing the required exchanges above, since the uploading of the access token does not rely on a direct interaction between C and RS like in the original ACE workflow. For some profiles of ACE, this may prevent the use of the new ACE workflow altogether.¶

This issue can be solved by having the AS acting as intermediary also for the exchange of C- and RS-generated information, by relying on two new parameters "to_rs" and "from_rs" (see Appendix B.2.2). In particular, C can use "to_rs" for providing the AS with C-generated information, to be relayed to the RS when uploading the access token. Also, the RS can use "from_rs" for providing the AS with RS-generated information when replying to the token uploading, and to be relayed to C.¶

With reference to the two cases mentioned above, "to_rs" can specify the nonce N1 generated by C, while "from_rs" can specify the nonce N2 generated by RS.¶

B.2.1. token_uploaded

The parameter "token_uploaded" defined in Section 3.1 builds on the assumption that C can operate in the presence of the alternative ACE workflow defined in Section 2.¶

In particular, it assumes that C accepts as valid an Access Token Response that includes the parameter "token_uploaded" encoding the CBOR simple value "true" but not the access token, and that, in such a case, C continues by sending a protected request to the RS.¶

In turn, this assumes that the AS knows that C can operate in the presence of the alternative ACE workflow. This can be part of the information that C provided to the AS at its registration.¶

An alternative design choice would instead require C to opt-in when sending the Access Token Request to the AS. That is, C can include the parameter "token_uploaded" in the Access Token Request, encoding the CBOR simple value "true", hence explicitly signaling its understanding of the alternative workflow.¶

Only if the AS supports the alternative workflow and the Access Token Request includes the parameter "token_uploaded" encoding the CBOR simple value "true", can the AS attempt to upload the access token to the RS on behalf of C as per the alternative workflow.¶

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

• "token_series_id" - This parameter specifies the unique identifier of a token series, thus ensuring that C can dynamically update its access rights, irrespective of the used ACE workflow (see Appendix B.1.1).¶

  When issuing the first access token of a token series, the AS specifies this parameter in the Access Token Response to C, with value TS_ID. Also, the AS includes a claim "token_series_id" with the same value in the access token.¶

  When C requests a new access token in the same tokes series for dynamically updating its access rights, C specifies the value TS_ID as "kid" within the parameter "req_cnf" of the Access Token Request (see Section 3.1 of [RFC9201]). The AS specifies the same value as "kid" within the claim "cnf" of the new access token.¶

• "token_hash" - This parameter specifies the hash of an access token that the AS has successfully issued and uploaded to the RS as per the new ACE workflow, and thus that the AS does not provide to C (see Appendix B.1.1).¶

  The AS specifies this parameter in a successful Access Token Response, in case the parameter "token_uploaded" is also specified as encoding the CBOR simple value "true" (see Section 3.1). The parameter value is the hash computed over the value that the parameter "access_token" would have had in that same response message, if it was included therein specifying the access token.¶

  C specifies this parameter in the request sent to the authz-info endpoint at the RS for "re-uploading" the same access token, e.g., in order to perform a key update (see Appendix B.1.2).¶

  This parameter also allows C to seamlessly use the method defined in [I-D.ietf-ace-revoked-token-notification] for learning of revoked access tokens, even when the new ACE workflow is used and C does not obtain the access token, which makes it impossible for C to compute the token hash by itself.¶

• "to_rs" - When using the new ACE workflow, this parameter specifies C-generated information that, according to the used profile of ACE, C has to provide to the RS together with the access token if using the original ACE workflow. This allows the AS to relay such information to the RS upon uploading the access token on behalf of C (see Appendix B.1.3).¶

  First, C specifies this parameter in the Access Token Request sent to the AS. Then, the AS specifies this parameter in the request to the RS sent for uploading the access token on behalf of C, by simply relaying the value received from C. The used profile of ACE has to define the detailed content and semantics of the information specified in the parameter value.¶

• "from_rs" - When using the new ACE workflow, this parameter specifies RS-generated information that, according to the used profile of ACE, the RS has to provide to C after the uploading of an access token if using the original ACE workflow. This allows the AS to relay such information to C after having uploaded the access token on behalf of C (see Appendix B.1.3).¶

  First, the RS specifies this parameter in the response sent to the AS, after the upload of an access token through a request from the AS. Then, the AS specifies this parameter in the Access Token Response to C, by simply relaying the value received from the RS. The used profile of ACE has to define the detailed content and semantics of the information specified in the parameter value.¶