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). _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
