Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

From: Mike Jones <[email-masked]>
Date: Thu, 12 Mar 2020 14:18:34 +0000

I agree that we should restore the client_id functionality.  Thanks for moving this forward!

                                                       -- Mike

From: OAuth <[email-masked]> On Behalf Of Nat Sakimura
Sent: Monday, February 24, 2020 6:18 PM
To: John Bradley <[email-masked]>
Cc: oauth <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:

---------- Forwarded message ---------
From: John Bradley <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>>

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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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
> >>> [email-masked]<mailto:[email-masked]>
> >>> 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
> >> [email-masked]<mailto:[email-masked]>
> >> 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
> > [email-masked]<mailto:[email-masked]>
> > 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
> [email-masked]<mailto:[email-masked]>
> 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
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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

---

From: Joseph Heenan <[email-masked]>
Date: Thu, 12 Mar 2020 14:20:20 +0000

I agree with that too.

Joseph

> On 12 Mar 2020, at 14:18, Mike Jones <Michael.Jones=[email-masked]> wrote:
> 
> From: OAuth <[email-masked] <mailto:[email-masked]>> On Behalf Of Nat Sakimura
> To: John Bradley <[email-masked] <mailto:[email-masked]>>
> Cc: oauth <[email-masked] <mailto:[email-masked]>>
> On Fri, Jan 24, 2020 at 6:55 AM John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>  
> From: John Bradley <[email-masked] <mailto:[email-masked]>>
> To: Benjamin Kaduk <[email-masked] <mailto:[email-masked]>>
>  
> 
> On Fri, Jan 17, 2020 at 11:53 PM Benjamin Kaduk <[email-masked] <mailto:[email-masked]>> wrote:
> > > On Jan 16, 2020, at 7:38 PM, Joseph Heenan <[email-masked] <mailto:[email-masked]>> wrote:
> > > 
> > >> On 16 Jan 2020, at 22:40, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
> > >> 
> > >>>>> <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.
> > >>>>> 
> > >>> 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://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.
> > >>> 
> > >>> [email-masked] <mailto:[email-masked]>
> > >>> 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>
> > >> 
> > >> [email-masked] <mailto:[email-masked]>
> > >> 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>
> > > 
> > > [email-masked] <mailto:[email-masked]>
> > > 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>
> > 
> 
> > [email-masked] <mailto:[email-masked]>
> > 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>
> 
> [email-masked] <mailto:[email-masked]>
> 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>
> [email-masked] <mailto:[email-masked]>
> 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)
> 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
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 12 Mar 2020 09:31:12 -0600

+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 <[email-masked]> wrote:

> I agree with that too.
>
> Joseph
>
> On 12 Mar 2020, at 14:18, Mike Jones <
> Michael.Jones=[email-masked]> wrote:
>
> *From:* OAuth <[email-masked]> *On Behalf Of *Nat Sakimura
> *Sent:* Monday, February 24, 2020 6:18 PM
> *To:* John Bradley <[email-masked]>
> *Cc:* oauth <[email-masked]>
> *Subject:* Re: [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured Authorization
> Request (JAR) vs OIDC request object
>
> On Fri, Jan 24, 2020 at 6:55 AM John Bradley <[email-masked]> wrote:
>
>
> From: *John Bradley* <[email-masked]>
> To: Benjamin Kaduk <[email-masked]>
>
>
> 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 <[email-masked]> wrote:
>
> > 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:
> >
> > 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:
>
> > 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 <[email-masked]>
> 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 <[email-masked]> wrote:
> > >>
> > >>>>> <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.
> > >>>>>
> 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://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.
> > >>>
> > >>> [email-masked]
> > >>> 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>
> > >>
> > >> [email-masked]
> > >> 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>
> > >
> > > [email-masked]
> > > 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>
> >
>
> > [email-masked]
> > 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>
>
> [email-masked]
> 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>
>
> [email-masked]
> 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)
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> [email-masked]
> 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._

---

From: George Fletcher <[email-masked]>
Date: Thu, 12 Mar 2020 12:24:29 -0400

I'm a +1 for adding client_id back as well

---

From: Nat Sakimura <[email-masked]>
Date: Mon, 16 Mar 2020 23:20:28 +0900

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=
[email-masked]> wrote:

> On Thu, Mar 12, 2020 at 8:20 AM Joseph Heenan <[email-masked]> <[email-masked]> wrote:
>
>
> I agree with that too.
>
> Joseph
>
> *From:* OAuth <[email-masked]> <[email-masked]> *On Behalf Of *Nat Sakimura
> *To:* John Bradley <[email-masked]> <[email-masked]>
> *Cc:* oauth <[email-masked]> <[email-masked]>
> On Fri, Jan 24, 2020 at 6:55 AM John Bradley <[email-masked]> <[email-masked]> wrote:
>
>
> From: *John Bradley* <[email-masked]> <[email-masked]>
> To: Benjamin Kaduk <[email-masked]> <[email-masked]>
>
>
> On Fri, Jan 17, 2020 at 11:53 PM Benjamin Kaduk <[email-masked]> <[email-masked]> wrote:
>
> I don’t agree with this stance from a security or implementation
>
> perspective.
>
>  - 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
>
> On Jan 16, 2020, at 7:38 PM, Joseph Heenan <[email-masked]> <[email-masked]>
>
> wrote:
>
> On 16 Jan 2020, at 22:40, John Bradley <[email-masked]> <[email-masked]> wrote:
>
> Puting the iss in the JWE headder addresses the encryption issue
>
> without
>
> merging.
>
> I understand that some existing servers have dependencys on getting
>
> the
>
> 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
>
> I am not promising a change but gathering info before proposing
>
> something.
>
> John B.
>
>
> achieve "request parameters outside the request object should not
>
> be
>
> <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.
>
> request / request_uri because client authentication is not
>
> performed
>
> client (every client is unauthenticated at the authorization
>
> endpoint)
>
> 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
>
> I really wonder what the reasoning of the IESG reviewers was to
>
> insist
>
> 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,
>
> 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
>
> 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 [email-masked]://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 [email-masked]://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 [email-masked]://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 [email-masked]://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 [email-masked]://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 [email-masked]://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 [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Tue, 17 Mar 2020 14:39:39 +0200

+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 <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I agree with that too.
>
>     Joseph
>
>>     On 12 Mar 2020, at 14:18, Mike Jones
>>     <Michael.Jones=[email-masked]
>>     <mailto:Michael.Jones=[email-masked]>> wrote:
>>
>>     *From:* OAuth <[email-masked]
>>     <mailto:[email-masked]>> *On Behalf Of *Nat Sakimura
>>     *To:* John Bradley <[email-masked] <mailto:[email-masked]>>
>>     *Cc:* oauth <[email-masked] <mailto:[email-masked]>>
>>     *Subject:* Re: [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured
>>     Authorization Request (JAR) vs OIDC request object
>>      
>>         From: *John Bradley* <[email-masked]
>>         <mailto:[email-masked]>>
>>         Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured
>>         Authorization Request (JAR) vs OIDC request object
>>         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
>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>             > 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:
>>
>>             > 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
>>             > > On Jan 16, 2020, at 7:38 PM, Joseph Heenan
>>             <[email-masked] <mailto:[email-masked]>> 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
>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>             > >> 
>>             > >> security properties it would be quite difficult to
>>             specify safely..
>>             > >> 
>>             <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://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.
>>             > >>> 
>>         <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)
> /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./
>

-- 
Vladimir Dzhuvinov

---

From: Rob Otto <[email-masked]>
Date: Tue, 17 Mar 2020 12:56:49 +0000

I agree with this as well.

Rob

On Tue, 17 Mar 2020 at 12:40, Vladimir Dzhuvinov <[email-masked]>
wrote:

> parameter outside the request object JWT or URI and that its value has to
> be the same as within the request object.
>
>> > Breaking one out of the four possible combinations in a very
>> predictable way is, I think, the best way to handle backwards compatibility
>> here.
>> >
>> isn’t found inside the request object).. Ruling out that case makes
>> security analysis (particularly when creating new OAuth2 parameters)
>> significantly simpler.
>> > >
>> > >> security properties it would be quite difficult to specify safely..
>> > >>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> 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.*
>

-- 
<https://www.pingidentity.com>
<https://www.pingidentity.com>
Rob Otto
EMEA Field CTO/Solutions Architect
[email-masked]

c: +44 (0) 777 135 6092
Connect with us: 
<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
[image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter
logo] <https://twitter.com/pingidentity> 
<https://www.facebook.com/pingidentitypage> 
<https://www.youtube.com/user/PingIdentityTV> 
<https://www.pingidentity.com/en/blog.html>
<https://www.google.com/url?q=https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/faqs/en/consumer-attitudes-post-breach-era-3375.pdf?id%3Db6322a80-f285-11e3-ac10-0800200c9a66&source=gmail&ust=1541693608526000&usg=AFQjCNGBl5cPHCUAVKGZ_NnpuFj5PHGSUQ>
<https://www.pingidentity.com/en/events/d/identify-2019.html>
<https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/Misc/en/3464-consumersurvey-execsummary.pdf>
<https://www.pingidentity.com/en/events/e/rsa.html>
<https://www.pingidentity.com/en/events/e/rsa.html>
<https://developer.pingidentity.com/en/signup.html>