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

Dick Hardt <dick.hardt@gmail.com> Fri, 27 September 2019 17:22 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 1C00E1209FD for <oauth@ietfa.amsl.com>; Fri, 27 Sep 2019 10:22:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 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, URIBL_BLOCKED=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 u-4mfBxsAG22 for <oauth@ietfa.amsl.com>; Fri, 27 Sep 2019 10:22:16 -0700 (PDT)
Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450: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 0977D120019 for <oauth@ietf.org>; Fri, 27 Sep 2019 10:22:16 -0700 (PDT)
Received: by mail-lj1-x242.google.com with SMTP id 7so3253066ljw.7 for <oauth@ietf.org>; Fri, 27 Sep 2019 10:22:15 -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=a+Gfqlro4NJqzoZ8NZASq7wD81B6+gyOrM7ip9+DDL0=; b=I8rLLHVyaw4CT0g7Qkmk9FEKO+WyJC9MIKUSNWmJBivACq02DyGy2udNxIwOJS2c6k NNldsG7e9PKNyaP7kn+DmulVtn985wUSupZn68FmAaszt8xR0adEhIX/3noGCwhsjIgG zOX1SILhmw5ZCmzo0iSOAA5lHZISter6B14qUYUqUnCFk57OWo3KvmgyWPbCEsB1urc+ 9ZsfkpsyAbKzZP+8dy0vu7c1DK4QsWwBVSpqmfvKayqrCet/np6S2ZR4AbGpqgr0ZpI0 BQlBlnrLymtRTsdAepcckaXMfyPg9bXcBckiF/VslfSFplVlHe8mM6Bf8dD83W14cLBg wXzw==
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=a+Gfqlro4NJqzoZ8NZASq7wD81B6+gyOrM7ip9+DDL0=; b=YT3AqgtZWi5xExcQ8dxs2rT9cyPE+sMdBrRhR6i3Q3IcrZfa9I5UMVCwsORfg9pU5/ QJ1gYltIFnH1kHTO1wyAgDX7lDWetKTC52wZ1RkbZm/quTrhaPuBMOODZogkIcoODShb jz2OakG0m4ffPEA7mqx5Z7IQLlsK0JdlwzeMyPdVPpPvWZvVsemLa1BfTUxfgEO9Alyl p4CQABcwUIy/i/QRQc/atiO6hEU0XE8dR+ky5Z9yqqOCfbzkkcaGYpKol/mC41p9dr6K VO69+QMkSJieEMPf8J3XYbWXRPXxBO5fVLab5skkxTTmTTvFLElae12icpTs/ShR8rEZ 51Pg==
X-Gm-Message-State: APjAAAXw2azqmyrB3T0Vq7p67tV1p4WlaQcJosEitnONw9rbgp3cqGG5 QSnNdSQq6pUra3C6bgrDTVldY7+HjZBrYrFa50g=
X-Google-Smtp-Source: APXvYqzM5MwSjikWbBl/0hv2HWSA6DvSCzYoRtZQ8uyuDsRIdm1btyc7iMvnKYfqCPsiZqpiE2Ex6JxINlwmxOCe/U0=
X-Received: by 2002:a2e:7212:: with SMTP id n18mr3645914ljc.91.1569604934110; Fri, 27 Sep 2019 10:22:14 -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>
In-Reply-To: <C72FC218-32E0-481B-92B3-6B3747261295@mit.edu>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Fri, 27 Sep 2019 10:22:02 -0700
Message-ID: <CAD9ie-shdFOKNFxRunpvzvE6-MhCtPHRWM=MQ+htBov3-A4Q9A@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Aaron Parecki <aaron@parecki.com>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000089130105938c2034"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/U-Dn7IYhj2pYhLK2_qCCh5JI8Ds>
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: Fri, 27 Sep 2019 17:22:20 -0000

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