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

[Roman Danyliw <[e-mail]>]

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