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