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 >> >> >> >>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
