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

Dick Hardt <dick.hardt@gmail.com> Mon, 30 September 2019 15:33 UTC

Return-Path: <dick.hardt@gmail.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 9E2D0120110 for <oauth@ietfa.amsl.com>; Mon, 30 Sep 2019 08:33:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 l4EhUw1knlKU for <oauth@ietfa.amsl.com>; Mon, 30 Sep 2019 08:33:40 -0700 (PDT)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 777B71200CD for <oauth@ietf.org>; Mon, 30 Sep 2019 08:33:39 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id b20so9974681ljj.5 for <oauth@ietf.org>; Mon, 30 Sep 2019 08:33:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EYHUbroTuW8sd60OKeeHCDRtsKkc5+iaUCWE778YEVM=; b=sHR97k1FVCtpt7d4mdw1qzt2qYGwUHZE/xgyIk+o4v1+4a/MJT9hHSbaIyMay7VWiL XUJb74yhwSt66lHadZo0TxxPrIa32ysNg5C/MNCLDxlX8SHQDzkdM/YRhG8dcUIoaVs6 zOAQHo+Qy8JhPNIZiETy4P38WsGjdLmY0J1M+1G1Ll6H7XgeN5t+vqwf0uE5EW9+7599 MkDDJAcnbX1/MU4DrRfb9Kmsiq4SgK44t8Iujs4dkWO/6I2WZJBTFrLo4c4p+yay0gQ4 4YvtTEbyeuBXbgyp3AxTf9F+OgpY1NKJBCOCQBUWBEJWJp9GM20uU3RG5QV0r8H0Ke3g Y6wA==
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=EYHUbroTuW8sd60OKeeHCDRtsKkc5+iaUCWE778YEVM=; b=G4CEbxl+E+gdoAcQOwNZGK9b3Fp31DbplqAhsjUgNCKcuqPSxGe/w7/xsOaUWjegvt ZdXdwlJpe7aUwszNztcOJGln6pzCebKlKAduDkK30GsC5Zkm7E8tqmEk7Ww5Uu4Kx0RM DVtq3aSFDoUiGfkqvpTSvwH6VF4KQ+9jav46Fq5wx49PWrZT8IEB3pMP4UL9HS9tRFBh QkhZjW1C+eiT72dfp3DW/KPGkIHeoR2aHxQl8i7Gm2aD5WxJqHzChkjkkwlKfNkV/Amn 6FR0FqM0LKXYldy9ItNM0Q1gPCLreUkYigySAq2VwVS5mOtp2xFuaXGg6MbRKMOIuC7L eFNw==
X-Gm-Message-State: APjAAAUCV2Zt069hk7/L70pf1RtImef/3HHqFmlkXQCltsHtMJ324ozt RutoIJBaYgR63B/xSWL6UU4OmM0UDNjmbsRfdAM=
X-Google-Smtp-Source: APXvYqy1VkhVnqLIROLhtp+a9avfsrYpztMR+C3zj02u3Pv4gInuUcQiAxN8M1I/I0ASg24EVvwa4OjrRfBjns/PusM=
X-Received: by 2002:a2e:1614:: with SMTP id w20mr12551762ljd.159.1569857617383; Mon, 30 Sep 2019 08:33:37 -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>
In-Reply-To: <CAP-T6TSUfN2daDUQ=dU_9jsMsDU6VcmYyy4WoK=XrhkXF9emVQ@mail.gmail.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Mon, 30 Sep 2019 08:33:25 -0700
Message-ID: <CAD9ie-v8rtJWBL1de=k4G_NcgCmcVwFwx0fijfVr5bNaCyYX8Q@mail.gmail.com>
To: Dave Tonge <dave.tonge@momentumft.co.uk>
Cc: Justin Richer <jricher@mit.edu>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a1d5890593c6f582"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/u8kgBOcOO_d4NVHjeQhQjCGRvDk>
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: Mon, 30 Sep 2019 15:33:44 -0000

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