Hi This version hopefully have addressed all the comments that I received during IESG review. I also added RFC8141 as the reference to URN.
The main difference from -12 that was posted in March are: 1) Now, all the parameters to be used MUST reside within the request object. (It is still possible to be duplicated but they are ignored from the security point of view by the server that supports this spec.) 2) Clarified that when request object is stored by the authorization server, `request_uri` can be a URN. 3) Added text on the security risks of using `request_uri` in the security consideration. Best, Nat Sakimura -- PLEASE READ :This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. > -----Original Message----- > From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] > Sent: Friday, July 21, 2017 10:14 PM > To: Nat Sakimura <n-sakim...@nri.co.jp>; John Bradley > <ve7...@ve7jtb.com> > Subject: New Version Notification for draft-ietf-oauth-jwsreq-15.txt > > > A new version of I-D, draft-ietf-oauth-jwsreq-15.txt has been > successfully submitted by Nat Sakimura and posted to the IETF repository. > > Name: draft-ietf-oauth-jwsreq > Revision: 15 > Title: The OAuth 2.0 Authorization Framework: JWT Secured > Authorization Request (JAR) > Document date: 2017-07-21 > Group: oauth > Pages: 26 > URL: > https://www.ietf.org/internet-drafts/draft-ietf-oauth-jwsreq-15.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ > Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-15 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-15 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-15 > > 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 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. > > > > > 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. > > The IETF Secretariat _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
