Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-12

[Justin Richer <[e-mail]>]

Thank you, Roman — I put together a PR with those changes here:

https://github.com/oauthstuff/draft-oauth-rar/pull/89

 — Justin

> On Oct 27, 2022, at 1:51 PM, Roman Danyliw <[e-mail]> wrote:
> 
> Hi!
> 
> I appreciate the updated in -13 and -14.  Most of the AD feedback has been addressed there.  Combing through the multiple sub-threads, I've pruned to text to cover what is the residual feedback.  See below.
> 
> To keep this document moving, I'm going to start IETF LC on it.  Please address this feedback concurrently.
> 
>>> -----Original Message-----
>>> From: Justin Richer <[e-mail]>
>>> Sent: Thursday, September 15, 2022 11:20 AM
>>> To: Roman Danyliw <[e-mail]>
>>> Cc: [e-mail]
>>> Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-12
>>> 
>>> Hi Roman, some responses inline.
>>> 
>>>> On Sep 14, 2022, at 6:30 PM, Roman Danyliw <[e-mail]> wrote:
> 
> [snip]
> 
>>>> ** 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.
>>>> 
>>> 
>>> It might be possible to do such a comparison in a specific case, but
>>> we can’t add logic in the general case. In OAuth, scopes are supposed
>>> to be purely additive, so if you have another scope it’s for “more”
>>> things. We know in practice that that’s not always how it works.
>>> Things get much more complex with RAR because you could have an object
>>> with :more: fields in it that makes things more :strict: by the
>>> presence of those fields. That’s all going to be up to the “type”
>>> definition though, so if you understand the “type” definition you
>>> could do a comparison based on that. To me the text is clear, can you suggest
>> how we could clarify this?
>> 
>> OLD 1
>> Since the nature of an authorization details request
>>   is based solely on the API or APIs that it is describing, there is
>>   not a simple means of comparing any two arbitrary authorization
>>   details requests.
>> 
>> NEW 1
>> Since the semantics of the fields in the authorization details result will be
>> implementation specific to a given API or set of APIs, there is a no standardized
>> mechanism to compare two arbitrary authorization detail requests.
>> 
>> OLD 2
>>   However, when comparing a new request to an existing request,
>> 
>> NEW 2
>> 
>> When comparing a new request to an existing request, ...
> 
> [snip]
> 
> 
>>>> ** 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"?
>>> 
>>> I’m not positive, but I think the guidance here is meant for “basic”
>>> to mean more like “make sure it’s a JSON object and that it has a type
>>> field” as opposed to “check the type field’s value and run it against a JSON
>> Schema definition”.
>> 
>> I don't think this is worth unpacking and would just recommend:
>> 
>> OLD
>> *  Accept authorization_details parameter in authorization requests
>>      including basic syntax check for compliance with this
>>      specification
>> 
>> NEW
>> *  Accept authorization_details parameter in authorization requests
>>      Conformant with this this specification
> 
> Thanks,
> Roman
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth