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 protected]>: > > 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 <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 > > From: [email protected] <mailto:[email protected]> > Sent: March 30, 2017 9:57 PM > To: John Bradley <mailto:[email protected]>; Nat Sakimura > <mailto:[email protected]> > Cc: IETF oauth WG <mailto:[email protected]> > Subject: Re: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt > > +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. > > On Mar 30, 2017 17:33, "Nat Sakimura" <[email protected] > <mailto:[email protected]>> 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 protected] > <mailto:[email protected]>> 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 protected] <mailto:[email protected]>] > Sent: Thursday, March 30, 2017 4:44 PM > To: Mike Jones <[email protected] > <mailto:[email protected]>> > Cc: Nat Sakimura <[email protected] <mailto:[email protected]>>; IETF oauth > WG <[email protected] <mailto:[email protected]>> > 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 protected] > <mailto:[email protected]>> 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 protected] <mailto:[email protected]>] > On Behalf Of John Bradley > Sent: Thursday, March 30, 2017 3:00 PM > To: IETF OAUTH <[email protected] <mailto:[email protected]>> > 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 <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 > > From: [email protected] <mailto:[email protected]> > Sent: March 30, 2017 1:38 PM > To: [email protected] <mailto:[email protected]> > Cc: [email protected] <mailto:[email protected]> > 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 > > 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/ > <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://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> > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-13 > <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 > <http://tools.ietf.org/>. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/> > > _______________________________________________ > OAuth mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
