Re: [OAUTH-WG] WGLC Review of PAR

Dick Hardt <> Wed, 26 August 2020 22:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9DA043A093A for <>; Wed, 26 Aug 2020 15:16:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kGqh3VwrxxAf for <>; Wed, 26 Aug 2020 15:16:50 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 543DC3A0934 for <>; Wed, 26 Aug 2020 15:16:50 -0700 (PDT)
Received: by with SMTP id m22so4166144ljj.5 for <>; Wed, 26 Aug 2020 15:16:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N96mq3kxZ7sFwwyniutso4NEGauCNvAydA74KWLOWWY=; b=U6+GWIan30Yxy1E/KT0tdxrpGg6K2D3mZ8jRbL9Lz/g5vgtVN9MV1C2N0frZebgRV1 aU5c80CfevJfc2BKtKbCh6e/3PO3ptjm33A8BifTwUWejzr8akmE6I+g36ml++wh2k0g d8WR3x7Zg06SrtbErHsnN7Lmb4Het+IXJzoqKgBIGsMf9cyEKJ1smy3beUX3TdCWXHwC YBQ/LtGVuh1InE12lF0+VHPVUknkkQXeF8TJmijLV91lodRFx6CiLSn8VFwYJdwdjgsJ zvfuZky0Nye9Gpc1jCrJ1trbGSj2PutN6OZ7w0OyzUXOW8EgPRolT4KvIyhJBIy2SPaL xL2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N96mq3kxZ7sFwwyniutso4NEGauCNvAydA74KWLOWWY=; b=EBESf9FDEj4bwZDyehSazbwBhxCUHrpbKpNEtwxuYj/Tts1Qi+vdX6vq9o0YhmKlIQ OwozQ/CARQdIMR7g4y+zMIDMRRksKRULSazUocyGfsMycd55t3aJIGrrY38ddm1Fe3uO bdyHUx5HilUd3FVWxE1lR2WT+K2XOU1EXEask+eTVL6R8VOFmXa0DVi4YfN1RhPJpcCR jhAW3vlibGdpJaRIARF5cqJPwFxLe4zjF61UrjfvYMSUfVYH0juD4dKJtQsmYkskSpmZ 7UbMaiCb1t0pGqivluMwKS9JLU0AGWHku3VUPyA1x3j113p+ls4xhrS0958P2IIkZi8n K4ag==
X-Gm-Message-State: AOAM533mSJ1OqLziWivZWUfg7NbNM6hbNDmnUSa4+arZ2HK3+8bHiDcD 88IP4QUkaxKumRfZfZ1qK+Y4WoH0Yc8hBHha2GI=
X-Google-Smtp-Source: ABdhPJymZjjW3IlepI71GQ4cSGHTbfcqSTGXDwWpX0iq4R1b/Ei8K3XibDD98WF0NcZUGGBmgDFcqrMN20AigEnnEgg=
X-Received: by 2002:a2e:7215:: with SMTP id n21mr8770762ljc.242.1598480208096; Wed, 26 Aug 2020 15:16:48 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Dick Hardt <>
Date: Wed, 26 Aug 2020 15:16:12 -0700
Message-ID: <>
To: Brian Campbell <>
Cc: Justin Richer <>, oauth <>
Content-Type: multipart/alternative; boundary="000000000000fbf08f05adcf2ca2"
Archived-At: <>
Subject: Re: [OAUTH-WG] WGLC Review of PAR
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Aug 2020 22:16:53 -0000

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=> 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
> On Tue, Aug 25, 2020 at 4:57 PM Justin Richer <> 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 <>
>> 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 <> 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