Telechat Review of draft-ietf-ace-revoked-token-notification-08
review-ietf-ace-revoked-token-notification-08-iotdir-telechat-widell-2024-07-04-00

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/