Skip to main content

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

Request Review of draft-ietf-oauth-rar
Requested revision No specific revision (document currently at 23)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2022-11-17
Requested 2022-10-27
Authors Torsten Lodderstedt , Justin Richer , Brian Campbell
I-D last updated 2022-11-16
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 Carl Wallace
State Completed
Request Last Call review on draft-ietf-oauth-rar by Security Area Directorate Assigned
Posted at
Reviewed revision 15 (document currently at 23)
Result Has nits
Completed 2022-11-16
- Section 2.2 states "When different common data fields are used in
combination, the permissions the client requests are the cartesian product of
the values." What would that mean for the example in Figure 7 where geolocation
is asserted? Are data fields other than the common types not processed this
way? - The MUST in the first sentence of the third paragraph in Section 3.1
should probably be a SHOULD. The paragraph before recommends against using both
scope and authorization_details. The rest of the paragraph leaves open how to
handle the combination (presumably including ignoring one or the other). - It
is unclear to me how the "MUST consider both sets of requirements in
combination with each other" language in Section 3.2 squares with the "resource
parameter does not have any impact on the way the AS processes the
authorization_details" language in Section 3.3 for  a request that includes
scope, resource and authorization_details w/locations. If scope and resource
were used before, it seems odd to only consider scope during a migration
period. - In section 7, the first paragraph has a MUST regarding sending "the
authorization details as granted by the resource owner". The third paragraph
leaves room for discretion. Should the MUST be a SHOULD?

- Expand AS and RS on first use
- The security considerations should echo the requirement that the AS ensure
that there is no collision between different authorization details types that
it supports. - In section 6, the bulleted list of privileges is incomplete. The
example in Section 3 also allowed for checking the status of and canceling a
payment. - Section 11.1 should probably include a bullet regarding client use
of the authorization_details_types metadata. - In the second paragraph of
Section 12, "all strings" should probably be "all strings in an
authorization_details parameter".