Last Call Review of draft-ietf-oauth-rar-15
review-ietf-oauth-rar-15-secdir-lc-wallace-2022-11-16-00

Comments/questions
- 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?

Nits
- 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".