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
