I agree with the IESG reasoning that merging is problimatic. Once we allow that given a unknown list of possible paramaters with diffrent security properties it would be quite difficult to specify safely.
Query paramaters can still be sent outside the JAR, but if they are in the OAuth registry the AS MUST ignore them. Puting the iss in the JWE headder addresses the encryption issue without merging. I understand that some existing servers have dependencys on getting the clientID as a query paramater. Is that the only paramater that people have a issue with as oposed to a nice to have? Would allowing the AS to not ignore the clientID as a query paramater as long as it matches the one inside the JAR, basicly the same as Connect request object but for just the one paramater make life easier for the servers? I am not promising a change but gathering info before proposing something. John B. On 1/16/2020 1:53 AM, Benjamin Kaduk wrote: > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
