Last Call: <draft-ietf-oauth-jwsreq-11.txt> (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)) to Proposed Standard

The IESG <> Mon, 30 January 2017 23:11 UTC

Return-Path: <>
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 992CA12967A; Mon, 30 Jan 2017 15:11:21 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <>
To: "IETF-Announce" <>
Subject: Last Call: <draft-ietf-oauth-jwsreq-11.txt> (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)) to Proposed Standard
X-Test-IDTracker: no
X-IETF-IDTracker: 6.41.0
Auto-Submitted: auto-generated
Precedence: bulk
Sender: <>
Message-ID: <>
Date: Mon, 30 Jan 2017 15:11:21 -0800
Archived-At: <>
X-Mailman-Version: 2.1.17
List-Id: "IETF announcement list. No discussions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 30 Jan 2017 23:11:22 -0000

The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document:
- 'The OAuth 2.0 Authorization Framework: JWT Secured Authorization
   Request (JAR)'
  <draft-ietf-oauth-jwsreq-11.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the mailing lists by 2017-02-13. Exceptionally, comments may be
sent to instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.


   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

   This document introduces the ability to send request parameters in a
   JSON Web Token (JWT) instead, which allows the request to be JWS
   signed and/or JWE encrypted so that the integrity, source
   authentication and confidentiality property of the Authorization
   Request is attained.  The request can be sent by value or by

The file can be obtained via

IESG discussion can be tracked via

No IPR declarations have been submitted directly on this I-D.

The document contains these normative downward references.
See RFC 3967 for additional information: 
    rfc6234: US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) (Informational - IETF stream)
    rfc6819: OAuth 2.0 Threat Model and Security Considerations (Informational - IETF stream)
    rfc6973: Privacy Considerations for Internet Protocols (Informational - IAB stream)
Note that some of these references may already be listed in the acceptable Downref Registry.