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

Aaron Parecki <> Thu, 26 September 2019 15:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 75E7E120958 for <>; Thu, 26 Sep 2019 08:30:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 DqdxY1ZBNHQi for <>; Thu, 26 Sep 2019 08:30:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 89C3B12088D for <>; Thu, 26 Sep 2019 08:30:29 -0700 (PDT)
Received: by with SMTP id c25so7549127iot.12 for <>; Thu, 26 Sep 2019 08:30:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=z8Z8JAyH7YGhj8Zt8ZP9JlE5YFE4q/nM8RJpW3zSaJg=; b=vCvYSYTCESTMczjrQAv6RNoB0/PdzgP9svT0Z0E1YKOfw2cjuZQC2mB9aHt9Xk/9N3 iZkUuD1QQTtBPvXl1F3AXNl2ikcsl2LYn249gfu3nidAXfm8xCZhGtBzP2mlaetgEXjB TTkHOc3NC0SxD9JtJvrnJQSTcI+8Fi22uM9E02skvBaQXvtVc+lXYYmynSyYkVlOnac/ JYFQSQyQxLpxC8TTRGfvIJ+SGp8mBGg9X30nKhqBJlf7IOVr1uHU/C3DaNZ5kmP5NH1z apx+xgytVvAUZBWRlEqWrardX5IlnmGe8iFHp+xctJshQdGv2wFsIYbakMbxoI2q6HK1 5V+w==
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:content-transfer-encoding; bh=z8Z8JAyH7YGhj8Zt8ZP9JlE5YFE4q/nM8RJpW3zSaJg=; b=PtIXERkjhAaVHcRoHzWxkQaABHlSDZVTwO2DM3lqg05goxWvd3wUUFyQQNxOgY8cIA WsFLKdzaXUrY0E1vLdt1sWMvdvuRrzRvMkr+PVvjUETlDvJ020HEneeLtFOzR/LV6pfP cKvNRAD0fUvCs4AAP0UeffHRj06cKtZrab+/uFUe3t3OlDtmzs8JSxPeFA+ia0zKOjbQ AZt+W+zW7rE89+m2NOZVPaAJFLIM9EEIYbN6OEe5P7rPhXzlYgvUkCH6zfx0xpyTNjwf Cmb9Qe101xJvUctZDEiwTDsUce1e/cz38f6wwFOfVfGnCs7uaD77F9/mvdst63OQCCZs QXow==
X-Gm-Message-State: APjAAAVmcRBdjgE7QQO3QjkYU71DpkRRMqTo+NeunNBjkGMYAPdVAyar dfAOdoSI8v84JNODx9NdsB0+SALJlFA=
X-Google-Smtp-Source: APXvYqw5ocWygdDMCidz2Dxj5U7xTUekqhYZaNGRCYb9jjYPi+Y2fcJdMpjzws/AUD/zJZ5MWcNc6Q==
X-Received: by 2002:a92:1bcb:: with SMTP id f72mr2948950ill.129.1569511828407; Thu, 26 Sep 2019 08:30:28 -0700 (PDT)
Received: from ( []) by with ESMTPSA id k66sm1555830iof.25.2019. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Sep 2019 08:30:28 -0700 (PDT)
Received: by with SMTP id b19so7666753iob.4 for <>; Thu, 26 Sep 2019 08:30:27 -0700 (PDT)
X-Received: by 2002:a6b:b494:: with SMTP id d142mr3611629iof.156.1569511827355; Thu, 26 Sep 2019 08:30:27 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Aaron Parecki <>
Date: Thu, 26 Sep 2019 17:30:15 +0200
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Torsten Lodderstedt <>
Cc: oauth <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [OAUTH-WG] Fwd: 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 15:30:34 -0000

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.

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

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

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,
> 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