I'd support this (client_id being the only additional query parameter allowed/required) as well.
FWIW, our AS implementations looks for and requires that the response_type and client_id parameters be present as regular request parameters. This was done largely to maintain some semblance of compatibility/compliance to Connect. But client_id is the only one that's helpful. I also agree with the IESG and others that merging is problematic. I've personally never believed there was enough real world utility in the merge approach to justify the added complexity in policy and implementation and/or reduced security as a result. On Thu, Jan 16, 2020 at 7:01 AM Neil Madden <neil.mad...@forgerock.com> wrote: > 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 > -- _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
