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 <r...@cert.org> 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 <jric...@mit.edu> >>> Sent: Thursday, September 15, 2022 11:20 AM >>> To: Roman Danyliw <r...@cert.org> >>> Cc: oauth@ietf.org >>> 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 <r...@cert.org> 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
