I'd agree that Vladimir's proposed wording is more meaningful/helpful. On Mon, Apr 20, 2020 at 12:12 AM Vladimir Dzhuvinov <vladi...@connect2id.com> wrote:
> Nat, John, thanks for updating the JAR spec. I just reviewed it, in > particular the authz request and the security considerations sections. > Choosing to make client_id (as top-level parameter) mandatory for all > cases, even for those when it can be readily extracted from the JWT, makes > the job of implementers even easier. > > > I have just one comment about the last paragraph in section 5, assuming > backward compatibility means with RFC6749 requests. Here is my proposed > wording: > > The client MAY send the parameters included in the request object > duplicated in the query parameters. For instance, this can be done > to ensure the minimal required query parameters for an OAuth 2.0 > [RFC6749] authorization request are also present. An authorization > server supporting this specification MUST however only use the > parameters included in the request object. > > > Vladimir > > > On 19/04/2020 21:30, internet-dra...@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol WG 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-21.txt > Pages : 31 > Date : 2020-04-19 > > 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. > > > 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-21https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-21 > > A diff from the previous version is available > at:https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-21 > > > 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 > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
