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

Dave Tonge <dave.tonge@momentumft.co.uk> Mon, 30 September 2019 09:53 UTC

Return-Path: <dave.tonge@moneyhub.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 6B7A112013F for <oauth@ietfa.amsl.com>; Mon, 30 Sep 2019 02:53:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.737
X-Spam-Level:
X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk
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 HMGylUVu3ywC for <oauth@ietfa.amsl.com>; Mon, 30 Sep 2019 02:53:09 -0700 (PDT)
Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) (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 E50B6120802 for <oauth@ietf.org>; Mon, 30 Sep 2019 02:53:08 -0700 (PDT)
Received: by mail-oi1-x242.google.com with SMTP id m16so10562223oic.5 for <oauth@ietf.org>; Mon, 30 Sep 2019 02:53:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xrQKOKfJWjSrkdl9iQsZ/CMSpjk5YpqEK02cW12tJxQ=; b=UufTubWgudMWNd5W7fmj7y8VJJEBkZsltLlsVhvOhaurWzAkoLZszML/NumKTKzUPE Lxxcim7+JYhZBH/dY3KPkCVrr22tgzGTHFG2pf0va8IXpDhbXwtfenIYu5LD4G3AxDiJ 5aZX3O90LEGYrRzBYID/Q8mjmR1Cwc1ae8B+U=
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=xrQKOKfJWjSrkdl9iQsZ/CMSpjk5YpqEK02cW12tJxQ=; b=kG0dVS9BcTKif9OmL4GxVtN+gnkWkwgOCb3ce3fnTDhPXIm7a10UQacgmTGsAk4aOd qa2TYUS/D6N+KC42M2ugy9GlPE5H/MM2IE6gUxS9kJsKCMc1Uly88W4I/gs8ZFR760P5 UZY78Gm+siHE27cEKRFKa08/bv+UoOqC7ycg3Nd1c0Er6r0j4ZFm+Afe9lURDvy42+1d 5fhTiunFgCFxvtYQMixvmGEx6yRFeIzX7TaOzj5lrsNz0OifN9moK3ce7iXkr+bcIBu+ O7mFAioq+jooCSbQWbHn3DL8k5k+B0+NWFRO/OY7B9dW/oC2zPJaYjNw2H8zgRiv/YZ5 ar/w==
X-Gm-Message-State: APjAAAU4TzNd2vQh52feCGIDLf01nqHJyhHvo4PbXMWJd9ZAgXnIBPmB Chj+mzjJTsX6xaI2BQW0GH/CKVUFCEj9jy99G1QhAw==
X-Google-Smtp-Source: APXvYqw2n9+CwmCHg417LrsCHOf7oOlsRyIlN4oJq6qQ1YqrAiYgMez5EHEgdq4uRRKzZKKsgSClIGTbdS+l6xnR4oI=
X-Received: by 2002:aca:c7d8:: with SMTP id x207mr17830799oif.99.1569837188179; Mon, 30 Sep 2019 02:53:08 -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>
In-Reply-To: <CAD9ie-shdFOKNFxRunpvzvE6-MhCtPHRWM=MQ+htBov3-A4Q9A@mail.gmail.com>
From: Dave Tonge <dave.tonge@momentumft.co.uk>
Date: Mon, 30 Sep 2019 11:52:56 +0200
Message-ID: <CAP-T6TSUfN2daDUQ=dU_9jsMsDU6VcmYyy4WoK=XrhkXF9emVQ@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f510040593c233d6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ZP2oI4lDgjM7hsf1R3KISfe-dGU>
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 09:53:11 -0000

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
>


--