[Ace] Francesca Palombini's Yes on draft-ietf-ace-dtls-authorize-16: (with COMMENT)

[Francesca Palombini via Datatracker <[e-mail]>]

Francesca Palombini has entered the following ballot position for
draft-ietf-ace-dtls-authorize-16: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-dtls-authorize/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for this document. Some minor comments below.

Francesca

1. -----

   The response MAY contain a "profile" parameter with the value

   authorizes the client, it returns an AS-to-Client response.  If the
   profile parameter is present, it is set to "coap_dtls".  The

         profile    : coap_dtls,

FP: s/profile/ace_profile

2. -----

   [RFC8747].  A resource server MUST have the capacity to store one
   access token for every proof-of-possession key of every authorized
   client.

FP: I am not sure this BCP 14 MUST is correct here.

3. ------

   raw public keys, it needs to determine which key to use.  The
   authorization server can help with this decision by including a "cnf"
   parameter in the access token that is associated with this
   communication.  In this case, the resource server MUST use the

FP: The example in Figure 4 show how the whole RPK of the client can be
included in the access_token, so maybe this paragraph should cover that case,
or the example changed.

4. -----

   token carries a symmetric key, the access token MUST be encrypted
   using a "COSE_Encrypt0" structure.  The authorization server MUST use

FP: Since only CWT is allowed in this profile, it might be good to reference
section 7.1 of RFC 8392.

5. -----

   the "psk_identity" field.  If key derivation is used, the resource
   server uses the "COSE_KDF_Context" information as described above.

FP: "COSE_KDF_Context" appears here for the first time, so this might need to
be rephrased.

6. -----

   As recommended in Section 5.8 of [I-D.ietf-ace-oauth-authz], this
   specification uses CBOR web tokens to convey claims within an access
   token issued by the server.  While other formats could be used as

FP: I think this warrants for RFC 8392 to be moved to normative reference (but
can be convinced of the contrary).