Re: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt

"" <> Fri, 31 March 2017 02:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9E10D129781 for <>; Thu, 30 Mar 2017 19:57:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.897
X-Spam-Status: No, score=-0.897 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_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, HTML_NONELEMENT_30_40=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Xzj07y_iL8eG for <>; Thu, 30 Mar 2017 19:57:40 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 25EDA129704 for <>; Thu, 30 Mar 2017 19:57:40 -0700 (PDT)
Received: by with SMTP id k6so80568589wre.2 for <>; Thu, 30 Mar 2017 19:57:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=date:subject:message-id:references:from:to:cc:mime-version :content-transfer-encoding; bh=gwrsLsDnuJaOvTGQuho5/I+v0jDXMJkzHB9JI02OZmE=; b=o476jlW4ijcYIKQRNj4k3W36AfuINXMxd3b+12+uiPW2Ps3Gk/5SsDvFZI8ILg0t7A 2JFVfimg2ZDS9pQJ8Wuq5NMB+L0fSYzxrMF7bPRipd9I3rP0BK8VHOXsotg3x3NVk09Y LryGt2H2EuYkpsxKR3oW4/Y7Q7xNkJsX6onNFNVgrOD1QA5i4VQ/d9yZEIRCUEGaeKKk sigCByfMiC8WrpnY8S/3FaFjVl3DLUfl44qidIR7HFUSrrPGobRnol2X6AICbQ3MpnYW 41BgGaFDU7dTJDSsN0hAUT63Ph261PZccmDkNFXFAGanLJs3LUz8o8A3xedWxfXTCwQe bkkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:subject:message-id:references:from:to:cc :mime-version:content-transfer-encoding; bh=gwrsLsDnuJaOvTGQuho5/I+v0jDXMJkzHB9JI02OZmE=; b=YbmshIVwFeapMWS3PX2hjpYdd8uAAEKqvXGACPid4+E3t9x4EpaFUbTx6KQ7FnmR5g wdb0o0KcjAGaxCQLdc8PIOWhKAzbKlCtk4Ma0BYS0XR54lTWlj5ft/tK7boUqkUFMrc4 9K+CkNx/pKnyrbiD+xXNwrFL1PBwSyQWbmXWVha3pAr6RfN5dfWaX3Q+gOUlD+xNU82l LojtkacZpVyEsOwNQ8leztAy4i1d4Ua32yvu3oUgCAfUuUyyYjqvKun5kUx8qRzDNJCN 3Ui8gxgJRHyLeTN9jdoeLumE/WEv8OMlE6tN4FDKSy/JpdYefdxhhlgYzxQv6QPbG1lf zBTg==
X-Gm-Message-State: AFeK/H1wjAd3xDzvU4cusmLZ+RQ3uXkAZ8eIg/adJcoCkKvnuRvRjKzqbE7PA7rxk90VRQ==
X-Received: by with SMTP id w81mr537049wma.113.1490929058574; Thu, 30 Mar 2017 19:57:38 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id r17sm4877075wrc.47.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 19:57:37 -0700 (PDT)
Date: Thu, 30 Mar 2017 21:57:10 -0500
X-Priority: 3
Message-ID: <>
References: <>
From: "" <>
To: John Bradley <>, Nat Sakimura <>
Cc: IETF oauth WG <>
MIME-Version: 1.0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <>
Subject: Re: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 31 Mar 2017 02:57:43 -0000


Sent from my Huawei Mobile

-------- Original Message --------
Subject: Re: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt
From: John Bradley
To: Nat Sakimura
CC: IETF oauth WG

So I think we need to make the must ignore clearer for the additional paramaters on the authorization endpoint.  

On Mar 30, 2017 17:33, "Nat Sakimura" <> wrote:
Not right now.

As of this writing, a client can still send duplicate parameters in the query but they get ignored by the servers honoring OAuth JAR. So, it is backwards compatible with OpenID Connect in that sense (OpenID Connect sends duplicate manatory RFC6749 parameters as the query parameters as well just to be compliant to RFC6749). Conversely, servers that do not support OAuth JAR will ignore request_uri etc.
On Mar 30, 2017, at 4:47 PM, Mike Jones <> wrote:

Is there a clear statement somewhere along the lines of “parameters (other than “request” or “request_uri”) are only allowed to be in the signed object if a signed object is used”?  That’s the kind of thing I was looking for and didn’t find.


                                                       -- Mike

From: John Bradley []
Sent: Thursday, March 30, 2017 4:44 PM
To: Mike Jones <>
Cc: Nat Sakimura <>; IETF oauth WG <>
Subject: RE: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt


The intent of the change is to only allow the paramaters to be in the signed object if a signed object is used.  


This requires State, nonce etc to be in the JWT.  Only one place to check will hopefully reduce implimentation errors.  


This also allows us to remove the caching text as we now have one JWT per request, so caching won't happen.   


John B.  




On Mar 30, 2017 4:36 PM, "Mike Jones" <> wrote:

I *believe* the intent is that *all* parameters must be in the request object, but the spec doesn’t actually say that, as far as I can tell.  Or maybe the intent is that parameters must not be duplicated between the query parameters and the request object.


One or the other of these statements should be explicitly included in the specification.  Of course, I could have missed the statement I’m asking for in my review, in which case please let me know what I missed.



                                                      -- Mike


From: OAuth [] On Behalf Of John Bradley
Sent: Thursday, March 30, 2017 3:00 PM
Subject: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt


Based on feeback from the IESG we have removed some of the optionality in the draft.


It is a shorter read than draft 12.  


John B.


Sent from" target="_blank" rel="nofollow">Mail for Windows 10


Sent: March 30, 2017 1:38 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-13.txt



A New Internet-Draft is available from the on-line Internet-Drafts directories.

This draft is a work item of the Web Authorization Protocol of the IETF.


        Title           : The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)

        Authors         : Nat Sakimura

                          John Bradley

           Filename        : draft-ietf-oauth-jwsreq-13.txt

           Pages           : 27

           Date            : 2017-03-30



   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 signed

   with JSON Web Signature (JWS) and/or 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.



The IETF datatracker status page for this draft is:" target="_blank" rel="nofollow">


There are also htmlized versions available at:" target="_blank" rel="nofollow">" target="_blank" rel="nofollow">


A diff from the previous version is available at:" target="_blank" rel="nofollow">



Please note that it may take a couple of minutes from the time of submission

until the htmlized version and diff are available at" target="_blank" rel="nofollow">


Internet-Drafts are also available by anonymous FTP at:" target="_blank" rel="nofollow">



OAuth mailing list" target="_blank" rel="nofollow">