So, I am getting overwhelming approval on getting client_id back. In the next few days, I will create another draft that has it back.
Best, Nat Sakimura On Fri, Mar 13, 2020 at 1:25 AM George Fletcher <gffletch= 40aol....@dmarc.ietf.org> wrote: > I'm a +1 for adding client_id back as well > > On 3/12/20 11:31 AM, 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> > <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> wrote: > > I agree that we should restore the client_id functionality. Thanks for > moving this forward! > > -- Mike > > *From:* OAuth <oauth-boun...@ietf.org> <oauth-boun...@ietf.org> *On Behalf Of > *Nat Sakimura > *Sent:* Monday, February 24, 2020 6:18 PM > *To:* John Bradley <ve7...@ve7jtb.com> <ve7...@ve7jtb.com> > *Cc:* oauth <oauth@ietf.org> <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> > <ve7...@ve7jtb.com> wrote: > > > ---------- Forwarded message --------- > From: *John Bradley* <ve7...@ve7jtb.com> <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> <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> > <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> > <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> > <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> > > <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> > > <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> > > <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> > > <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 listOAuth@ietf.orghttps://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> > > <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 listOAuth@ietf.orghttps://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> > > <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 listOAuth@ietf.orghttps://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> > > <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 listOAuth@ietf.orghttps://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> > > <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 > listOAuth@ietf.orghttps://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> > > <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 > listOAuth@ietf.orghttps://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> > > <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 > Foundationhttp://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> > > <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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
