Skip to main content

Last Call Review of draft-ietf-oauth-rar-23

Request Review of draft-ietf-oauth-rar
Requested revision No specific revision (document currently at 23)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2022-11-17
Requested 2022-10-27
Authors Torsten Lodderstedt , Justin Richer , Brian Campbell
I-D last updated 2023-05-15
Completed reviews Genart Last Call review of -15 by Robert Sparks (diff)
Secdir Last Call review of -15 by Carl Wallace (diff)
Artart Last Call review of -14 by Thomas Fossati (diff)
Opsdir Last Call review of -23 by Qin Wu
Assignment Reviewer Qin Wu
State Completed
Request Last Call review on draft-ietf-oauth-rar by Ops Directorate Assigned
Posted at
Reviewed revision 23
Result Has issues
Completed 2023-05-15
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.