Re: [OAUTH-WG] WGLC Review of PAR
Brian Campbell <bcampbell@pingidentity.com> Mon, 31 August 2020 15:40 UTC
Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1C43A15FC for <oauth@ietfa.amsl.com>; Mon, 31 Aug 2020 08:40:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTdl5WGFdk9B for <oauth@ietfa.amsl.com>; Mon, 31 Aug 2020 08:40:19 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A20BB3A15F6 for <oauth@ietf.org>; Mon, 31 Aug 2020 08:40:18 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id c15so3768510lfi.3 for <oauth@ietf.org>; Mon, 31 Aug 2020 08:40:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3pz3e9hlSRQaI4l82X6D0aAQvqVzxbfHOZFwayUGD4s=; b=So7rxjnqn/ywP/oeEvn9rJIQaM67qlbK6GGcNpW7UrMxMlHVPVeRLcz054n54GUws8 Mv2h2uCLpcxmNogL6E01lbMqhvDUpQ9OKDbIMCFd2i8H/NrnsQy01kbhnTlDfWPyBsPZ 8wa3x6bi7uToOw1WYlIKR4LHSiUjyPmA1scoibcu73E4C7OMXS7WNzlLm32fNyijT9UB Pv61x5oS/KJOKado2Uj4HgF950VTny7zrTEt0EsPMjLHCn4Qm2jKTOiFQC+efSgu31W0 /hVcjJeQ0g/4qjdEt9XquGIhp7LqqES22nLTBPpVxnuufCm68X8p53ScNygMXQx2Sh+Q /6Lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3pz3e9hlSRQaI4l82X6D0aAQvqVzxbfHOZFwayUGD4s=; b=nADdvQF7WjGKq/RoexBP4H0ntzm1G9sI16IjeEpq/66m5nSUx2xZi6qmfpcrJZwPY2 i2sSrQat4thM35Tg0sGMCUdpDjXRtbocGO/FpzxFyPGkNSsG3//7e4MyK0Ju79WuVw8G aSxhI78QoOjWshFf1LDc0AQkE/6WPZbfSYx4n7XGwIT6I6pXKHy4lpT5IYS5Us4zZ7ko G3GhlVFS8Sepxse2tUm4VMND02YShimwovW1AlbieO9PZvaIkuShIHJBGfQjE1GzXeTB uQ8pxYn7+BWc+7RSwS/RQ43D/ZHmWEovJMEyfy2wM3aiWdfEOk2AALWoTXnoOD+xpLJj 5Mbw==
X-Gm-Message-State: AOAM530IP3FSqgrO01bQlA+GyG8wfRh5FDqZfGHYq1/8aKZ1UoV1Dmi5 cH5OrDk/Ok6DDSr5jXWok/XofvVim0O63D3LxjDhaxOAIjikBw/YEEHKPcum32Ge46Oei522vHg 6bVSdbGYA722sZg==
X-Google-Smtp-Source: ABdhPJxEW5nDlP0u+1uS96Be9NI1LIdCW1Qbur8/dlGYnZOwc9HKsfsSQ78NSvi54Vm0FXDVsSF+ztK/cwoOXFNLSL4=
X-Received: by 2002:a19:418a:: with SMTP id o132mr982560lfa.63.1598888416653; Mon, 31 Aug 2020 08:40:16 -0700 (PDT)
MIME-Version: 1.0
References: <7C0FD285-F677-4501-B2FB-9431A59855F6@mit.edu> <CA+k3eCRsBTvdhyzBOETxWLd6PJ61B2W4yY5QHv196amDFq7gnQ@mail.gmail.com> <C43FDA5A-7422-4DF4-B5B3-77C35C051CD4@mit.edu> <CA+k3eCS2C73FYTmna24VXEnxzFcuXfNOSm1psiHM2FOak6=7jQ@mail.gmail.com> <CAD9ie-vWvvhVmUEHNWxGmngr5UafH7Bi4AP84AB38=3CK04Y8g@mail.gmail.com> <F6B03D81-5DD6-4E51-B387-DAD2C1202601@mit.edu> <CAD9ie-uooPukCxJ7nUT6wtG7=z3vV86mBJahh=W4+JpGs5jxrA@mail.gmail.com> <102C6B96-C1FA-4BC1-8932-C7F4F377CFFE@lodderstedt.net> <CAD9ie-u1fKDTyD1sCqaC_0qsgvLdJ3=B7T7MvyRN2ThUYva2GQ@mail.gmail.com>
In-Reply-To: <CAD9ie-u1fKDTyD1sCqaC_0qsgvLdJ3=B7T7MvyRN2ThUYva2GQ@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 31 Aug 2020 09:39:50 -0600
Message-ID: <CA+k3eCThL-UQs=NkcqgnV2nNJNskKkYgxef7M4zG+gn4cQr_EQ@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Torsten Lodderstedt <torsten@lodderstedt.net>, Justin Richer <jricher@mit.edu>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001c518a05ae2e3886"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/xofmLF30MGuzbAS1zKXA1luB_Ow>
Subject: Re: [OAUTH-WG] WGLC Review of PAR
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2020 15:40:22 -0000
I'm not sure how to word it exactly but I think Dick has landed on what we ultimately want this to say. Basically that the "request_uri" is intended to be used only once, the client MUST not use it more than once, and that the AS should also treat it as one-time use but may make reasonable accommodations to more gracefully handle redundant authorization requests due to browser reload or similar. On Sun, Aug 30, 2020 at 4:48 PM Dick Hardt <dick.hardt@gmail.com> wrote: > 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 < > torsten@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.hardt@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 <jricher@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.hardt@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.com@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 <jricher@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 < >> bcampbell@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 <jricher@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 >> >> ᐧ > -- _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-WG] WGLC Review of PAR Justin Richer
- Re: [OAUTH-WG] WGLC Review of PAR Brian Campbell
- Re: [OAUTH-WG] WGLC Review of PAR Justin Richer
- Re: [OAUTH-WG] WGLC Review of PAR Brian Campbell
- Re: [OAUTH-WG] WGLC Review of PAR Dick Hardt
- Re: [OAUTH-WG] WGLC Review of PAR Justin Richer
- Re: [OAUTH-WG] WGLC Review of PAR Dick Hardt
- Re: [OAUTH-WG] WGLC Review of PAR Torsten Lodderstedt
- Re: [OAUTH-WG] WGLC Review of PAR Torsten Lodderstedt
- Re: [OAUTH-WG] WGLC Review of PAR Justin Richer
- Re: [OAUTH-WG] WGLC Review of PAR Torsten Lodderstedt
- Re: [OAUTH-WG] WGLC Review of PAR Dick Hardt
- Re: [OAUTH-WG] WGLC Review of PAR Brian Campbell
- Re: [OAUTH-WG] WGLC Review of PAR Torsten Lodderstedt
- Re: [OAUTH-WG] WGLC Review of PAR Takahiko Kawasaki
- Re: [OAUTH-WG] WGLC Review of PAR Justin Richer
- Re: [OAUTH-WG] WGLC Review of PAR Brian Campbell
- Re: [OAUTH-WG] WGLC Review of PAR Justin Richer
- Re: [OAUTH-WG] WGLC Review of PAR Torsten Lodderstedt
- Re: [OAUTH-WG] WGLC Review of PAR Brian Campbell
- Re: [OAUTH-WG] WGLC Review of PAR Dave Tonge
- Re: [OAUTH-WG] WGLC Review of PAR Torsten Lodderstedt
- Re: [OAUTH-WG] WGLC Review of PAR Torsten Lodderstedt