Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt

Torsten Lodderstedt <> Mon, 23 September 2019 18:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3327A120088 for <>; Mon, 23 Sep 2019 11:17:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.627
X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.026, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HasKpXjvdvQJ for <>; Mon, 23 Sep 2019 11:17:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 68DB012004D for <>; Mon, 23 Sep 2019 11:17:06 -0700 (PDT)
Received: from [] (helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) (envelope-from <>) id 1iCStT-000680-HM; Mon, 23 Sep 2019 20:17:03 +0200
From: Torsten Lodderstedt <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_7E0DB8C1-AF81-489A-9B0C-EF0F24F86AFE"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 23 Sep 2019 20:17:02 +0200
In-Reply-To: <>
Cc: oauth <>, Filip Skokan <>
To: Janak Amarasena <>
References: <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <>
Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt
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: Mon, 23 Sep 2019 18:17:09 -0000

Hi Janak,

thanks for your feedback to PAR as well. 

> On 22. Sep 2019, at 21:51, Janak Amarasena <> wrote:
> Hi,
> Since the /as/par endpoint is intended to be used to store the actual authorization request I feel that validating the authorization request as mentioned in point 2 section 2.1(Request) should not be a responsibility of the /as/par endpoint and that it should not validate the authorization request.

Why do you think so?

Validating the request data at the pushed authorisation request endpoint has the advantage that the AS can refuse the process early. It also means the authorisation endpoint of the AS can safely assume all request URIs sent in Authorization Request that are minted by the same AS (which is detected based on its structure), are pre-checked and can be trusted (regarding the input validation).  

> Also, the majority case could be the endpoint receiving valid requests and the validation process will be duplicated at the authorization endpoint.

I would assume the same core service is used to check the payload, so no code duplication required.

> Also since section 2.2 (Successful Response) states;
> The "request URI" MUST be bound to the "client_id" of the client that posted the authorization request.
> Wouldn't it be good to enforce the use of the clientId in section 4 (Authorization Request) when the authorization request is made with the "request_uri" parameter?
> GET /authorize?request_uri=urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2&client_id=s6BhdRkqt3 HTTP/1.1

There is no need for an additional client id since the request URI is already bound to the client_id passed to and, in case of a confidential client, authenticated in the pushed authorization request.

best regards,
> Best Regards,
> Janak Amarasena
> On Sat, Sep 21, 2019 at 4:32 PM Torsten Lodderstedt <> wrote:
> Hi all, 
> I just published a new draft that Brian Campbell, Dave Tonge, Filip Skokan, Nat Sakimura and I wrote. 
> It proposes a new endpoint, called "pushed authorization request endpoint”, that allows the client to push the Authorization Request payload with the AS on a backchannel connection instead of a front channel interaction. The AS provides the client with a request URI (according to draft-ietf-oauth-jwsreq) that the client uses in a subsequent authorization requests to refer to the pushed request data. 
> We believe this simple mechanism will significantly increase OAuth security and robustness since any application can use it by just sending the parameters in the same encoding as used at the authorisation endpoint over a HTTPS-protected and (for confidential clients) mutually authenticated connection to the AS. It can also be used to push signed and encrypted request objects to the AS, i.e. it provides an interoperable way to use request objects managed at the AS for use cases requiring an even higher security level.
> We look forward to getting your feedback. 
> kind regards,
> Torsten. 
>> Begin forwarded message:
>> From:
>> Subject: New Version Notification for draft-lodderstedt-oauth-par-00.txt
>> Date: 21. September 2019 at 12:47:28 CEST
>> To: "Nat Sakimura" <>, "Brian Campbell" <>, "Torsten Lodderstedt" <>, "Dave Tonge" <>, "Filip Skokan" <>
>> A new version of I-D, draft-lodderstedt-oauth-par-00.txt
>> has been successfully submitted by Torsten Lodderstedt and posted to the
>> IETF repository.
>> Name:		draft-lodderstedt-oauth-par
>> Revision:	00
>> Title:		OAuth 2.0 Pushed Authorization Requests
>> Document date:	2019-09-21
>> Group:		Individual Submission
>> Pages:		12
>> URL:  
>> Status:
>> Htmlized:
>> Htmlized:
>> Abstract:
>>   This document defines the pushed authorization request endpoint,
>>   which allows clients to push the payload of an OAuth 2.0
>>   authorization request to the authorization server via a direct
>>   request and provides them with a request URI that is used as
>>   reference to the data in a subsequent authorization request.
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at
>> The IETF Secretariat
> _______________________________________________
> OAuth mailing list