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

Justin Richer <> Thu, 26 September 2019 16:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 53C9012009E for <>; Thu, 26 Sep 2019 09:49:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J8-fYRux9DdY for <>; Thu, 26 Sep 2019 09:49:52 -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 A4968120019 for <>; Thu, 26 Sep 2019 09:49:51 -0700 (PDT)
Received: from (W92EXEDGE4.EXCHANGE.MIT.EDU []) by (8.14.7/8.12.4) with ESMTP id x8QGnKi8029064; Thu, 26 Sep 2019 12:49:21 -0400
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1293.2; Thu, 26 Sep 2019 12:48:43 -0400
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 26 Sep 2019 12:49:22 -0400
Received: from ([]) by ([]) with mapi id 15.00.1365.000; Thu, 26 Sep 2019 12:49:22 -0400
From: Justin Richer <>
To: Aaron Parecki <>
CC: Torsten Lodderstedt <>, oauth <>
Thread-Topic: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt
Thread-Index: AQHVdIpY21j3hq2VmkCWElppvnoDQQ==
Date: Thu, 26 Sep 2019 16:49:22 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_BB0AE29D5CD04441B3B6FEB6D3F749EEmitedu_"
MIME-Version: 1.0
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: Thu, 26 Sep 2019 16:49:55 -0000

Aaron, some comments inline.

— Justin

On Sep 26, 2019, at 8:30 AM, Aaron Parecki <<>> wrote:

Hi Torsten,

I'm very glad to see this draft, I think it's definitely needed in
this space. Here are some of my thoughts on the draft.

"request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2"

Is it acceptable for the AS to return just an opaque string, rather
than something prefixed with "uri:*"? I don't think anyone would be
confused about copypasting the exact string from the "request_uri"
response into the "request_uri" parameter even if it didn't start with
"urn:". If, for whatever reason, it is required that this value is
actually a URI, is there some expected namespace to use other than
"example"? I worry that if all the examples in the spec are just
"urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" then developers will end up
using the text "example" because they don't understand why it's there,
and then it serves no purpose really.’

This field must be a URI, as per JAR:

   request_uri  The absolute URI as defined by RFC3986<> [RFC3986<>] that
      points to the Request Object (Section 2.1<>) that holds
      authorization request parameters stated in section 4<> of OAuth 2.0

Somewhat awkwardly, the JAR spec currently states that the AS has to do an HTTP GET on the request URI, so that will need to be fixed in JAR before it goes forward. I don’t think that was always the case though, and I’m not sure how that changed.

As for the namespace, “example” is ok for an example URN. The problem with URNs is that nobody really understands how to do domain-safe fully compliant URNs. So perhaps we should instead use “<>:….” Instead (as per

The pushed authorization request endpoint shall be a RESTful API

I would drop the term RESTful and just say "HTTP API", as this
description is arguably RESTful at best.

Depending on client type and authentication method, the request might
 also include the "client_id" parameter.

I assume this is hinting at the difference between public clients
sending only the "client_id" parameter and confidential clients
sending only the HTTP Basic Authorization header which includes both
the client ID and secret? It would probably be helpful to call out
these two common examples if I am understanding this correctly,
otherwise it seems pretty vague.

Not quite, those differences are for the token endpoint, and this is capturing things from the authorization endpoint. I don’t quite understand the differentiation listed here either, though.

The "request_uri" value MUST be generated using a cryptographically
 strong pseudorandom algorithm

I assume this includes the use of a random number inside of a JWT, in
case the AS wants to use JWTs as the "request_uri" parameter"? If so,
it's probably worth spelling that out as it kind of reads like it has
to be literally a random string at first glance.

The URI is intended to be a reference not a value. If the client could send a JWT it would just send a request object instead of a request URI in the first place. So the intent is that it’s random, and maybe we should just say that explicitly.

That's all for now, thanks!

Aaron Parecki<>

On Sat, Sep 21, 2019 at 1:02 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,

Begin forwarded message:

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

 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

OAuth mailing list