Hi Roman,
thanks for you review.
I’m trying to do the next round for the outstanding issues you raised.
> Am 15.09.2022 um 00:30 schrieb Roman Danyliw :
>
> 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.
I’m not sure how to handle this as there is no direct consequence (in the sense
of error condition) other then that different byte arrays constitute different
types.
We could state something like this: "String values with different byte
representations constitute different types.“ ?
>
> ** 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
The spec uses authorization details types to refer to the general concept and
authorization_details to refer to the parameter. I think the former is
appropriate at this place.
>
> ** 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.
Justin: „You aren’t required to use “scope” in order to use
“authorization_details”, but we do want to say that the AS is allowed to (or
even is supposed to) consider both “scope” and “authorization_details” when
determining the resulting access for any given request that might have both.
The guidance in 3.1 should probably say “the AS MUST consider all requirements
present on a request” or something like that?“
Section 3 already states that the AS must consider scope and resource in
addition to authorisation details. I suggest to drop that sentence entirely.
>
> ** 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?
5 and 8 define the error behaviour of different endpoint. But you are right,
the text is the same (with 5 being even more detailed). Suggest to remove the
text in 8 with a reference to 5.
best regards,
Torsten.
>
> ** 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 pro
