Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

Aaron Parecki <> Thu, 23 July 2020 22:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE4D73A0807 for <>; Thu, 23 Jul 2020 15:50:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, 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 2nrVy6rbauHn for <>; Thu, 23 Jul 2020 15:50:56 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 012813A07FF for <>; Thu, 23 Jul 2020 15:50:55 -0700 (PDT)
Received: by with SMTP id a11so5763517ilk.0 for <>; Thu, 23 Jul 2020 15:50:55 -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; bh=Glj5/i+If+xV5smdo+RsZKFfDKJYpMCBNxI1dxFbOHU=; b=CiilpUf68tSqN9UNtxoY0I29Z+wkmM4KMjzY4L10g0SWjPklUZYECdFxfXszQviR/F 9ie6lyUniO0M/vnRtGcpRyEmMINe8RrOz0pWNUMQBUDbVHu9KA0vmcxnoLMvqCHt0X+0 qj+Dv5EQ5PMk8DcoboCE3er1xwzva3d/trFKBUQ68tghFovPT2iSqr32IoPZDSvXc8Yp bt9dcSjmZthITqzPp1l1XF7aj/Lr3DM9RvL5miBuWLHybyDIqxbdkmrZsbf3FuElMpti OVo7WrgqtvTUXHXQoc7x7jfYkMCn1SisJQZ4RYX0/EURVqLeI/Ydm580iB/gu1zFCdz6 hw0g==
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; bh=Glj5/i+If+xV5smdo+RsZKFfDKJYpMCBNxI1dxFbOHU=; b=QAilsrZAnkplE2lw94K62l2/DIg4+AmtvO1JQ+LNTVWrQ+XbFQCckUHoz/ku+CRee6 h4vo14WprhRK/D+0lKPGA8e2tYBhQiB7qjb9HHfobzPm2FF4GH/0iMGcTM0VZHqTda4O KqusGgGUu4fCPfwVDrpUNpGGocyQnXZP9zvlcJ+4XAWFie9y4xd2TzpIWf0nwTRC8o+Y ExH/F2kj/XQmWqC+cV6a0XirTWbNNM8EHBvti9qwCQ6azMQUpHZ+D2ZKK94/gC1XI0sH nvwvoA7iqiEqqC/Q5QteueI5CXadnA9ZnLvCxHMRONgtzWnAbO4WA5qw/alt/y+4Du1i EEBw==
X-Gm-Message-State: AOAM531MN6Tpzo6vK0mNMczKpVFe3socLGVEsz4izzeoAoLs01z+wbTJ hzdRDHaVTrIgKjN//uLMwOeXKBfFsik=
X-Google-Smtp-Source: ABdhPJzLfh/XbQXaAvtQcsU3DfAcmI3I/mQfAs/MszNzIfVBOZAD1SjBE1Z67WZTx+611UTY9E+9Ag==
X-Received: by 2002:a92:1a08:: with SMTP id a8mr5704912ila.187.1595544654306; Thu, 23 Jul 2020 15:50:54 -0700 (PDT)
Received: from ( []) by with ESMTPSA id i12sm2246081ioi.48.2020. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Jul 2020 15:50:52 -0700 (PDT)
Received: by with SMTP id d18so8019425ion.0 for <>; Thu, 23 Jul 2020 15:50:52 -0700 (PDT)
X-Received: by 2002:a6b:8b86:: with SMTP id n128mr7289001iod.202.1595544652273; Thu, 23 Jul 2020 15:50:52 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Aaron Parecki <>
Date: Thu, 23 Jul 2020 15:49:50 -0700
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: oauth <>
Content-Type: multipart/alternative; boundary="00000000000038dd9005ab23b0aa"
Archived-At: <>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
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: Thu, 23 Jul 2020 22:50:58 -0000

I know this is a bit of an old thread to dig up, but as I'm working through
this draft again, something is sticking out to me about this.

In every other instance of "*_uri" in OAuth and extensions, the value is a
URI (usually https) which will be visited by the user's browser or be sent
a POST request from a client. In the case of PAR, this "request_uri" is
actually just an identifier that is *added* to an existing URL, the
authorization endpoint, not a URL that will be visited itself. This
discrepancy is bothering me.

I would have expected that either:

* The PAR response includes a "request_uri" which is the full URL that the
client would redirect the user's browser to, OR
* The PAR response includes a "request_id" which it adds in the query
string to the authorization endpoint and then redirects the browser to

For example:

POST /as/par HTTP/1.1
      "request_uri": "",
      "expires_in": 60

then the user's browser is sent to whatever the value of "request_uri" is


POST /as/par HTTP/1.1
      "expires_in": 60

then the "request_id" is added to the authorization endpoint (as currently
described by PAR)

My personal preference is the first option, keeping the term "request_uri"
but having it actually be the full URI, to simplify the job of the client.
In that model, the client doesn't have to mess with building URLs, and
actually provides additional flexibility for the AS as well since that
endpoint no longer needs to be the exact same URL as the authorization

Aaron Parecki

On Thu, Jan 16, 2020 at 8:25 AM Torsten Lodderstedt <torsten=> wrote:

> I just thought about another option. What if we change PAR to not use the
> request_uri parameter but a new parameter, e.g. request_id?
> That would decouple both specs. The reason why we use request_uri was to
> make the life of clients easier since they can use the standard library
> function for request objects to pass the PAR reference to the AS. Is this
> worth the trouble?
> Am 16.01.2020 um 16:48 schrieb Justin Richer <>:
> +1 to this approach, and it sounds like JAR might need to come back to go
> through another round anyway thanks to the breaking changes the IESG pushed
> into it after it left WGLC.
> I’d rather see us get this right than publish something many of us think
> is broken.
> Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.
>  — Justin