Hi!
I performed an AD review of draft-ietf-oauth-rar-12. Thanks for this document.
My feedback is as follows:
** Section 2. Editorial
This field MUST be compared using an exact byte match of the string
value against known types by the AS.
Consider if you want to introduce how the lack of match will be handled here -
it is covered later.
** Section 2.2.
All data fields are OPTIONAL for use by a given API
definition.
I don't follow how this is true in the general case. I was under the
impression that this section defined what is expected to be common fields.
Couldn't some AS with a particular type require their presence?
** Section 3. Editorial
OLD
In case of authorization requests as defined in [RFC6749],
implementors MAY consider to use
NEW
In case of authorization requests as defined in [RFC6749],
implementors MAY consider using ...
** Section 3. Typo. s/intiate/initiate/
** Section 5. Typo.
OLD
authorization details type
or authorization details
NEW
authorization_details type
or authorization_details
** Section 6.1
However, when comparing a new request to an existing request,
authorization servers can use the same processing techniques as used
in granting the request in the first place to determine if a resource
owner needs to authorize the request.
Why is it possible to assess two arbitrary requests in this case to determine
"if a resource owner needs to authorize the request", but the prior paragraph
explicitly calls out that comparing two arbitrary requests is not feasible? To
me is seems like comparing two requests to understand if more or less
permissions are being requested is equivalent to determining if a new request
exceed the current request to determine if going back to the resource owner is
needed.
** Section 6.1. Typo. s/isaunce/issuance/
** Section 7.
If the client does not specify
the authorization_details token request parameters, the AS determines
the resulting authorization details at its discretion. The
authorization server MAY consider the values of other parameters such
as resource and scope if they are present during this processing, and
the details of such considerations are outside the scope of this
specification.
This guidance seems to indicate the use of the scope parameter is optional in
determining the authorization details. Section 3.1 says "The AS MUST consider
both sets of requirements in combination with each other for the given
authorization request." My read is that this is conflicting guidance and
Section 3.1 is correct.
** Figure 15. The text prior to this figure says that for "For our running
example, this would look like this" indicating that this figure is similar to
previous examples. There is one key different - this is the first use of a
"payment_initiator" type with the API URL prepended.
** Section 7.1. Typo. s/sub set/subset/
** Section 8. What is the difference between this section and Section 5 beyond
this text explicitly stating the name of the error value
(invalid_authorization_details). I'd recommend stating the normative behavior
twice; that is, why are both sections needed?
** Section 9.2. Editorial. There is some kind of rendering issues in the
RFC7622 reference. It reads "[!@RFC7662]".
** Section 11.2.
Products supporting this specification should provide the following
basic functions:
Should this section be more tightly scoped to AS behavior instead of a
"products"?
** Section 11.2.
Accept authorization_details parameter in authorization requests
including basic syntax check for compliance with this
specification
Why only "basic syntax checking"? Perhaps "syntax checking"?
** Section 11.2
One option would be to have a mechanism allowing the registration of
extension modules, each of them responsible for rendering the
respective user consent and any transformation needed to provide the
data needed to the resource server by way of structured access tokens
or token introspection responses.
I don't follow the flexibility being described here. "One option ..." with
respect to what?
** Section 11.3. Could this section provide an example of what it would mean
to use JSON schema ids in the type value.
** Section 12. Please note that the Security Considerations of RFC6749,
RFC7662, and RFC8414 apply.
** Section 13.
Implementers MUST design and use authorization details in a privacy-
preserving manner.
I completely agree with the principle, but this design guidance cannot be
enforced without specifics. I recommend s/MUST/must/. The more specific text
in this section can use the normative MUST statements.
** Section 13.
Any sensitive personal data included in authorization details MUST be
prevented from leaking, e.g., through referrer headers.
Is "leaking" the same as being sent unencrypted? Recommend being clear.
** Section 13.
The AS SHOULD share this data with those parties on a "need to know"
basis.
Completely agree. Consider ending this sentence with "... as determined by
local policy", or the equivalent to make it clear that it will not be document
in this specification.
Thanks,
Roman
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
