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

From: [email-masked]
Date: Thu, 30 Mar 2017 11:38:30 -0700

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

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/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:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-13
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-13

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: John Bradley <[email-masked]>
Date: Thu, 30 Mar 2017 15:00:11 -0500

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

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

Abstract:

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Mike Jones <[email-masked]>
Date: Thu, 30 Mar 2017 21:36:14 +0000

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.

                                                       Thanks,
                                                      -- Mike

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

John B.

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: [email-masked]<mailto:[email-masked]>
Sent: March 30, 2017 1:38 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-13.txt

Abstract:

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Thu, 30 Mar 2017 16:44:12 -0500

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" <[email-masked]> 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.
>
>
>
>                                                        Thanks,
>
>                                                       -- Mike
>
>
>
> *From:* OAuth [mailto:[email-masked]] *On Behalf Of *John Bradley
> *Sent:* Thursday, March 30, 2017 3:00 PM
> *To:* IETF OAUTH <[email-masked]>
> *Subject:* [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: [email-masked]
> *Sent: *March 30, 2017 1:38 PM
> *To: [email-masked]
> *Cc: [email-masked]
> *Subject: *[OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-13.txt
>
>
>
>
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 30 Mar 2017 21:47:36 +0000

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 [mailto:[email-masked]]
Sent: Thursday, March 30, 2017 4:44 PM
To: Mike Jones <[email-masked]>
Cc: Nat Sakimura <[email-masked]>; IETF oauth WG <[email-masked]>
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" <[email-masked]<mailto:[email-masked]>> 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.

                                                       Thanks,
                                                      -- Mike

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

John B.

Abstract:

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<http://tools.ietf.org>.

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 30 Mar 2017 17:33:07 -0500

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, 4:47 PM, at 4:47 PM, Mike Jones <[email-masked]> 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
>This requires State, nonce etc to be in the JWT.  Only one place to
>check will hopefully reduce implimentation errors.
>
>On Mar 30, 2017 4:36 PM, "Mike Jones"
><[email-masked]<mailto:[email-masked]>>
>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.
>
>                                                       Thanks,
>                                                      -- Mike
>
>From: OAuth
>[mailto:[email-masked]<mailto:[email-masked]>] On
>Behalf Of John Bradley

---

From: John Bradley <[email-masked]>
Date: Thu, 30 Mar 2017 19:05:12 -0500

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" <[email-masked]> 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 <[email-masked]>
> wrote:
>>
>> *From:* John Bradley [mailto:[email-masked]]
>> *Sent:* Thursday, March 30, 2017 4:44 PM
>> *To:* Mike Jones <[email-masked]>
>> *Cc:* Nat Sakimura <[email-masked]>; IETF oauth WG <[email-masked]>
>> *Subject:* RE: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt
>>
>>
>>

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 30 Mar 2017 21:57:10 -0500

+1

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.

Not right now.

On Mar 30, 2017, at 4:47 PM, Mike Jones <[email-masked]> wrote:

-- Mike

John B.

Thanks,

-- Mike

John B.

Authors         : Nat Sakimura

John Bradley

Pages           : 27

Date            : 2017-03-30

Abstract:

forward.

OAuth mailing list

[email-masked]

---

From: John Bradley <[email-masked]>
Date: Thu, 30 Mar 2017 22:40:52 -0500

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.

From: [email-masked]
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

+1

-------- Original Message --------

  
                                                       -- Mike 

  
  
John B.   

  
  
                                                       Thanks, 
                                                      -- Mike 

  
  
John B. 

  
  
Abstract:

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 30 Mar 2017 23:01:08 -0500

I had assumed using the request object is mutual exclusive to use of URI query parameters. Did I misinterpret the draft?

> Am 30.03.2017 um 22:40 schrieb John Bradley <[email-masked]>:
> 
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
>  
> From: [email-masked] <mailto:[email-masked]>
> To: John Bradley <mailto:[email-masked]>; Nat Sakimura <mailto:[email-masked]>
> Cc: IETF oauth WG <mailto:[email-masked]>
> On Mar 30, 2017 17:33, "Nat Sakimura" <[email-masked] <mailto:[email-masked]>> wrote:
> Not right now.
> 
> On Mar 30, 2017, at 4:47 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>  <>From: John Bradley [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Mike Jones <[email-masked] <mailto:[email-masked]>>
> Cc: Nat Sakimura <[email-masked] <mailto:[email-masked]>>; IETF oauth WG <[email-masked] <mailto:[email-masked]>>
> On Mar 30, 2017 4:36 PM, "Mike Jones" <[email-masked] <mailto:[email-masked]>> wrote:
>   <>
> From: OAuth [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of John Bradley
> To: IETF OAUTH <[email-masked] <mailto:[email-masked]>>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
>   
> From: [email-masked] <mailto:[email-masked]>
> To: [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ <https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/>
>   
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-13 <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-13>
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-13 <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-13>
>   
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-13 <https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-13>
>   
>   
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>   
> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>   
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>   
>

---

From: John Bradley <[email-masked]>
Date: Thu, 30 Mar 2017 23:14:31 -0500

They are mutually exclusive.

However there are two options as to how the authorization endpoint would treat extra query parameters like state if they are sent.

The current text causes the AS to ignore them and not return a error.  This would be more backwards compatible with the request object in OpenID Connect, however in reality it may cause connect clients to send parameters as query parameters  that would be processed by a connect server that would be ignored by a OAuth server without any obvious error.  There may however be subtle errors downstream from missing parameters.

The other option is to have a cleaner breaking change from Connect and have the Authorization endpoint return a error if anything other than the two new parameters are sent to the authorization endpoint.

I am leaning towards the latter as it is easier to debug,  and wont allow incompatible Connect requests to be accepted without a error.   We would have done this in Connect but couldn’t drop required parameters from OAuth in a Connect spec.

The downside for the latter is that the client would need to know if the AS is supporting The Connect version or the OAuth version.

One of the typical conundrums around how to deal with doing the best going forward thing vs not blowing up older implementations.

In the current proposal a client could put the required parameters both places and the same request would work on servers supporting both the Connect and OAuth versions.

John B.

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

 

 
 
From: [email-masked]
 
+1

-------- Original Message --------

  
                                                       -- Mike 

  
  
John B.   

  
  
                                                       Thanks, 
                                                      -- Mike 

  
  
John B. 

  
  
Abstract:

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 31 Mar 2017 10:40:47 +0100

Hi John

I see a line in our implementation checking that if a response_type is 
also available as a query parameter then it must match the request claim 
value.
Would it make sense to require checking all the well-known query 
parameters and if they exist - enforcing they must also be available in 
the request object ?

Sergey
On 31/03/17 05:14, John Bradley wrote:
> However there are two options as to how the authorization endpoint would
> treat extra query parameters like state if they are sent.
>
>
>
> The current text causes the AS to ignore them and not return a error.
>  This would be more backwards compatible with the request object in
> OpenID Connect, however in reality it may cause connect clients to send
> parameters as query parameters  that would be processed by a connect
> server that would be ignored by a OAuth server without any obvious
> error.  There may however be subtle errors downstream from missing
> parameters.
>
>
>
> The other option is to have a cleaner breaking change from Connect and
> have the Authorization endpoint return a error if anything other than
> the two new parameters are sent to the authorization endpoint.
>
>
>
> I am leaning towards the latter as it is easier to debug,  and wont
> allow incompatible Connect requests to be accepted without a error.   We
> would have done this in Connect but couldn’t drop required parameters
> from OAuth in a Connect spec.
>
>
>
> The downside for the latter is that the client would need to know if the
> AS is supporting The Connect version or the OAuth version.
>
>
>
> One of the typical conundrums around how to deal with doing the best
> going forward thing vs not blowing up older implementations.
>
>
>
> In the current proposal a client could put the required parameters both
> places and the same request would work on servers supporting both the
> Connect and OAuth versions.
>
>
>
> John B.
>
> *From: *Torsten Lodderstedt <mailto:[email-masked]>
> *Sent: *March 30, 2017 11:01 PM
> *To: *John Bradley <mailto:[email-masked]>
> *Cc: *Nat Sakimura <mailto:[email-masked]>; Nat Sakimura
> <mailto:[email-masked]>; IETF oauth WG <mailto:[email-masked]>
> *Subject: *Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-13.txt
>
>
>
> I had assumed using the request object is mutual exclusive to use of URI
> query parameters. Did I misinterpret the draft?
>
>
>
>     Am 30.03.2017 um 22:40 schrieb John Bradley <[email-masked]
>     <mailto:[email-masked]>>:
>
>
>
>     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.
>
>
>
>     *From: [email-masked] <mailto:[email-masked]>
>     *Sent: *March 30, 2017 9:57 PM
>     *To: *John Bradley <mailto:[email-masked]>; Nat Sakimura
>     <mailto:[email-masked]>
>     *Cc: *IETF oauth WG <mailto:[email-masked]>
>     *Subject: *Re: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt
>
>
>
>     +1
>
>         So I think we need to make the must ignore clearer for the
>         additional paramaters on the authorization endpoint.
>
>
>
>             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
>             <[email-masked]
>             <mailto:[email-masked]>> 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 [mailto:[email-masked]
>                 <mailto:[email-masked]>]
>                 *To:* Mike Jones <[email-masked]
>                 <mailto:[email-masked]>>
>                 *Cc:* Nat Sakimura <[email-masked]
>                 <mailto:[email-masked]>>; IETF oauth WG
>                 <[email-masked] <mailto:[email-masked]>>
>                 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.
>
>
>
>
>
>
>
>                 <[email-masked]
>                 <mailto:[email-masked]>> 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
>                     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.
>
>
>
>
>                     Thanks,
>
>
>                                                -- Mike
>
>
>
>                     *From:* OAuth [mailto:[email-masked]
>                     <mailto:[email-masked]>] *On Behalf Of *John
>                     Bradley
>                     *To:* IETF OAUTH <[email-masked]
>                     <mailto:[email-masked]>>
>                     Sent from Mail
>                     <https://go.microsoft.com/fwlink/?LinkId=550986> for
>                     Windows 10
>
>
>
>                     <mailto:[email-masked]>
>                     <mailto:[email-masked]>
>                     *Cc: [email-masked] <mailto:[email-masked]>
>                             Title           : The OAuth 2.0
>                     Authorization Framework: JWT Secured Authorization
>                     Request (JAR)
>
>                             Authors         : Nat Sakimura
>
>                                               John Bradley
>
>                                Filename        :

---

From: Brian Campbell <[email-masked]>
Date: Fri, 31 Mar 2017 08:36:09 -0500

"The current text causes the AS to ignore them and not return a error. " -
except that I don't believe the current text actually specifies that
anywhere. And I think that the intent of Mike's original comment was that
-13 doesn't specify the behavior but that it needs to be revised to do so.

I'd suggest that the doc say that the client must include in the request
object (request or request_uri) all the oauth parameters that it sends. And
when request or request_uri is sent, that the AS must/should only rely on
parameter values from the request object.

I think being semi or somewhat compatible or tolerant of the Connect
variation or request/request_uri is good because it uses the same parameter
names, the same endpoint, and the same metadata names.

On Thu, Mar 30, 2017 at 11:14 PM, John Bradley <[email-masked]> wrote:

> This would be more backwards compatible with the request object in OpenID
> Connect, however in reality it may cause connect clients to send parameters
> as query parameters  that would be processed by a connect server that would
> be ignored by a OAuth server without any obvious error.  There may however
> be subtle errors downstream from missing parameters.
>
>
>
> have the Authorization endpoint return a error if anything other than the
> two new parameters are sent to the authorization endpoint.
>
>
>
> I am leaning towards the latter as it is easier to debug,  and wont allow
> incompatible Connect requests to be accepted without a error.   We would
> have done this in Connect but couldn’t drop required parameters from OAuth
> in a Connect spec.
>
>
>
> One of the typical conundrums around how to deal with doing the best going
> forward thing vs not blowing up older implementations.
>
>
>
> *From: *Torsten Lodderstedt <[email-masked]>
> *To: *John Bradley <[email-masked]>
> *Cc: *Nat Sakimura <[email-masked]>; Nat Sakimura <[email-masked]>; IETF
> oauth WG <[email-masked]>
> 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.
>
>
>
> *From: [email-masked]
> *To: *John Bradley <[email-masked]>; Nat Sakimura <[email-masked]>
> *Cc: *IETF oauth WG <[email-masked]>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 31 Mar 2017 08:37:56 -0500

BTW, the intro still has text about 'dynamic parameters such as "state"'
that need to be cleaned up.
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-13#section-1

On Fri, Mar 31, 2017 at 8:36 AM, Brian Campbell <[email-masked]>
wrote:

>> *Cc: *Nat Sakimura <[email-masked]>; Nat Sakimura <[email-masked]>;
>> IETF oauth WG <[email-masked]>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 31 Mar 2017 08:39:34 -0500

and a typo - "If thie location is" should say "If this location is"

On Fri, Mar 31, 2017 at 8:37 AM, Brian Campbell <[email-masked]>
wrote:

> that need to be cleaned up.  https://tools.ietf.org/html/
> draft-ietf-oauth-jwsreq-13#section-1
>
> On Fri, Mar 31, 2017 at 8:36 AM, Brian Campbell <
> [email-masked]> wrote:
>
>> "The current text causes the AS to ignore them and not return a error. "
>> - except that I don't believe the current text actually specifies that
>>> would have done this in Connect but couldn’t drop required parameters from
>>> OAuth in a Connect spec.
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>>                                                        Thanks,
>>>
>>>                                                       -- Mike
>>>
>>>
>>>