Re: [OAUTH-WG] WGLC Review of PAR

[Dick Hardt <[e-mail]>]

I don't have the context of the text to respond to the exact wording, but I
think we can state that the client MUST use the "request_uri" only once,
and then explain that the AS may receive duplicate requests if the browser
is reloaded.


On Sat, Aug 29, 2020 at 4:24 AM Torsten Lodderstedt <[e-mail]>
wrote:

> You are making a good point here. The reason we added the one time use
> constraint was the fact the client will include parameters supposed to be
> used only once, e.g. the PKCE code_challenge. For a traditional
> authorisation request, we would recommend the client to use a per
> transaction (== one time use) code_challenge, but PKCE does not require the
> AS to enforce it. Mapping this to PAR means, we SHOULD recommend the client
> to use the request_uri only once but not require the AS to enforce it.
>
> Would the following text work for you?
>
> Since parts of the request content, e.g. the "code_challenge"
>    parameter value, is unique to a certain authorization request,
> the client SHOULD use the "request_uri" only once.
>
> I also would move this text to section 4.
>
> > On 27. Aug 2020, at 18:11, Dick Hardt <[e-mail]> wrote:
> >
> > That is not correct.
> >
> > The authorization code one-time-use is directly between the client and
> the AS. The client has a number of mechanisms to ensure it only presents
> the authorization code to the AS once, such as a session that was set when
> the user started at the client.
> >
> > In contrast, in a redirect from the client to the AS, the client loses
> control on how many times the user-agent loads the URL at the AS.
> Additionally, there is unlikely to be an active browser session at the AS,
> so the AS can not easily differentiate between a URL load from the same
> user, or different users. If one-time-use, one of them MUST fail. If the
> two requests happen to be from the same user (because of a reload, which
> the user did because the AS was slow to respond), there is no way for the
> AS to know which of the requests is the one that is current in front of the
> user. While the AS can internally ensure processing of the request once,
> one-time-use would dictate that it provides a failure message to one of the
> requests.
> >
> > /Dick
> >
> >
> > ᐧ
> >
> > On Thu, Aug 27, 2020 at 7:17 AM Justin Richer <[e-mail]> wrote:
> > We already have this same property with authorization codes, and it’s
> managed today reasonably well (in my opinion). If you submit the same
> request URI twice in the same browser (the refresh you’re talking about),
> it shouldn’t start two separate authorization requests, but it would be
> reasonable to detect that the same session attached to the same request URI
> value showed up twice and continue the session as appropriate.
> >
> > None of this is in conflict with “one time use”, in my view, since
> you’re actively detecting the session and source of the value.
> >
> >  — Justin
> >
> >> On Aug 26, 2020, at 6:16 PM, Dick Hardt <[e-mail]> wrote:
> >>
> >> I think one-time use may be overly restrictive, and I don't think it is
> the property that we actually want.
> >>
> >> Give the request URI is in a redirect from the browser, there is a good
> chance of a race condition where the same browser request is made more than
> once, for example, while the browser is loading the authorization URL at
> the AS, the user could refresh the page causing the authorization URL to be
> reloaded. Would the reload count as a second use? One could argue it either
> way.
> >>
> >> What I think we want from what I understand, is the request URI MUST be
> unique so that there is no confusion on which request is being referenced.
> >>
> >> I did not see anything about the expiry time of the request URI (but I
> did not look super hard). If that is not there, then I think the request
> URI MUST expire in a "short" period of time.
> >>
> >>
> >>
> >> ᐧ
> >>
> >> On Wed, Aug 26, 2020 at 1:45 PM Brian Campbell <bcampbell=
> [e-mail]> wrote:
> >> Thanks Justin. Just a couple more responses to responses inline below
> (but with lots of content that needs no further discussion removed).
> >>
> >> A TL;DR for the WG is that I'd like to get some wider feedback on the
> question of changing the one-time-use condition on the request_uri from a
> SHOULD to a MUST.
> >>
> >> On Tue, Aug 25, 2020 at 4:57 PM Justin Richer <[e-mail]> wrote:
> >> Hi Brian, just a couple responses inline where it seemed fitting.
> Thanks for going through everything!
> >>  — Justin
> >>
> >>> On Aug 25, 2020, at 6:01 PM, Brian Campbell <
> [e-mail]> wrote:
> >>>
> >>> Thanks for the review and comments Justin. Replies (or attempts
> thereat) are inline below.
> >>>
> >>>
> >>> On Wed, Aug 19, 2020 at 2:06 PM Justin Richer <[e-mail]> wrote:
> >>> I’ve done a full read through of the PAR specification, and here are
> my notes on it.
> >>>
> >>>
> >>>     ¶2: Of necessity, this spec mixes parameters in the authorization
> endpoint and token endpoint registries into a single request. Is there any
> danger of conflict between them? The registry holds them in one list but
> they could possibly have different semantics in both places..
> >>>
> >>> I think that technically such danger does exist but that it's highly
> unlikely in practice. Especially because the only token endpoint parameters
> that are relevant to PAR are those that deal with client authentication
> (currently client_secret, client_assertion, and client_assertion_type). I'm
> also not sure what can reasonably be done about it given the way the
> registries are. I guess PAR could update the registration for those three
> (client_secret, client_assertion, and client_assertion_type) to also
> indicate authorization request as a usage location with some commentary
> that it's only for avoiding name collisions. And offer some guidance about
> doing the same for any future client auth methods being defined. But
> honestly I'm not sure what, if anything, to do here?
> >>>
> >>> And yes it is super unfortunate that client auth and protocol
> parameters got mixed together in the HTTP body. I didn't cause that
> situation but I've certainly contributed to it and for that I apologize.
> >>
> >> I think the only perfect solution is to go back in time and fix the
> registries with based on the last decade of knowledge in using them. :P
> >>
> >> For this, I think maybe being very prescriptive about the fact that the
> only parameters from the token endpoint that are allowed here are those
> used for client authentication and that when they show up, they’re
> interpreted as in the token endpoint request not the authorization endpoint
> request. Does that work?
> >>
> >> I think so, yes.. And will work on incorporating some text towards that
> end.
> >>
> >>
> >>
> >>>     I don’t see why a request URI with unguessable values isn’t a MUST
> for one-time-use, is there a reason?
> >>>
> >>> The reason AFAIK was to not be overly prescriptive and allow for
> eventually consistent or not atomic storage of the data by not strictly
> requiring the AS to enforce one-time-use. Do you think that's too loose or
> could be worded/explained differently or better?
> >>
> >> I do think it’s too loose and it should be a MUST, and the methods for
> enforcing that “MUST” are going to vary based on the deployments and
> implementations out there.
> >>
> >>
> >> I'd be okay with making it a MUST but think maybe it'd be good to hear
> from a few more people in the WG before committing to that change.
> >>
> >> Can I ask some folks to weigh in on this one? I'm leaning towards
> making the change barring objections.
> >>
> >>
> >> CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly
> prohibited...  If you have received this communication in error, please
> notify the sender immediately by e-mail and delete the message and any file
> attachments from your computer. Thank
> you._______________________________________________
> >> OAuth mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
>
> ᐧ