Re: [OAUTH-WG] WGLC Review of PAR

Dick Hardt <dick.hardt@gmail.com> Sun, 30 August 2020 22:48 UTC

Return-Path: <dick.hardt@gmail.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 00FA23A0833 for <oauth@ietfa.amsl.com>; Sun, 30 Aug 2020 15:48:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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=gmail.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 eUH3mk9QznQE for <oauth@ietfa.amsl.com>; Sun, 30 Aug 2020 15:48:39 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 380423A0831 for <oauth@ietf.org>; Sun, 30 Aug 2020 15:48:39 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id j15so2460907lfg.7 for <oauth@ietf.org>; Sun, 30 Aug 2020 15:48:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7oYvtN0LPMBk3bR0HEfd2hSxg007Vknk/5cRcnKjQYk=; b=V04BK4YIoIMK417NQ3d3Zo+5sOwp7GLdl0ncLBcqHggL6rsEcMnRYeYwtNRmHmaPjy T/q12MhsiuR7MVPzEhog0aZBJm62svHh6ps5L0Bc7S5PgfVOJyd5xX9pbrO2Db8X3B2a OOOyvPPCtMSYv3xiWTufOsGV2cAEj3PETz5xvDcU91Tlt8469c399s9DLbFpeztubDsL VcwcWjZamr0gmV8cPQfg82whLLDf2x/2s0imUW0ZKANF/6MjK2wrWIrOaWYETt2sxGpK batOlFm+YwrrMUbCLkVRiyEEH/O1BP9N69ln0LkRSF3btWGZWqoFFEt2eflFXDkHsPDa RS3A==
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=7oYvtN0LPMBk3bR0HEfd2hSxg007Vknk/5cRcnKjQYk=; b=HRNnLbSR+/a88XF5Gq95I1CKE5wwmUQn8RlcjXz7G5xso4eEeludUT0NMDq6daIhKh RfmTDtbz8oIGboeBE5AKJBPSJL0f5+yVr9cgrpyyYGEaCk3966FXVJ8JeDQO2qb6Q7Jv GqyKT6AmKcLasj+df1bIi2xMM+1Q/NvpddEnTm7dwPMPfFSZ57nC1KUzXcm5zxXgsYrb PNHN5ERobPw/pCU64vfVMEloDGPAo9Xn0mm+CuoXNX0C6ARpdpu+2HoWf3AhXoeaBdf9 pp0lkDmOe2Cptxy5D94qcENH1yTK+TEfDTRF0dHWq1GOtiPTVq/r7vrKjMxZdXm7AOw4 LBUg==
X-Gm-Message-State: AOAM5333CIlK5m7qYvumKkruFLPuF8cNR5/oU3IdFFj6qN9uD4AQrOtU iIpmLq8O6JQIi1eWEAn75VvRBxoLCyKTUBedxkU=
X-Google-Smtp-Source: ABdhPJxoW4Zf+9Ccbf/JTolDDKSlyr31kulHHrZ3D4Rp3DFjdSDBTkextiF82vMQX3xxpLQvulLClrWPhvVEbKKDbQY=
X-Received: by 2002:a19:70c:: with SMTP id 12mr4322468lfh.207.1598827717146; Sun, 30 Aug 2020 15:48:37 -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>
In-Reply-To: <102C6B96-C1FA-4BC1-8932-C7F4F377CFFE@lodderstedt.net>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Sun, 30 Aug 2020 15:48:01 -0700
Message-ID: <CAD9ie-u1fKDTyD1sCqaC_0qsgvLdJ3=B7T7MvyRN2ThUYva2GQ@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: Justin Richer <jricher@mit.edu>, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000233afc05ae2016b5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/n2cO83V5DTMMHP2eXUbBcfcQoBw>
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: Sun, 30 Aug 2020 22:48:42 -0000

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
>
> ᐧ