[OAUTH-WG] Review of draft-ietf-oauth-jwsreq-06

Hannes Tschofenig <hannes.tschofenig@gmx.net> Mon, 02 November 2015 12:06 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 328921A6F2F for <oauth@ietfa.amsl.com>; Mon, 2 Nov 2015 04:06:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id E7vxDMf2C1LP for <oauth@ietfa.amsl.com>; Mon, 2 Nov 2015 04:06:31 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 940E61A6F32 for <oauth@ietf.org>; Mon, 2 Nov 2015 04:06:30 -0800 (PST)
Received: from [] ([]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MQzUc-1a2YKz2QL0-00UKAM for <oauth@ietf.org>; Mon, 02 Nov 2015 13:06:28 +0100
To: "oauth@ietf.org" <oauth@ietf.org>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
X-Enigmail-Draft-Status: N1110
Message-ID: <563751BF.4080808@gmx.net>
Date: Mon, 02 Nov 2015 13:06:23 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="o0SqX1lBhwjmrfbALDDesobrpTw5m0FK0"
X-Provags-ID: V03:K0:PHYY2QgD44fxdIMAa4vwR2oFeabPhdpnRl09k8JGP8paUiWR9HY vypKsSaq9WmCdDhoFJJNP6EeQq4KS5tEOJCllsfbc2n4uctLdhyMp4ngt23BsbljTjOplVG nt2Dt/EpD0p3l0LQPDOxkcN1l6yupD6FuXE/KqjGMGwZ1RPrrxkFUzUt2XRn5/TtAKFFuFt et4ctN4TL0AEkXssTuDUA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:WcVPCftTipA=:/OrgMd8BjUdBGH51Ll6RgK lp/mCKghNeC5jVj8TNE9x8IHoZhG9iFGC4pKkM24a+euBFW8jKgw38iK7oKxtCIjTKkN3Aqmt 4XmXqJMwgeFDxIeMvspBbhfKWvxTA/3vtXoGDQCLLRkzdMi3gRfZ1MGA+KVKdflpuZhxe5w8J jBBMDpalaf5B9CCoDMsS1Mt1IKVRaVSjF8uk23QbryHEDuUgPSiIDeoQ0P3cvXxL3Pe4oVkqC BCJXTgdSPqWMvhBI1z8WS6O4jOiyX5zKsdSeVZ/H9k1TmBXxY6+o2m7932hbgvjt6H5ZfnTV2 PRoJ+Tob0MlSzOsAsCoek9Hr4NCTuNNBgoAcZuOhp0QNJUMd87NqVKo3EGnXgbqe9/gIUDY2g qIXt7waJ0DNu2vw4zppKaOsgOYLw9Eumg92BCnZUre7dWJnvRRMCPA7QTGZ3y6Zg1TLGv7VLt A2kEIuFVHne1n65wWEIL79l6jg0SNjIHm0aZNwtceAvph9FRizPOgrtNH0vxlPRJiCzvclBJ/ lFX7/5a6NZBfwLBFJCSytJjbQtp+k2iDyUrDmegSRGTkbdzPSoGBTVaQokuwdkrtVcFOHVqfB ke3ZC/tsg+1OvKyLwiN6HSrNf2JhIzRQkzYLMurZ/yVpgToApk5Td6qmjJh4dvcZgn8X0jFJa SwXRlRz8zT4I5jJvvlK0YewR94fU6gHyHTPhKZAPJH99rs9L+JODNNUARj6KB96w8N0XPsSGz SWDWbvMFkynImAem6nf+pwF5nhXr+F+MCf2SN434rgCG9P+f5dOm8DmFuKs=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/HBmhdFJsv9b8TxmA2WFNaUFDF4s>
Subject: [OAUTH-WG] Review of draft-ietf-oauth-jwsreq-06
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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, 02 Nov 2015 12:06:34 -0000

Hi Nat, Hi John,

thanks for the work on this document. I have started my review and
wanted to post a few thoughts about the abstract and the introduction.

I have some wording suggestions for the abstract. Here is the current

   The authorization request in RFC6749 utilizes query parameter
   serialization.  This specification defines the authorization request
   using JWT serialization.  The request is sent by value through
   "request" parameter or by reference through "request_uri" parameter
   that points to the JWT, allowing the request to be optionally signed
   and encrypted.

Here is my new proposal:

The authorization request in OAuth 2.0 utilizes query parameter
serialization, which means that parameters are encoded in the URI of the
request. This document introduces the ability to send
request parameters in form of a JSON Web Token (JWT) instead, which
allows the request to be signed and encrypted. The request is sent by
value or by reference.

We call the 'JWT Authorization Request' extension JAR.

1. Introduction

I would expect the following structure of this section.

 a) A description on how things are done today. Here is a proposal:

The OAuth 2.0 specification [RFC 6749] defines the encoding of requests
and responses and in case of the authorization request query parameter
serialization has been chosen. For example, the parameters
'response_type', 'client_id', 'state', and 'redirect_uri' are encoded in
the URI of the request:

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

 b) Why are we making changes / additions? What is wrong with the
current way of doing things?

Here is a proposal:
The encoding in the URI does not allow application layer security with
confidentiality and integrity protection to be used. While TLS is used
to offer communication security between the client and the resource
server, TLS sessions are often terminated prematurely at some middlebox
(such as a load balancer). The use of application layer security
additionally allows requests to be prepared by a third party so that a
client application cannot request more permissions than previously
agreed. This offers an additional degree of privacy protection.

The request by reference allows to reduce the over-the-wire overhead.

 c)  What is the solution (at a high level) described in the document?

   The parameters "request" and "request_uri" are introduced as
   additional authorization request parameters for the OAuth 2.0
   [RFC6749] flows.  The "request" parameter is a JSON Web Token (JWT)
   [RFC7519] whose JWT Claims Set holds the JSON encoded OAuth 2.0
   authorization request parameters.  The JWT [RFC7519] can be passed to
   the authorization endpoint by reference, in which case the parameter
   "request_uri" is used instead of the "request".

You may want to explain why you have chosen the JWT format rather than
something else, such as the CBOR format.

I have a few comments regarding the benefits of the <request by
reference>. You write:

   There are a few cases that request by reference are useful such as:

   1.  When it is detected that the User Agent does not support long
       URLs: Some extensions may extend the URL.  For example, the
       client might want to send a public key with the request.

[Hannes] I believe what you are trying to say in this section is that
the use of the reference reduces the size of the transmitted request
since the use of application layer security, and public
key cryptography in particular, substantially increases the size.

   2.  Static signature: The client can make a signed Request Object and
       put it at a place that the Authorization Server can access.  This
       may just be done by a client utility or other process, so that
       the private key does not have to reside on the client,
       simplifying programming.

[Hannes] The downside of this approach is that it is vulnerable to reply
protection and the signature only becomes a token. Another downside is
that the developer(?) has to place the JWT at
some server first.

   3.  When the server wants the requests to be cacheable: The
       request_uri may include a SHA-256 hash of the file, as defined in
       FIPS180-2 [FIPS180-2], the server knows if the file has changed
       without fetching it, so it does not have to re-fetch a same file,
       which is a win as well.

[Hannes] I believe that this is a by-product of item #2. I am not sure
what the hash of the file means here.

   4.  When the client wants to simplify the implementation without
       compromising the security.  If the request parameters go through
       the browser, they may be tampered in the browser even if TLS was
       used.  This implies we need to have signature on the request as
       well.  However, if HTTPS "request_uri" was used, it is not going
       to be tampered, thus we now do not have to sign the request.
       This simplifies the implementation.

[Hannes] Could you  explain this threat a bit more? Is this aspect
related to some prior OAuth work, such as PKCE?