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
