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 <tors...@lodderstedt.net> 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 <dick.ha...@gmail.com> 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 <jric...@mit.edu> 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 <dick.ha...@gmail.com> 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= > 40pingidentity....@dmarc.ietf.org> 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 <jric...@mit.edu> 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 < > bcampb...@pingidentity.com> 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 <jric...@mit.edu> 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 > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > 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
