[OAUTH-WG] Opsdir last call review of draft-ietf-oauth-rar-23

[Qin Wu via Datatracker <[e-mail]>]

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.