[OAUTH-WG] FW: New Version Notification for draft-ietf-oauth-jwsreq-15.txt

"Nat Sakimura" <n-sakimura@nri.co.jp> Fri, 21 July 2017 13:25 UTC

Return-Path: <n-sakimura@nri.co.jp>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B8C8812EBF7 for <oauth@ietfa.amsl.com>; Fri, 21 Jul 2017 06:25:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 48AW-8BaO167 for <oauth@ietfa.amsl.com>; Fri, 21 Jul 2017 06:25:50 -0700 (PDT)
Received: from nrifs04.index.or.jp (nrigw01.index.or.jp []) by ietfa.amsl.com (Postfix) with ESMTP id D9B731317D5 for <oauth@ietf.org>; Fri, 21 Jul 2017 06:25:49 -0700 (PDT)
Received: from nrimmfm052.index.or.jp (unknown []) by nrifs04.index.or.jp (Postfix) with ESMTP id 37BDC472EE0 for <oauth@ietf.org>; Fri, 21 Jul 2017 22:25:49 +0900 (JST)
Received: from index.or.jp (unknown []) by nrimmfm052.index.or.jp (Postfix) with ESMTP id 8FD0E4E0046 for <oauth@ietf.org>; Fri, 21 Jul 2017 22:25:48 +0900 (JST)
Received: from nriea04.index.or.jp (localhost.localdomain []) by pps.mf051 ( with SMTP id v6LDPmE0031280 for <oauth@ietf.org>; Fri, 21 Jul 2017 22:25:48 +0900
Received: from nrims00a.nri.co.jp ([]) by nriea04.index.or.jp with ESMTP id v6LDPmcD031279 for <oauth@ietf.org>; Fri, 21 Jul 2017 22:25:48 +0900
Received: from nrims00a.nri.co.jp (localhost.localdomain []) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id v6LDPmVi026179; Fri, 21 Jul 2017 22:25:48 +0900
Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id v6LDPman026178; Fri, 21 Jul 2017 22:25:48 +0900
X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f
Received: from nrizmf15.index.or.jp ([]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id v6LDPmXj026174 for <oauth@ietf.org>; Fri, 21 Jul 2017 22:25:48 +0900
Received: from NatRZ4 (unknown []) by nrivpnfs02.index.or.jp (Postfix) with ESMTP id 983525816A for <oauth@ietf.org>; Fri, 21 Jul 2017 22:25:45 +0900 (JST)
From: "Nat Sakimura" <n-sakimura@nri.co.jp>
To: <oauth@ietf.org>
References: <150064286988.11282.3403961378795912731.idtracker@ietfa.amsl.com>
In-Reply-To: <150064286988.11282.3403961378795912731.idtracker@ietfa.amsl.com>
Date: Fri, 21 Jul 2017 22:25:49 +0900
Message-ID: <01c101d30224$e0519ec0$a0f4dc40$@nri.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
X-MailAdviser: 20141126
Thread-Index: AQKVKIy4ShU2Xp2Er7lXbFHzf0wIqKDZ+F5g
Content-Language: ja
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Boag8LJZl-_sYl7_fkGaMl5qYs4>
Subject: [OAUTH-WG] FW: New Version Notification for draft-ietf-oauth-jwsreq-15.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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, 21 Jul 2017 13:25:52 -0000


This version hopefully have addressed all the comments that I received during IESG review. 
I also added RFC8141 as the reference to URN. 

The main difference from -12 that was posted in March are: 

1) Now, all the parameters to be used MUST reside within the request object. 
   (It is still possible to be duplicated but they are ignored from the security point of view by the server that supports this spec.)
2) Clarified that when request object is stored by the authorization server, `request_uri` can be a URN. 
3) Added text on the security risks of using `request_uri` in the security consideration. 


Nat Sakimura

PLEASE READ :This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender  and delete this e-mail.

> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Friday, July 21, 2017 10:14 PM
> To: Nat Sakimura <n-sakimura@nri.co.jp>jp>; John Bradley 
> <ve7jtb@ve7jtb.com>
> Subject: New Version Notification for draft-ietf-oauth-jwsreq-15.txt
> A new version of I-D, draft-ietf-oauth-jwsreq-15.txt has been 
> successfully submitted by Nat Sakimura and posted to the IETF repository.
> Name:		draft-ietf-oauth-jwsreq
> Revision:	15
> Title:		The OAuth 2.0 Authorization Framework: JWT Secured
> Authorization Request (JAR)
> Document date:	2017-07-21
> Group:		oauth
> Pages:		26
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-oauth-jwsreq-15.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-15
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-15
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-15
> Abstract:
>    The authorization request in OAuth 2.0 described in RFC 6749 utilizes
>    query parameter serialization, which means that Authorization Request
>    parameters are encoded in the URI of the request and sent through
>    user agents such as web browsers.  While it is easy to implement, it
>    means that (a) the communication through the user agents are not
>    integrity protected and thus the parameters can be tainted, and (b)
>    the source of the communication is not authenticated.  Because of
>    these weaknesses, several attacks to the protocol have now been put
>    forward.
>    This document introduces the ability to send request parameters in a
>    JSON Web Token (JWT) instead, which allows the request to be signed
>    with JSON Web Signature (JWS) and encrypted with JSON Web Encryption
>    (JWE) so that the integrity, source authentication and
>    confidentiality property of the Authorization Request is attained.
>    The request can be sent by value or by reference.
> 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