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

Takahiko Kawasaki <taka@authlete.com> Sat, 05 October 2019 00:11 UTC

Return-Path: <taka@authlete.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C5812006B for <oauth@ietfa.amsl.com>; Fri, 4 Oct 2019 17:11:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=authlete-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAeSi-sjh5Gc for <oauth@ietfa.amsl.com>; Fri, 4 Oct 2019 17:11:20 -0700 (PDT)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9158120052 for <oauth@ietf.org>; Fri, 4 Oct 2019 17:11:19 -0700 (PDT)
Received: by mail-wm1-x329.google.com with SMTP id v17so7381420wml.4 for <oauth@ietf.org>; Fri, 04 Oct 2019 17:11:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KAENUjNiwUfTd2wlo+ocVpLLEzQ8MYYpu7moZzXzo4E=; b=nkteiGbuX4GTK7ebMU2eZ4U0uPW20q1aUR429c5za86aTYtzJbzzjHDrsoO8SoOgFF POhEPKwM6UyLJ6QptkvYCwi0k7xTTR+bMjCa/4Uiadf5EGDAjQbp/CTF17sXKpkoj3// Y1Ws4avgBu5SQqquzI1H1VBrlAz4NkT+cApgQ8b5ZegH/p5ck6D5iCue6zf14Tw9nV1d Sh7QQgSbV7yUdHGG2L6S9vi0W/q+ErPaLyQhAUymNyu8Danwwgst/qkyjiwL47SC9BMH 654foiUamGXzXnraQtcVDK5AOG9jdzG9P5l9+NmjhJQmGTrxntIRg1W2KIkMfEgOC2cr TJOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KAENUjNiwUfTd2wlo+ocVpLLEzQ8MYYpu7moZzXzo4E=; b=g18qBl6q2w4dEe4ktoB5Rs7BKhbClv/4jG4pOdro95tN9m4wVOrrFdeEIlEKg4800k ZKA3SRK00bgbJjdbS0GPgaegrVusfXQoHLYLYeXH7G9uECohRds4+vBY8gf/AIw536Fs 76KA6Tkt4gYji5PH8Mc5wjDClFPsYeKyx0Az+gLy5bqtL+kbHUxQsq8KQfthPFyLdZ+9 jaL47yz07iC2Q9cRedKXgrMR802YBbDsxJKuZ/D+jWrQbRgMrigPvEwNbAX5KCxNKFPr oUCR89YOWFlnAAnH8Bi5N443zcuafOPMjzEb3Ktxk6SGjamj3fcxyTrH72243GiXGbQU 7PXQ==
X-Gm-Message-State: APjAAAXvAWWSlreGpeiR9Awnpdsv0+cEQmmNIL6sE5FNwoYh3X+VMM19 5KDgmw+698icSzI95kYR2TWZdZViuDre8qOTUvfCdefLuGE=
X-Google-Smtp-Source: APXvYqxYCkRaz2D+HiAAuViCR1Jv8lcPtSJpHyO3ASGNdPC3bbaPX4t5pNc54oz5zOgsyaznm+Bz84BNu/5Xwcwvhak=
X-Received: by 2002:a7b:cd99:: with SMTP id y25mr12613009wmj.152.1570234277943; Fri, 04 Oct 2019 17:11:17 -0700 (PDT)
MIME-Version: 1.0
References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> <CAGBSGjqdrCOZAu_2VvtjHVD+rBEK+0B86wNjoyXiQKAwS2Q4hA@mail.gmail.com> <BB0AE29D-5CD0-4441-B3B6-FEB6D3F749EE@mit.edu> <CAGBSGjqk_OkiJHGTDaMAymtQHE1UG5PnJsBMv=CkakUoFouqhA@mail.gmail.com> <C72FC218-32E0-481B-92B3-6B3747261295@mit.edu> <CAD9ie-shdFOKNFxRunpvzvE6-MhCtPHRWM=MQ+htBov3-A4Q9A@mail.gmail.com> <CAP-T6TSUfN2daDUQ=dU_9jsMsDU6VcmYyy4WoK=XrhkXF9emVQ@mail.gmail.com> <CAD9ie-v8rtJWBL1de=k4G_NcgCmcVwFwx0fijfVr5bNaCyYX8Q@mail.gmail.com> <48D64799-1A80-40D0-B5A0-D90F9BD42DA5@mit.edu>
In-Reply-To: <48D64799-1A80-40D0-B5A0-D90F9BD42DA5@mit.edu>
From: Takahiko Kawasaki <taka@authlete.com>
Date: Fri, 4 Oct 2019 17:11:06 -0700
Message-ID: <CAHdPCmPt1C3NP7ohE0763knpigJh_Ym9-m9+ZA64dikRrDdo=Q@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000059f35605941ea829"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/RopkepJFs_wnFGZtjrxOr3Km9jc>
Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Oct 2019 00:11:24 -0000

Hi Torsten,

>2.3.1.5.  Request entity too large
>
>   If the request size was beyond the upper bound that the authorization
>   server allows, the authorization server shall return a "413 Request
>   Entity Too Large" HTTP error response.

"413 Request Entity Too Large" should be changed to "413 Payload Too Large".
c.f.
https://bitbucket.org/openid/fapi/issues/256/pushed-request-object-payload-too-large

>   Depending on client type and authentication method, the request might
>   also include the "client_id" parameter.  The "request_uri"
>   authorization request parameter MUST NOT be provided in this case
>   (see Section 3).

How about changing to:

*the request might also include other request parameters such as the
"client_id" parameter, the "client_secret" parameter, the
"client_assertion" parameter, and so on.*

Taka


On Tue, Oct 1, 2019 at 3:36 PM Justin Richer <jricher@mit.edu>; wrote:

> To be clear, PAR is not the same as XYZ. Both are going to be inputs into
> the conversation under txauth, and there are similarities, but they
> shouldn’t be conflated.
>
> In PAR, the result has to be a URI because that’s what JAR defines as the
> input. With XYZ, you get returned two things: a transaction handle and an
> interaction URI. These are both opaque to the client.
>
> — Justin
>
> On Sep 30, 2019, at 8:33 AM, Dick Hardt <dick.hardt@gmail.com>; wrote:
>
> I can understand the request URI being a URI that the client is providing
> the AS, but why would the client's request URI be at the AS?
>
> As Justin has explained it in the past, the AS is returning a handle to
> the transaction. The only party that understands that handle as far as I
> know is the AS. It is meaningless to the client. Perhaps I am missing
> something else?
> ᐧ
>
> On Mon, Sep 30, 2019 at 2:53 AM Dave Tonge <dave.tonge@momentumft.co.uk>;
> wrote:
>
>> So although for this spec, request_uri is just an opaque string, it is
>> defined more generally in
>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-2.2 as an:
>>
>> * Absolute URI from which the Request Object (Section 2.1) can be
>>> obtained*
>>
>>
>> And in section 5.2 as:
>>
>>
>>> *The "request_uri" value MUST be either URN as defined in *
>>> *   RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of RFC7230 *
>>> *   [RFC7230] .  The "request_uri" value MUST be reachable by the **
>>>  Authorization Server.*
>>
>>
>> So this is why in the spec we have example of a URN and we have an
>> ongoing discussion as to whether we should have a standard urn namespace
>> that we recommend implementers use.
>>
>> In the interest of keeping the specs in sync I think it makes sense to
>> keep it a URN for this spec, but with more of an explanation as to why?
>>
>> Dave
>>
>> On Fri, 27 Sep 2019 at 19:22, Dick Hardt <dick.hardt@gmail.com>; wrote:
>>
>>> If I understand the proposal correctly, the request URI is opaque to the
>>> client. Correct?
>>>
>>> If so, why not just treat it as an opaque string?
>>>
>>> If I were implementing the protocol, I would have the blob be a signed
>>> token so that I could verify the integrity before making a database call.
>>> It much easier to throw compute at a DDOS attack to verify a signature,
>>> than DB capacity.
>>>
>>> ᐧ
>>>
>>> On Thu, Sep 26, 2019 at 2:24 PM Justin Richer <jricher@mit.edu>; wrote:
>>>
>>>> Yes, the request object is JWT-based, but the request URI is not. In
>>>> other words, you can post a JWT but what you get back is a URI, not the JWT
>>>> itself.  The request URI was always meant to be a reference, and originally
>>>> it was explicitly a reference to a signed request object.
>>>>
>>>> — Justin
>>>>
>>>> On Sep 26, 2019, at 10:03 AM, Aaron Parecki <aaron@parecki.com>; wrote:
>>>>
>>>> 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.
>>>>
>>>>
>>>> I thought this language was explicitly to allow the use of structured
>>>> values for the request_uri? From the introduction:
>>>>
>>>> but it also allows clients requiring an even
>>>> higher security level, especially cryptographically confirmed non-
>>>> repudiation, to explicitly adopt JWT-based request objects.
>>>>
>>>>
>>>> ----
>>>> Aaron Parecki
>>>> aaronparecki.com
>>>>
>>>> On Thu, Sep 26, 2019 at 6:49 PM Justin Richer <jricher@mit.edu>; wrote:
>>>>
>>>>
>>>> Aaron, some comments inline.
>>>>
>>>> — Justin
>>>>
>>>> On Sep 26, 2019, at 8:30 AM, Aaron Parecki <aaron@parecki.com>; 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
>>>>      [RFC6749].
>>>>
>>>> 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 “urn:fdc:example.com:….”
>>>> Instead (as per https://tools.ietf.org/html/rfc4198).
>>>>
>>>>
>>>> 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
>>>> aaronparecki.com
>>>> @aaronpk
>>>>
>>>> On Sat, Sep 21, 2019 at 1:02 PM Torsten Lodderstedt
>>>> <torsten@lodderstedt.net>; wrote:
>>>>
>>>>
>>>> Hi all,
>>>>
>>>> I just published a new draft that Brian Campbell, Dave Tonge, Filip
>>>> Skokan, Nat Sakimura and I wrote.
>>>>
>>>> https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00
>>>>
>>>> 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: internet-drafts@ietf.org
>>>> Subject: New Version Notification for draft-lodderstedt-oauth-par-00.txt
>>>> Date: 21. September 2019 at 12:47:28 CEST
>>>> To: "Nat Sakimura" <nat@sakimura.org>;, "Brian Campbell" <
>>>> bcampbell@pingidentity.com>;, "Torsten Lodderstedt" <
>>>> torsten@lodderstedt.net>;, "Dave Tonge" <dave@tonge.org>;, "Filip
>>>> Skokan" <panva.ip@gmail.com>;
>>>>
>>>>
>>>> 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:
>>>> https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-par-00.txt
>>>> Status:
>>>> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/
>>>> Htmlized:
>>>> https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00
>>>> <https://tools.ietf..org/html/draft-lodderstedt-oauth-par-00>
>>>> Htmlized:
>>>> https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-par
>>>>
>>>>
>>>> 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 tools.ietf.org.
>>>>
>>>> The IETF Secretariat
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>>
>> --
>>
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>