Re: [OAUTH-WG] WGLC Review of PAR

Brian Campbell <> Wed, 26 August 2020 20:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BF4F3A0B75 for <>; Wed, 26 Aug 2020 13:44:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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_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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4JeNah3zlkE1 for <>; Wed, 26 Aug 2020 13:44:50 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EC0453A0B63 for <>; Wed, 26 Aug 2020 13:44:49 -0700 (PDT)
Received: by with SMTP id t23so3945123ljc.3 for <>; Wed, 26 Aug 2020 13:44:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4LQtn6+lr45IpS7SuoSwMQC+tDneFYeVl9i1mdHQeE0=; b=Ab/QtLQJ+DDvurQ9yPB83RuRCS1r6npOkVesJX8uqC1c+8wN5kdxwxk0u51QPmKTu9 m3voZ0xwpNoAnc3XeUA9Y+IFR51PZ/3IQu8fjOUD16O2TANl4qHT3htXhhV6d0t5KI7S rJ0Q0rYb8GpkQHWc2dVAX4tkIMAnZ8OqJjqrOoi5EmvCdrN/Erlk24U5LPSSMGgZLcy/ SHKhkleqorJbyQu9vEshVlsYxWMZ7X/DxYnXeqAYhGxVAbHv1Y4eM4+JVKPd8b45Ltk6 fqqgkwmGT3W2sO+1fje4nijk5KpYJwt7eSPUosD7zFdlOybyJjogRb7Ex/F5VCQDYjkQ qsNg==
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=4LQtn6+lr45IpS7SuoSwMQC+tDneFYeVl9i1mdHQeE0=; b=I9Bsif20WWmMqwugqPkkuXNGCEn7LV4CEWurWVWpp3iDOVv/h1SxjUIYg1K+1fOyWd xn1ZYdD0qdelQ2RIlBtALp6gN4wivy31iTtStpHvAIwO3KqqF6GDmzuG94654WZ1JgRk k/9RPXf4tIja3bplY+r3jCWFGw8Y1HmsxsldqJcVix6x8BhBXBloytqE98EVE4MB6uhi qjKDpgHTM1Fjq8icO//rWt7hSQzoWo+2WOg6i+FCuiKNgqPHk4U4QI6vbTNehwd4VbWo mBD7hlEGtUb+R6wk8T/decwQ6+NioCWTVjq7VZ3onUp7T7QTjpw9AKIMZlsVeCFu2Nkr vYpA==
X-Gm-Message-State: AOAM532wlRmKj87SlUW680sOV/y8l1ZkxbEPuoO2a/x/Vdl6K7T9FTi1 fjoIz53GpvvcQi0t2nhxz9RzVqpJso75np0ntG75kQrH9o4C1E0WWKB2fHkYsPOY0OBaKpZarmc Fb7Nhrw7Yt4lQ47eKZdrABA==
X-Google-Smtp-Source: ABdhPJzRGParRqpHYuAD8gqMveXauXxQtyihP5PWYGVAXqp5dvcJG1shZmlPmd23kd7dcm6K0iE9v76pDln0Y2vdvAw=
X-Received: by 2002:a05:651c:1136:: with SMTP id e22mr7956062ljo.422.1598474687771; Wed, 26 Aug 2020 13:44:47 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Brian Campbell <>
Date: Wed, 26 Aug 2020 14:44:21 -0600
Message-ID: <>
To: Justin Richer <>
Cc: oauth <>
Content-Type: multipart/alternative; boundary="000000000000f295ac05adcde370"
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 20:44:52 -0000

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._