Re: [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object
Nat Sakimura <sakimura@gmail.com> Tue, 25 February 2020 02:18 UTC
Return-Path: <sakimura@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83163A1813 for <oauth@ietfa.amsl.com>; Mon, 24 Feb 2020 18:18:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCt6i64m5F3Y for <oauth@ietfa.amsl.com>; Mon, 24 Feb 2020 18:17:59 -0800 (PST)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 541E53A184B for <oauth@ietf.org>; Mon, 24 Feb 2020 18:17:59 -0800 (PST)
Received: by mail-wr1-x430.google.com with SMTP id z3so12808897wru.3 for <oauth@ietf.org>; Mon, 24 Feb 2020 18:17:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vu8g4oZ1Esw/DQR7qXRxBMBCW0t7yY46/quaJlYGFQ0=; b=uLvuDeBWITloAhMbS6ysVpBRA2TjcpGpkD+LTAz+VvsE8ADvP+61je8ED/W05EZO34 u+fWomxp3RhNKDO53j+1KrjLl1ltnK0/TjfU/5YbJvsVdAKDPraMRfS4UD60e2b7gpw1 mb2B+aZeUfyEiS/DD8hKO8C31OX2i6vA6q9xDTXXQtfUgRTUop2VKoPCBkMec/PHIoMy 9bKiSCvjdwTFt2NlL252An31ISZTBkAHb0lsiRaorDjfPv8PuHfpj3GMtkfTcYNCqndJ /4492QaJXj2rZ4SqtjNbb6CDqEXR7I/PxdcKb3dCBVFDNDImP5J3P8l5JTe5z9u9MQeO FyMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vu8g4oZ1Esw/DQR7qXRxBMBCW0t7yY46/quaJlYGFQ0=; b=i7XX85zo3HUJ9IcKf9HT0idpjqYTIEdqvsr96eNLGwVyStKPRQX9HGMiqOqlfw2TXm RfBz7d3QMyMc63fqUzXnHcL3PC9/kzkPW6OOyYQdRR7ITrtkF3WORv3/8jJ+vFZ9KrpO JHLcud+yzWcqs9Ww3loTVWwF8sA1IBQLktKyI0vLH9QdAjQ7DNIHPGB7xee1Rp/S7SzT FcJ/leirSIgb9JVYN4j4/yjpYQ+OUzo7RPYjfmINxKS4BhVmwDqr2cJBHSgAcDwnnm/7 ffj1p2x0IGeoXIwc0jt+9u48rb1Lheu8ZF5qWPKVcGCzWchX75aHMQGi1vtHTArNv7EY J5Yg==
X-Gm-Message-State: APjAAAV4WpfXTH7jXeEo/+EG48yLiJyO93G5hEPe0XAH3aYBEeeGj3nR NTmwJpqDEQyrWdTGyBbghDLNACwULDr8+BVCNLNuXEatGQM=
X-Google-Smtp-Source: APXvYqz354Lit8cF97INEV8sbueTny9rq+h1A6+l0/6Q89645P0Ahfpgf3l65Ht8oLXDVIVNOJGyKfi/jl0Lh6LGrj8=
X-Received: by 2002:adf:f18e:: with SMTP id h14mr11579798wro.51.1582597077298; Mon, 24 Feb 2020 18:17:57 -0800 (PST)
MIME-Version: 1.0
References: <CAANoGhJB4mYSFiWKt3T=cObH7uCW0s3Zpv2m92+YaAY2Oy4mqw@mail.gmail.com> <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com> <7baae999-47c1-f749-6c51-f45022ab1a3d@ve7jtb.com> <3d9ffc74-6c9c-48a1-0c98-65a7465e8dbc@connect2id.com> <CAHdPCmNHeUyDjrc32oQPZ5g3oars-XY3vq2p3qt2LzzkZMTw5w@mail.gmail.com> <89345e9b-8191-f01d-71a6-453ec197796f@connect2id.com> <20200116045302.GG80030@kduck.mit.edu> <837c8db5-5200-29c6-5914-167b77bdc071@ve7jtb.com> <9DAC4E16-2A60-4B86-B1FA-B59B097E8F78@authlete.com> <D6837D1F-01B6-4B46-8DF7-41969BE96112@mit.edu> <20200118025320.GV80030@kduck.mit.edu> <CAANoGhKtgqob_7AmFJ-OfROSx7QopehFdKAx8qmR8rUdzLNWPA@mail.gmail.com> <CAANoGhJgz6QC8rTwXH4Fik9bRydFDuAJB3Kpvoj3j1MCX2CZOw@mail.gmail.com>
In-Reply-To: <CAANoGhJgz6QC8rTwXH4Fik9bRydFDuAJB3Kpvoj3j1MCX2CZOw@mail.gmail.com>
From: Nat Sakimura <sakimura@gmail.com>
Date: Tue, 25 Feb 2020 11:17:45 +0900
Message-ID: <CABzCy2B1ApKF6qKRNbaYiaR8sJEDiOkgjMxZV4vVmyfQ4xVYag@mail.gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009d7402059f5d1847"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/yM7Ai5cHnK28KfESzASCBejRb90>
Subject: Re: [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2020 02:18:03 -0000
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 <ve7jtb@ve7jtb.com> wrote: > > ---------- Forwarded message --------- > From: John Bradley <ve7jtb@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 <kaduk@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 <kaduk@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 <joseph@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 <ve7jtb@ve7jtb.com> wrote: >> > >> >> > >> I agree with the IESG reasoning that merging is problimatic. Once we >> > >> allow that given a unknown list of possible paramaters with diffrent >> > >> security properties it would be quite difficult to specify safely. >> > >> >> > >> Query paramaters can still be sent outside the JAR, but if they are >> in >> > >> the OAuth registry the AS MUST ignore them. >> > >> >> > >> Puting the iss in the JWE headder addresses the encryption issue >> without >> > >> merging. >> > >> >> > >> I understand that some existing servers have dependencys on getting >> the >> > >> clientID as a query paramater. >> > >> >> > >> Is that the only paramater that people have a issue with as oposed >> to a >> > >> nice to have? >> > >> >> > >> Would allowing the AS to not ignore the clientID as a query >> paramater as >> > >> long as it matches the one inside the JAR, basicly the same as >> Connect >> > >> request object but for just the one paramater make life easier for >> the >> > >> servers? >> > >> >> > >> I am not promising a change but gathering info before proposing >> something. >> > >> >> > >> John B. >> > >> >> > >> >> > >> On 1/16/2020 1:53 AM, Benjamin Kaduk wrote: >> > >>> On Wed, Jan 15, 2020 at 11:02:33PM +0200, Vladimir Dzhuvinov wrote: >> > >>>> On 14/01/2020 19:20, Takahiko Kawasaki wrote: >> > >>>>> Well, embedding a client_id claim in the JWE header in order to >> > >>>>> achieve "request parameters outside the request object should not >> be >> > >>>>> referred to" is like "putting the cart before the horse". Why do >> we >> > >>>>> have to avoid using the traditional client_id request parameter so >> > >>>>> stubbornly? >> > >>>>> >> > >>>>> The last paragraph of Section 3.2.1 >> > >>>>> <https://tools.ietf.org/html/rfc6749#section-3.2.1> of RFC 6749 >> says >> > >>>>> as follows. >> > >>>>> >> > >>>>> /A client MAY use the "client_id" request parameter to identify >> > >>>>> itself when sending requests to the token endpoint. In the >> > >>>>> "authorization_code" "grant_type" request to the token endpoint, >> > >>>>> *an unauthenticated client MUST send its "client_id" to prevent >> > >>>>> itself from inadvertently accepting a code intended for a client >> > >>>>> with a different "client_id".* This protects the client from >> > >>>>> substitution of the authentication code. (It provides no >> > >>>>> additional security for the protected resource.)/ >> > >>>>> >> > >>>>> >> > >>>>> If the same reasoning applies, a client_id must always be sent >> with >> > >>>>> request / request_uri because client authentication is not >> performed >> > >>>>> at the authorization endpoint. In other words, */an >> unauthenticated >> > >>>>> client (every client is unauthenticated at the authorization >> endpoint) >> > >>>>> MUST send its "client_id" to prevent itself from inadvertently >> > >>>>> accepting a request object for a client with a different >> "client_id"./* >> > >>>>> >> > >>>> Identifying the client in JAR request_uri requests can be really >> useful >> > >>>> so that an AS which requires request_uri registration to prevent >> DDoS >> > >>>> attacks and other checks can do those without having to index all >> > >>>> request_uris individually. I mentioned this before. >> > >>>> >> > >>>> I really wonder what the reasoning of the IESG reviewers was to >> insist >> > >>>> on no params outside the JAR JWT / request_uri. >> > >>>> >> > >>>> I'm beginning to realise this step of the review process isn't >> > >>>> particularly transparent to WG members. >> > >>> Could you expand on that a bit more? My understanding is that the >> IESG >> > >>> ballot mail gets copied to the WG precisely so that there is >> transparency, >> > >>> e.g., the thread starting at >> > >>> >> https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdiR9R0JwgI >> > >>> Which admittely is from almost three years ago, but that's the >> earliest >> > >>> that I found that could be seen as the source of this behavior. >> > >>> >> > >>> -Ben >> > >>> >> > >>> P.S. some other discussion at >> > >>> >> https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-IGx4xHy8 >> and >> > >>> >> https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_UwY >> and >> > >>> so on. >> > >>> >> > >>> _______________________________________________ >> > >>> OAuth mailing list >> > >>> OAuth@ietf.org >> > >>> https://www.ietf.org/mailman/listinfo/oauth >> > >> >> > >> _______________________________________________ >> > >> OAuth mailing list >> > >> OAuth@ietf.org >> > >> https://www.ietf.org/mailman/listinfo/oauth >> > > >> > > _______________________________________________ >> > > OAuth mailing list >> > > OAuth@ietf.org >> > > https://www.ietf.org/mailman/listinfo/oauth >> > >> >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
- Re: [OAUTH-WG] JWT Secured Authorization Request … Torsten Lodderstedt
- Re: [OAUTH-WG] JWT Secured Authorization Request … John Bradley
- [OAUTH-WG] JWT Secured Authorization Request (JAR… Filip Skokan
- Re: [OAUTH-WG] JWT Secured Authorization Request … Torsten Lodderstedt
- Re: [OAUTH-WG] JWT Secured Authorization Request … Filip Skokan
- Re: [OAUTH-WG] JWT Secured Authorization Request … Brian Campbell
- Re: [OAUTH-WG] JWT Secured Authorization Request … Filip Skokan
- Re: [OAUTH-WG] JWT Secured Authorization Request … Filip Skokan
- Re: [OAUTH-WG] JWT Secured Authorization Request … Brian Campbell
- Re: [OAUTH-WG] JWT Secured Authorization Request … Torsten Lodderstedt
- Re: [OAUTH-WG] JWT Secured Authorization Request … Takahiko Kawasaki
- Re: [OAUTH-WG] JWT Secured Authorization Request … Nat Sakimura
- Re: [OAUTH-WG] JWT Secured Authorization Request … Dominick Baier
- Re: [OAUTH-WG] JWT Secured Authorization Request … John Bradley
- Re: [OAUTH-WG] JWT Secured Authorization Request … Nat Sakimura
- Re: [OAUTH-WG] JWT Secured Authorization Request … Takahiko Kawasaki
- Re: [OAUTH-WG] JWT Secured Authorization Request … Justin Richer
- Re: [OAUTH-WG] JWT Secured Authorization Request … Takahiko Kawasaki
- Re: [OAUTH-WG] JWT Secured Authorization Request … Justin Richer
- Re: [OAUTH-WG] JWT Secured Authorization Request … Vladimir Dzhuvinov
- Re: [OAUTH-WG] JWT Secured Authorization Request … n-sakimura
- Re: [OAUTH-WG] JWT Secured Authorization Request … Filip Skokan
- Re: [OAUTH-WG] JWT Secured Authorization Request … Takahiko Kawasaki
- Re: [OAUTH-WG] JWT Secured Authorization Request … Justin Richer
- Re: [OAUTH-WG] JWT Secured Authorization Request … John Bradley
- Re: [OAUTH-WG] JWT Secured Authorization Request … Justin Richer
- Re: [OAUTH-WG] JWT Secured Authorization Request … John Bradley
- Re: [OAUTH-WG] JWT Secured Authorization Request … Torsten Lodderstedt
- Re: [OAUTH-WG] JWT Secured Authorization Request … Vladimir Dzhuvinov
- Re: [OAUTH-WG] JWT Secured Authorization Request … Filip Skokan
- Re: [OAUTH-WG] JWT Secured Authorization Request … Vladimir Dzhuvinov
- Re: [OAUTH-WG] JWT Secured Authorization Request … John Bradley
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Mike Jones
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… John Bradley
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Vladimir Dzhuvinov
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… John Bradley
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Vladimir Dzhuvinov
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Takahiko Kawasaki
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Vladimir Dzhuvinov
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Mike Jones
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Benjamin Kaduk
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Benjamin Kaduk
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Benjamin Kaduk
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Neil Madden
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Dominick Baier
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Neil Madden
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… John Bradley
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Neil Madden
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Benjamin Kaduk
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Nat Sakimura
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Neil Madden
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Nat Sakimura
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Joseph Heenan
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Benjamin Kaduk
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Benjamin Kaduk
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Justin Richer
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Richard Backman, Annabelle
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Jim Manico
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Richard Backman, Annabelle
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Justin Richer
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Brian Campbell
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Joseph Heenan
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Benjamin Kaduk
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Benjamin Kaduk
- Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authori… Neil Madden
- [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured Author… John Bradley
- Re: [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured Au… Nat Sakimura
- Re: [OAUTH-WG] JWT Secured Authorization Request … Mike Jones
- Re: [OAUTH-WG] JWT Secured Authorization Request … Joseph Heenan
- Re: [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured Au… Filip Skokan
- Re: [OAUTH-WG] JWT Secured Authorization Request … Brian Campbell
- Re: [OAUTH-WG] JWT Secured Authorization Request … George Fletcher
- Re: [OAUTH-WG] JWT Secured Authorization Request … Nat Sakimura
- Re: [OAUTH-WG] JWT Secured Authorization Request … Vladimir Dzhuvinov
- Re: [OAUTH-WG] JWT Secured Authorization Request … Rob Otto