Hi All, I wanted to submit a review of "Notification of Revoked Access Tokens in the Authentication and Authorization for Constrained Environments (ACE) Framework" (draft-tiloca-ace-revoked-token-notification-00).
I am an ACE noob, but hopefully my feedback will be constructive and helpful. If they are not, it could be because of my ignorance of ACE. That said, I am an expert in OAuth, so that is my frame of reference. * The draft mixes casing and has inconsistent use of acronyms like RS, resource server, authorization server, AS, etc. This hangs me up as a reader. I'd appreciate if one was used for all or if none were used. * I recommend an ASCII art be added to the protocol overview. I know that there are some good diagrams in the examples, but an overview figure in that section would be helpful as a reader as comes to terms with what the doc specifies and decide if it's relevant. It would also be helpful if this section ended with a link/reference to the example sections below (e.g., something like “see examples in section X for more detailed flows”). * In my strong opinion, It should not be assumed that the TRL endpoint is at the root of the URL path of the AS. https://example.com/tenant1/trl should be valid; also, https://example.com/my-good-trl should be a valid URI. This should be included in the OAuth metadata (if the AS supports this) or communicated to the client/RS by some undefined method (e.g., documentation). The spec may recommend some URI and the non-normative examples can use whatever URI, but these must not be MTI. * The doc should not make any distinction between an OAuth client and resource server. This makes it very confusing IMHO. Instead, it should consider the caller/client of the TRL endpoint, regardless of what role that caller plays in an OAuth flow. This is similar to how introspection and other OAuth-related APIs are defined. * The TRL endpoint need not be per client/RS. The endpoint only exposes random hashes. Disclosing these to other parties will not pose a security issue (that I can think of). This will allow clients/RSes to collaborate in unforeseen ways that could be useful in certain deployments. This also means that the TRL endpoint will be global and not have a client-specific path segment in the path of the URI. * The TRL endpoint should accept some method for filter based, for example, on client ID. This could be done using a query string argument like "client_id" which can be supplied 0..INF times. This will allow a monitoring client (like a NOC) to subscribed to revocation messages for multiple clients/RSes. If the "client_id" (or whatever) parameter is supplied, the caller of the TRL endpoint should be notified of ALL revoked tokens. * If the idea above is accepted and the AS requires authentication of the TRL endpoint client, then the AS may automatically subscribe the client to notifications for just itself (which the AS knows the identity of the client due to authentication). This implicitly filtering may be beyond the scope of the doc, however, and I think that authentication in general should be dropped. If it remains though, this identification and implicit filter can be done irrespective of authentication scheme used. * I think that the token name term should be changed to token hash, so that it is more intuitively obvious what it is in case the term was skimmed over or missed. * Because the draft is only about non-revoked tokens, the RS/client still has to manage expired token checking. If the list included expired tokens as well, the RS/client could off-load all of this to the AS. This would make the development of the RS/client a lot simpler and push that complexity to the AS. This is keeping in the spirit and aim of OAuth. I've understood from Ludwig and Marco that this does introduce some issues in a CoAP environment, that I know nothing about. So, please take it as a suggestion and see what's best. * Clarify that the hashes in the CBOR array are unordered. CBOR has no set, I've been told, only arrays. Arrays are ordered though, so it should be stated that this ordering is irrelevant, and the subscriber should treat them as a set where the order has no significant meaning. HTH! -- Travis Spencer _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
