+1 Thanks!
Vladimir On 12/03/2020 17:31, Brian Campbell wrote: > +1 (again) that `client_id` should be allowed/required as a query > parameter outside the request object JWT or URI and that its value has > to be the same as within the request object. > > On Thu, Mar 12, 2020 at 8:20 AM Joseph Heenan <jos...@authlete.com > <mailto:jos...@authlete.com>> wrote: > > I agree with that too. > > Joseph > >> On 12 Mar 2020, at 14:18, Mike Jones >> <Michael.Jones=40microsoft....@dmarc.ietf.org >> <mailto:Michael.Jones=40microsoft....@dmarc.ietf.org>> wrote: >> >> I agree that we should restore the client_id functionality. >> Thanks for moving this forward! >> >> -- Mike >> >> *From:* OAuth <oauth-boun...@ietf.org >> <mailto:oauth-boun...@ietf.org>> *On Behalf Of *Nat Sakimura >> *Sent:* Monday, February 24, 2020 6:18 PM >> *To:* John Bradley <ve7...@ve7jtb.com <mailto:ve7...@ve7jtb.com>> >> *Cc:* oauth <oauth@ietf.org <mailto:oauth@ietf.org>> >> *Subject:* Re: [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured >> Authorization Request (JAR) vs OIDC request object >> >> So, where should we take it to? >> Just add back client_id as it used to be? >> >> On Fri, Jan 24, 2020 at 6:55 AM John Bradley <ve7...@ve7jtb.com >> <mailto:ve7...@ve7jtb.com>> wrote: >> >> >> ---------- Forwarded message --------- >> From: *John Bradley* <ve7...@ve7jtb.com >> <mailto:ve7...@ve7jtb.com>> >> Date: Sat, Jan 18, 2020, 9:31 PM >> Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured >> Authorization Request (JAR) vs OIDC request object >> To: Benjamin Kaduk <ka...@mit.edu <mailto:ka...@mit.edu>> >> >> >> >> If you put the iss in the JWE header it is integrity >> protected, as JWE only supports AAD encryption algs. >> >> It is more of a problem when the client is sending a >> requestURI in that case having the clientID in the GET to the >> Authorization endpoint is useful. >> >> I think there is a argument for explicitly allowing the >> clientID as long as it exactly matches the clientID in the JAR. >> >> John B. >> >> On Fri, Jan 17, 2020 at 11:53 PM Benjamin Kaduk >> <ka...@mit.edu <mailto:ka...@mit.edu>> wrote: >> >> On Fri, Jan 17, 2020 at 08:44:18AM -0500, Justin Richer >> wrote: >> > I don’t agree with this stance from a security or >> implementation perspective. >> > >> > If there’s a clear order of precedence for the >> information, it’s not particularly problematic. >> Everything inside the request object is to be taken over >> things outside the request object. We have the exact same >> semantics and process with dynamic registration, where >> the software statement is carried alongside plain JSON >> claims, and the two are mixed with a very simple algorithm: >> > >> > - If a field is inside the signed payload, use that >> value and ignore any copy of it on the outside >> > - If a field is not inside the signed payload and is >> outside the signed payload, use the outside value >> > >> > Can someone please point out a concrete security issue >> with this algorithm? This is the extent of the “merge” >> semantics that we need here, and it would solve not only >> the ability to use this for use cases that call for a >> more static request object (perhaps signed by a third >> party and not the client) along side the plain parameters >> that can vary, but also the backwards compatibility issue >> that’s been discussed. With this algorithm in place, you >> could have OIDC clients actually be compliant with the >> spec, since OIDC requires replication of the values >> inside the request object on the outside with exact >> matches. An OIDC server wouldn’t be fully compliant with >> the new spec since it would reject some compliant JAR >> requests that are missing the external parameters, but >> that’s fairly easy logic to add on the OIDC side. And in >> that case you get a matrix of compatibility like: >> >> I agree that the merge algorithm is simple and fairly >> straightforward to >> implement. But, as Joseph has been alluding, it's only >> simple if you've >> already made the decision to use all the parameters, both >> from inside and >> from outside the signed payload. The security risk lies >> about having to >> make the trust decision twice, more than the mundane >> details of actually >> doing the merge. (Though there is still some latent >> risk, given that we've >> seen some really crazy quality of implementation out there.) >> >> It's certainly *possible* that things end up fine in many >> well-deliniated >> cases where merging can be used. But it's more >> complicated to reason >> about, and I don't remmber seeing much previous >> discussion about the >> specifics of the double trust decision. >> >> -Ben >> >> > >> > JAR Server | OIDC Server | >> > ------------+------------+--------------+ >> > JAR Client | YES | NO | >> > OIDC Client | YES | YES | >> > >> > Breaking one out of the four possible combinations in a >> very predictable way is, I think, the best way to handle >> backwards compatibility here. >> > >> > But between this issue and JAR’s problematic call for >> the value of a request_uri to always be a JWT and be >> fetchable by the AS (neither of which are true in the >> case of PAR) makes me think we need to pull this back and >> rework those things, in a push back to the IESG’s comments. >> > >> > — Justin >> > >> > >> > > On Jan 16, 2020, at 7:38 PM, Joseph Heenan >> <jos...@authlete.com <mailto:jos...@authlete.com>> wrote: >> > > >> > > I agree with this, particularly the security concerns >> of merging. If we merge, we can much guarantee there will >> eventually be a security issue where an attacker is able >> to gain an advantage by adding a parameter to the url >> query (which the server would then happily process if >> that parameter isn’t found inside the request object).. >> Ruling out that case makes security analysis >> (particularly when creating new OAuth2 parameters) >> significantly simpler. >> > > >> > > Putting the iss in the JWE header and having the >> client_id duplicated outside the request object seem to >> address all the concerns I’ve seen raised. >> > > >> > > (It seems like it may be unnecessary to have the >> client_id duplicated outside if the request_uri is a PAR >> one though.) >> > > >> > > Joseph >> > > >> > > >> > > >> > >> On 16 Jan 2020, at 22:40, John Bradley >> <ve7...@ve7jtb.com <mailto: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 >> >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc6749%23section-3.2.1&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986096572&sdata=m6%2BaTTp1bBtLcoJ883HIFFg5OPqcqW9Mo%2B8ennoFgaM%3D&reserved=0>> >> 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 >> >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Foauth%2FlkOhwiDj_hCI55BQRdiR9R0JwgI&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986106566&sdata=lkS8YioL8fTeiuLU%2F2MzebzCB%2FA%2FPPy%2Fl1Wi%2BLFKCFE%3D&reserved=0> >> > >>> 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 >> >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Foauth%2F-tUrNY1X9eI_tQGI8T-IGx4xHy8&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986106566&sdata=QNpyHqv10Dfu9MQzkhVs%2By23ShloRw9GIbn8%2B6pvigo%3D&reserved=0> >> and >> > >> >>> >> https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_UwY >> >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Foauth%2FUke1nxRlgx62EJLevZgpWCz_UwY&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986116568&sdata=JTvXisbbmnXSpNRFJQkEKvO%2BkXiLdtEr%2FoH8obLtlo8%3D&reserved=0> >> and >> > >>> so on. >> > >>> >> > >>> _______________________________________________ >> > >>> OAuth mailing list >> > >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >> > >>> https://www.ietf.org/mailman/listinfo/oauth >> >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986126557&sdata=I5KDQT%2BdT0lapMOr71odsiCRrZ7csVZMuaYnMzsWwhM%3D&reserved=0> >> > >> >> > >> _______________________________________________ >> > >> OAuth mailing list >> > >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> > >> https://www.ietf.org/mailman/listinfo/oauth >> >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986136551&sdata=8nJdrY3H98I39l5KXVkokwGw9sVzQGTJRfoxYwjtLhs%3D&reserved=0> >> > > >> > > _______________________________________________ >> > > OAuth mailing list >> > > OAuth@ietf.org <mailto:OAuth@ietf.org> >> > > https://www.ietf.org/mailman/listinfo/oauth >> >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986136551&sdata=8nJdrY3H98I39l5KXVkokwGw9sVzQGTJRfoxYwjtLhs%3D&reserved=0> >> > >> >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org <mailto:OAuth@ietf.org> >> > https://www.ietf.org/mailman/listinfo/oauth >> >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986146548&sdata=%2B1PGj7U2CLMlh6HWf8BuGIvqtcGkz0hLMJYlktmkLc4%3D&reserved=0> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986156545&sdata=2lgFg7%2F%2BLZ%2FgoabHcpK1ggg1FgNaArMIUKojGxJ%2BdLk%3D&reserved=0> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> >> <https://nam06.safelinks..protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986166540&sdata=Ex9kDYE8r4E0Y2KxMdDpwtZVWdNrq1Uqm6eYFf1LcsI%3D&reserved=0> >> >> >> >> -- >> Nat Sakimura (=nat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> >> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnat.sakimura.org%2F&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986166540&sdata=%2FEt7X7DH8psh0JPtSnZGyk6qtliZUySH4z9%2BbLAEeTs%3D&reserved=0> >> @_nat_en >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto: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 -- Vladimir Dzhuvinov
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
