Reviewer: Niklas Widell Review result: Ready with Nits IoT directorate review of Notification of Revoked Access Tokens in the Authentication and Authorization for Constrained Environments (ACE) Framework Reviewer: Niklas Widell Review result: Ready with Nits I have reviewed draft-ietf-ace-revoked-token-notification-08 from IoT point of view, as part of IoT directorate document reviews. The document is well-written, complete, and appears to be Ready (with non-blocking comments/reflections & Nits below). The document defines a mechanism for an Authorization server (AS) in the ACE framework to notify Clients and Resource Servers (RS) when access tokens are revoked. This can be useful in IoT environments as depending on token expiration is not always practical. The mechanism is designed for, but not limited to, IoT, and I did not find any directly IoT related issues in the document. ----- Comments: - General: The token revocation mechanism complements token expiration as a way to handle access. Are there any thoughts on system operator assumptions on how to balance short token expiration times vs. revocation with notification as ways to maintain the population of active access tokens? - (1.1 Administrator) The document specifies an Administrator role who's only (as far as I can tell) function is to retrieve the Token Revocation List (TRL) from the AS. Is the intent to specify other admin functions elsewhere? Furthermore, it is not clear what the value of the Administrator role is: the TRL is a list of token hashes, each of which an hash identifier derived from an actual access token. From this, I can't tell if the administrator can derive much useful information from those hashes themselves, like does client X have an access token for RS Y etc. - (4.4 TRL) The TRL of the AS is a CBRO array of CBOR byte strings, each of which a token hash. At the same time, every time a non-administrator registered device accesses the AS TRL it should only see its own hashes, which of course requires the AS to keep track of registered devices so as to filter properly. Is it up to the implementation to handle that? - General: Given that the notification is now the way to tell a registered device that one of its tokens is revoked - how is the device suppose to handle the actual revocation? ----- Nits: - 1. Introduction/first paragraph : add abbreviation (RS) to Resource Server first time it is used (3rd line), remove from later usage in same paragraph. - 2. Protocol overview/first paragraph: s/ about pertaining revoked access tokens/ about revoked access tokens/ -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
