and a typo - "If thie location is" should say "If this location is"
On Fri, Mar 31, 2017 at 8:37 AM, Brian Campbell <bcampb...@pingidentity.com> wrote: > 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 < > bcampb...@pingidentity.com> 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 >> 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 <ve7...@ve7jtb.com> wrote: >> >>> 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. >>> >>> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for >>> Windows 10 >>> >>> >>> >>> *From: *Torsten Lodderstedt <tors...@lodderstedt.net> >>> *Sent: *March 30, 2017 11:01 PM >>> *To: *John Bradley <ve7...@ve7jtb.com> >>> *Cc: *Nat Sakimura <sakim...@gmail.com>; Nat Sakimura <n...@sakimura.org>; >>> IETF oauth WG <oauth@ietf.org> >>> *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 <ve7...@ve7jtb.com>: >>> >>> >>> >>> 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: *sakim...@gmail.com >>> *Sent: *March 30, 2017 9:57 PM >>> *To: *John Bradley <ve7...@ve7jtb.com>; Nat Sakimura <n...@sakimura.org> >>> *Cc: *IETF oauth WG <oauth@ietf.org> >>> *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" <n...@sakimura.org> 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 <michael.jo...@microsoft.com> >>> 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:ve7...@ve7jtb.com] >>> *Sent:* Thursday, March 30, 2017 4:44 PM >>> *To:* Mike Jones <michael.jo...@microsoft.com> >>> *Cc:* Nat Sakimura <n...@sakimura.org>; IETF oauth WG <oauth@ietf.org> >>> *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" <michael.jo...@microsoft.com> >>> 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:oauth-boun...@ietf.org] *On Behalf Of *John >>> Bradley >>> *Sent:* Thursday, March 30, 2017 3:00 PM >>> *To:* IETF OAUTH <oauth@ietf.org> >>> *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: *internet-dra...@ietf.org >>> *Sent: *March 30, 2017 1:38 PM >>> *To: *i-d-annou...@ietf.org >>> *Cc: *oauth@ietf.org >>> *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/ >>> >>> >>> >>> 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/ >>> >>> >>> >>> _______________________________________________ >>> >>> OAuth mailing list >>> >>> OAuth@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
