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

[Nat Sakimura <[e-mail]>]

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=
[e-mail]> 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 <[e-mail]> <[e-mail]> wrote:
>
>
> I agree with that too.
>
> Joseph
>
> On 12 Mar 2020, at 14:18, Mike Jones <Michael.Jones=[e-mail]> wrote:
>
> I agree that we should restore the client_id functionality.  Thanks for
> moving this forward!
>
>                                                        -- Mike
>
> *From:* OAuth <[e-mail]> <[e-mail]> *On Behalf Of *Nat Sakimura
> *Sent:* Monday, February 24, 2020 6:18 PM
> *To:* John Bradley <[e-mail]> <[e-mail]>
> *Cc:* oauth <[e-mail]> <[e-mail]>
> *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 <[e-mail]> <[e-mail]> wrote:
>
>
> ---------- Forwarded message ---------
> From: *John Bradley* <[e-mail]> <[e-mail]>
> 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 <[e-mail]> <[e-mail]>
>
>
> 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 <[e-mail]> <[e-mail]> 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 <[e-mail]> <[e-mail]>
>
> 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 <[e-mail]> <[e-mail]> 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 [e-mail]://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 [e-mail]://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 [e-mail]://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 [e-mail]://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 [e-mail]://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 [e-mail]://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 [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en