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

John Bradley <> Fri, 31 March 2017 03:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5266512762F for <>; Thu, 30 Mar 2017 20:40:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pJpzOoRuyWI7 for <>; Thu, 30 Mar 2017 20:40:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 97AF812970F for <>; Thu, 30 Mar 2017 20:40:52 -0700 (PDT)
Received: by with SMTP id y18so5589782itc.1 for <>; Thu, 30 Mar 2017 20:40:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=message-id:mime-version:to:cc:from:subject:date:importance :in-reply-to:references; bh=5PBmwwd8WuEboAMt21iGCD769HpcLAEVOZRIyipzSdY=; b=QH/nIi28FIz4GbOUxewRSWVUJ8duG57HgBia+tUYtw5FPk99lXt79ZA8W3ThZiAucU HghMPq8myCd5NM0tifmA/OHnSXwH0O0SOLST6xx33u2SseriVBdS/TNY8na/RR8b+UHp eUjjx0TxWbNFc4O95J7VOELj/i/2Y4B/aQ4fpq9KjDcqOtS3KIBdX7cdSAiSR5rPlZ3e nkEt4NKMIXV/ozeGKt/g6GkbTNojKpRWTrywDdbHr6AV+ai1Xi8JltUgq1RNoxaAEHhp 8OQRlkvwXwq0ImC5mu6EMstYNtinUEIJ5NgnxnEB9nCyqYP+G67qCPqzUVrBTYQanz7W WGhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:message-id:mime-version:to:cc:from:subject:date :importance:in-reply-to:references; bh=5PBmwwd8WuEboAMt21iGCD769HpcLAEVOZRIyipzSdY=; b=DH8mT5NuQwX0WDQoRGanXSCQ6g8zvH0CG/J4KFjikdW6jIqn3qJmI/OVtVjQ/YkLg6 1q/58tEibZzcicIvevCnUxJAZncRokD0Uw36FUt3yXcGB73sQlj6Hhn5Nv/LTE0FR6wG DTQdHocWZ6JY0eVkkUUUYP76uId7nxW3PKutGQKNWje/JNO6fbpCC/A3tsrEx9tLMLz9 egnjd73QRefiXe0WKhXtsd9+QIm4mOAgVT80ztQ/Uqh96rUnwl9xvH/v3mg3zbTKtFxm i9JGp20J5p73/NFfn1hgPiS20bA6F0Stk0GDubChddZ88SXOk+xrz16U9ZwzR7ZSuxwG 0f6Q==
X-Gm-Message-State: AFeK/H1F2fz0AHNj612/Vc+ih7uNgOZaRYwyeHTTMfKtbau5qKSZd5FjPO8+eTb1WkuqgZdw
X-Received: by with SMTP id q127mr1778389itd.89.1490931651774; Thu, 30 Mar 2017 20:40:51 -0700 (PDT)
Received: from ?IPv6:2001:67c:1233:0:41f9:d4bc:922a:fa31? ([2001:67c:1233:0:41f9:d4bc:922a:fa31]) by with ESMTPSA id i89sm2539703ioo.52.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 20:40:51 -0700 (PDT)
Message-ID: <>
MIME-Version: 1.0
To: "" <>, Nat Sakimura <>
Cc: IETF oauth WG <>
From: John Bradley <>
Date: Thu, 30 Mar 2017 22:40:52 -0500
Importance: normal
X-Priority: 3
In-Reply-To: <>
References: <> <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c08a506817464054bfe934c"
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 03:40:56 -0000

It is a trade off between compatibility with Connect and possible configuration errors.

In reality it may not be compatible with Connect if the client is sending some parameters outside the object without including them in the object as a Connect client might.    You would potentially wind up dropping state or nonce without an error.  

I asked Mike and he was leaning to making it a error to send them as query parameters as that would be a clean change.

I think the choice is a bit of a grey area.

Sent from Mail for Windows 10

Sent: March 30, 2017 9:57 PM
To: John Bradley; Nat Sakimura
Cc: IETF oauth WG
Subject: Re: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt


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 <>rg>; 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 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: 
There are also htmlized versions available at: 
A diff from the previous version is available at: 
Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at 
Internet-Drafts are also available by anonymous FTP at: 
OAuth mailing list