Reviewer: Qin Wu Review result: Has Issues I have reviewed this document as part of the Ops area directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Ops area directors. Document editors and WG chairs should treat these comments just like any other last-call comments. This document extends oauth to support fine granularity access control. A new Request parameter "authorization_details" is defined. Here are a few comments I would like authors to consider: 1.The title of this draft focus only on rich authorization request and seems not completely to reflect what it is about, e.g., common fields defined in section can be used not just in authorization request, but also in token exchange, e.g., token request and token response, or in access tokens in JWT format or to Token Introspection responses. Would it be great tweak the title to reflect what this draft is really about. 2.Do we have a solution overview section to describe where the oauth message extensions are exchanged? In which message? E.g., between oauth client and authorization server or between authorization server and resource server? 3.Section 3 discuss the relation with “scope” parameter and “resource” parameter, it looks authorization request parameter can be used together with “scope” and “resource”, can you provide two separate example to show how they work together, is there any side effect of using them together? 4.It is not clear to me why Comparing authorization details is needed, how such comparing operation is different CRUD operation? Why not define token update message instead of introducing comparing operation? 5.Section 10 said: “To advertise its support for this feature, the supported list of authorization details types is included in the AS metadata response ” What does this feature referred to in the above sentence? Rich authorization request? Also the metadata is used by authorization server to advertise the capability support to oauth client or resource server? It seems the client also can indicate their selected choice in the authorization request? See relevant text below: “ Clients MAY indicate the authorization details types they will use when requesting authorization with the client registration metadata parameter authorization_details_types ” Also I feel that metadata exchange should take place before authorization request/response exchange? No? Hope this comments help improve the readability of the document. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
