Roman Danyliw has entered the following ballot position for draft-ietf-ace-revoked-token-notification-08: No Objection
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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-revoked-token-notification/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Dale Worley for the GENART review. ** Section 3.4 The specifically used hash function MUST be collision-resistant on byte-strings, and MUST be selected from the "Named Information Hash Algorithm" Registry [Named.Information.Hash.Algorithm]. Is there isn’t any mandatory to implement algorithm, how is interoperability expected? ** Section 6. I’m having trouble understanding who the “full TRL” download is for. -- Section 13.1 says “The AS MUST ensure that ... only authorized and authenticated administrators can retrieve the full TRL (see Section 9).” -- Section 13.2 cautions: If many non-expired access tokens associated with a registered device are revoked, the pertaining subset of the TRL could grow to a size bigger than what the registered device is prepared to handle upon reception of a response from the TRL endpoint, especially if relying on a full query of the TRL (see Section 6). It is there an assumption that administrators are operating on constrained devices to create issues with downloading the full TRL? ** Section 13.3 In order to avoid this, a requester SHOULD NOT rely solely on the CoAP Observe notifications. In particular, a requester SHOULD also regularly poll the AS for the most current information about revoked access tokens, by sending GET requests to the TRL endpoint according to a related application policy. Are the requestors going to be constrained devices? If so, both of these approaches seem problematic for device will limited battery power – either the device needs to stay awake to watch Observe notifications or it needs to poll. ** Section 13.5 In order to minimize such a risk, if an RS relies solely on polling through individual requests to the TRL endpoint to learn of revoked access tokens, the RS SHOULD implement an adequate trade-off between the polling frequency and the maximum length of the vulnerable time window. As above. Would an RS ever be constrained because polling would impact the battery life. _______________________________________________ Ace mailing list -- ace@ietf.org To unsubscribe send an email to ace-le...@ietf.org
