I believe just client_id would be sufficient for us, so I'd support a compromise position in which that is the only additional query parameter allowed.
-- Neil > On 16 Jan 2020, at 13:40, John Bradley <ve7...@ve7jtb.com> wrote: > > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
