On Wed, Jan 15, 2020 at 11:02:33PM +0200, Vladimir Dzhuvinov wrote: > > On 14/01/2020 19:20, Takahiko Kawasaki wrote: > > Well, embedding a client_id claim in the JWE header in order to > > achieve "request parameters outside the request object should not be > > referred to" is like "putting the cart before the horse". Why do we > > have to avoid using the traditional client_id request parameter so > > stubbornly? > > > > The last paragraph of Section 3.2.1 > > <https://tools.ietf.org/html/rfc6749#section-3.2.1> of RFC 6749 says > > as follows. > > > > /A client MAY use the "client_id" request parameter to identify > > itself when sending requests to the token endpoint. In the > > "authorization_code" "grant_type" request to the token endpoint, > > *an unauthenticated client MUST send its "client_id" to prevent > > itself from inadvertently accepting a code intended for a client > > with a different "client_id".* This protects the client from > > substitution of the authentication code. (It provides no > > additional security for the protected resource.)/ > > > > > > If the same reasoning applies, a client_id must always be sent with > > request / request_uri because client authentication is not performed > > at the authorization endpoint. In other words, */an unauthenticated > > client (every client is unauthenticated at the authorization endpoint) > > MUST send its "client_id" to prevent itself from inadvertently > > accepting a request object for a client with a different "client_id"./* > > > Identifying the client in JAR request_uri requests can be really useful > so that an AS which requires request_uri registration to prevent DDoS > attacks and other checks can do those without having to index all > request_uris individually. I mentioned this before. > > I really wonder what the reasoning of the IESG reviewers was to insist > on no params outside the JAR JWT / request_uri. > > I'm beginning to realise this step of the review process isn't > particularly transparent to WG members.
Could you expand on that a bit more? My understanding is that the IESG ballot mail gets copied to the WG precisely so that there is transparency, e.g., the thread starting at https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdiR9R0JwgI Which admittely is from almost three years ago, but that's the earliest that I found that could be seen as the source of this behavior. -Ben P.S. some other discussion at https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-IGx4xHy8 and https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_UwY and so on. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
