Re: [OAUTH-WG] JWT Token on-behalf of Use case
Justin Richer <jricher@mit.edu> Tue, 07 July 2015 00:04 UTC
Return-Path: <jricher@mit.edu>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65DA61A00EE for <oauth@ietfa.amsl.com>; Mon, 6 Jul 2015 17:04:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 2stp0varxv8g for <oauth@ietfa.amsl.com>; Mon, 6 Jul 2015 17:04:07 -0700 (PDT)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB01F1A21AC for <oauth@ietf.org>; Mon, 6 Jul 2015 17:04:06 -0700 (PDT)
X-AuditID: 1209190d-f796f6d000005314-75-559b1774ecbb
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 53.45.21268.5771B955; Mon, 6 Jul 2015 20:04:05 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t67044Nk017145 for <oauth@ietf.org>; Mon, 6 Jul 2015 20:04:04 -0400
Received: from [192.168.128.56] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t67042rh025935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <oauth@ietf.org>; Mon, 6 Jul 2015 20:04:04 -0400
Message-ID: <559B176F.90105@mit.edu>
Date: Mon, 06 Jul 2015 20:03:59 -0400
From: Justin Richer <jricher@mit.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: oauth@ietf.org
References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> <BY2PR03MB442205D40E8F1ECD88082F2F5AE0@BY2PR03MB442.namprd03.prod.outlook.com> <55928DB3.7090300@gmail.com> <5593C270.7000008@gmail.com> <5593DA7D.80401@mit.edu> <5593E5FD.3050403@gmail.com> <CA+k3eCTA+HmwnMBUBzD7FKYWL37BMA7az_2BE+vnqqpO3=2utw@mail.gmail.com> <559A676F.3070008@gmail.com> <CA+k3eCTJsLqn88K4qEYJUzoxwAH4boWGsvJZtZi8guvV6C6zSA@mail.gmail.com> <DEAFAD4A-36F8-47D7-813D-35948CDCEA2C@ve7jtb.com> <BY2PR03MB44276C3D04E3FE5AE238298F5930@BY2PR03MB442.namprd03.prod.outlook.com> <CA+k3eCTRK9ND5c2HbDU=3ctZ3J4u3HMA2QHNZfEpwtfcwiLxfQ@mail.gmail.com> <CY1PR0301MB12437C5CFE06B7837375E5DBA6930@CY1PR0301MB1243.namprd03.prod.outlook.com> <2BB85061-F141-478C-96B1-5086AFDA1F4F@oracle.com>
In-Reply-To: <2BB85061-F141-478C-96B1-5086AFDA1F4F@oracle.com>
Content-Type: multipart/alternative; boundary="------------020202070200060409080503"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsUixCmqrFsqPjvU4OFxTouTb1+xOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4//TZYwFa84xV7w4Id3A+HA6UxcjJ4eEgInE5qVrWCFsMYkL 99azdTFycQgJLGaSWPQOJAHiHGWUWPZ0L5TznkliVdsX5i5GDg5eARWJk2dlQLpZBFQlDm29 zg5iswHZ09e0gG0QFYiSmPp4HQuIzSsgKHFy5hMwW0RASOL5zj6wGmEBc4ktTfsZIeb/Z5WY 23SHDSTBKWAncW7PFrDzmAXCJDomTGefwMg/C8msWUhSELatxJ25u5khbHmJ5q2zoWxdiUXb VrAjiy9gZFvFKJuSW6Wbm5iZU5yarFucnJiXl1qka6SXm1mil5pSuokRHMiSvDsY3x1UOsQo wMGoxMMbUTMzVIg1say4MvcQoyQHk5Io7y3h2aFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHjP vJwVKsSbklhZlVqUD5OS5mBREufd9IMvREggPbEkNTs1tSC1CCYrw8GhJMEbLQY0VLAoNT21 Ii0zpwQhzcTBCTKcB2i4FkgNb3FBYm5xZjpE/hSjopQ4732QhABIIqM0D64XlmheMYoDvSLM +18UqIoHmKTgul8BDWYCGrxcF+Tq4pJEhJRUA6PH5q/uTJ1hs24/zWD9uWu7ipvifvf4DvlJ hRd1T92Z2y24ydHcv1v8lwCrA3eDf2bIXKvbMYLFZcqvlEVW8Nfzavc1LGnjOX39tu/F25Pz lxut1ai9o1Tc27kuuHvBvS3fVNxfH7qh9Tv+TNx5wQN3dadc0znuZX//3uFEi2blWMOLIo+L WJRYijMSDbWYi4oTAV7q3DwPAwAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/LPE2HWACWhBO_0H0M5fUYMhj840>
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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, 07 Jul 2015 00:04:14 -0000
+1 for this. Let's learn from the mistakes of the past instead of repeating them. "We've always done it this way" is a really, really poor reason for doing something. -- Justin On 7/6/2015 5:20 PM, Phil Hunt wrote: > I think the original reasoning was sound, but the fact that so many > remain confused is good reason to go to new vocab. > > We could still have clarifying text that impersonate/composite is xxx > and yyy in kerberos etc. > > Phil > > On Jul 6, 2015, at 13:43, Anthony Nadalin <tonynad@microsoft.com > <mailto:tonynad@microsoft.com>> wrote: > >> The WS-Trust “ActAs” mimics the Windows Kerberos Protocol Transition >> (impersonation) feature as this enables an account to impersonate >> another account for the purpose of providing access to resources. In >> a typical scenario, the impersonating account would be a service >> account assigned to a web application or the computer account of a >> web server. The impersonated account would be a user account >> requiring access to resources (e.g. data in an SQL database) via a >> web application. In this scenario, SQL server would be accessed by >> the impersonating (service account) account, however access would be >> under the context of the impersonated (user) account. >> >> WS-Trust “OnBehalfOf” mimics the Windows Kerberos Constrained >> Delegation feature, which lets you limit the back-end services for >> which a front-end service can request tickets on behalf of another >> user. “OnBehalfOf” allows a selected services on a server can be >> granted for access by the impersonating account, whilst other >> services on the same server, or services on other servers are denied >> for access. >> >> Maybe someone can summarize why they think the text for ActAs and >> OnBehalfOf in WS-Trust or Windows Kerberos is wrong or swapped as I >> have not seen a clear explanation other than John saying that Brian >> knows and Brian saying John knows. >> >> Our usage and use cases are based upon the deployed services of >> WS-Trust and Kerberos support in Windows (workstation and server) and >> Xbox. >> >> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian >> Campbell >> *Sent:* Monday, July 6, 2015 11:29 AM >> *To:* Mike Jones <Michael.Jones@microsoft.com >> <mailto:Michael.Jones@microsoft.com>> >> *Cc:* oauth <oauth@ietf.org <mailto:oauth@ietf.org>> >> *Subject:* Re: [OAUTH-WG] JWT Token on-behalf of Use case >> >> Stating specific action items resulting from the ad-hoc meeting in >> Dallas like that suggests some clear consensus was reached, which is >> not at all the case. As I recall, several of us argued past one >> another for an hour or so and decided to adjourn in order to go to >> the bar (okay, and dinner too - but mostly beer). >> >> The impression about reversal of terms, I think, comes from the text >> in >> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 >> which hurts my head a little every-time I read it but does seems to >> confuse things. The MSDN link >> <https://msdn.microsoft.com/en-us/library/ee748487.aspx> John gave is >> much more to the point than WS-Trust (I don't believe WS-Trust can be >> pointed to as a model of clarity). In the draft I wrote, I tried to >> take Mike's text and clarify a distinction between impersonation and >> delegation with >> https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 >> and then also be very explicit about act-as vs. on-behalf-of in the >> parameter definitions at >> https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in >> a manor that was consistent with WS-Trust and the MSDN explanation. I >> could see value in breaking with that shaky legacy and using new >> terms too. But I get the point of trying to keep with the old also >> and potential for even more confusing by using new terms. >> >> I wrote draft-campbell-oauth-sts last year in response to the call >> for adoption of jones-oauth-token-exchange (thread from the archive >> <https://www.ietf.org/mail-archive/web/oauth/current/msg13305.html>). >> Though I didn't try and stand in the way and indicated a willingness >> to collaborate on things. With the expectation, of course, that the >> details would differ from the -00s and -01s as work progressed. Folks >> seemed generally amenable to that >> <https://www.ietf.org/mail-archive/web/oauth/current/msg13308.html> >> at the time but little has happened since then. >> >> Phil's earlier point about the priory of this getting pushed down has >> some truth to it. But I still believe it's something that can provide >> a lot of value in standardizing, if we do so in a reasonable way. >> >> >> >> On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones >> <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>> wrote: >> >> It would surprise me if on-behalf-of and act-as were reversed >> with respect WS-Trust, because the explanations of the terms came >> directly from WS-Trust 1.4. I also think the chances of us >> reducing confusion by inventing new terminology, rather than >> adding to it, would not be in our favor. :-/ >> >> FYI, the action items outstanding from our ad-hoc meeting on this >> draft in Dallas are: >> - Allowing security types other than JWT to also be used as the >> act_as and on_behalf_of request values. >> - Further integrating the mechanism into the existing OAuth >> ecosystem - allowing use of access tokens or refresh tokens when >> appropriate. >> >> I plan to do the first today. The second is probably more than >> I'll get done today before the submission cutoff. I agree with >> John that it would be useful to have discussions on this in >> Prague on the best way to achieve this further integration. I'll >> plan to come into the Prague meeting with a concrete proposal for >> review. >> >> Best wishes, >> -- Mike >> >> >> -----Original Message----- >> From: OAuth [mailto:oauth-bounces@ietf.org >> <mailto:oauth-bounces@ietf.org>] On Behalf Of John Bradley >> Sent: Monday, July 06, 2015 8:13 AM >> To: Brian Campbell >> Cc: oauth >> Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case >> >> Yes unfortunately we haven’t made any progress on this since >> accepting Mike’s first draft. >> >> His proposal is basically for a new endpoint while Brian tired to >> fit it into the existing token endpoint. >> >> I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf >> and ActAs reversed compared to WS-Trust 1.4. >> see https://msdn.microsoft.com/en-us/library/ee748487.aspx for >> the short explanation. >> >> I think Brian is closer in explaining it. >> >> In fairness because WS-Trust originally only had On-Behalf-Of the >> naming and what people put in tokens is a bit muddled in many >> implementations. >> I think many times it is how WIF implemented it that people copied. >> >> It may be better to have new terms that are clear such as >> impersonation and composite. >> >> The WG needs to decide if this is going to be an entirely new >> endpoint, free of the Token endpoint semantics. There are >> plusses and minuses to both options. >> >> Also while it is nice to be pure and talk about abstract security >> tokens, it would be good to give some guidance on what a >> composite security token would look like for interoperability. >> >> There are also issues around how this would work with proof of >> possession security tokens, both as input and output. >> >> Perhaps we can make some progress on this in Prague. >> >> John B. >> >> >> >> >> > On Jul 6, 2015, at 11:04 AM, Brian Campbell >> <bcampbell@pingidentity.com <mailto:bcampbell@pingidentity.com>> >> wrote: >> > >> > Thanks Sergey, >> > >> > The goal of draft-campbell-oauth-sts was to be consistent with >> OAuth 2.0 and thus hopefully familiar to developers and easy to >> understand and implement (especially from the client side). It's >> also intended to be flexible in order to accommodate a variety of >> use-cases including the chaining type cases that Justin's draft >> covers. >> > >> > Specifying a security_token_type of the returned token is just >> a way of providing more info to the client about the token (i.e. >> is this a JWT or a SAML token or something else) via a URI. It's >> not always needed but in STS style cases the tokens are not >> always opaque to the client and the parameter just provides info >> about the returned token. >> > >> > On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin >> <sberyozkin@gmail.com <mailto:sberyozkin@gmail.com>> wrote: >> > Hi Brian >> > >> > I've read the text, I like it is still pure OAuth2, with few >> extra parameters added to the access token request, and a key >> response property being 'access_token' as opposed to >> 'security_access_token' as in the draft-ietf-oauth-token-exchange-01. >> > It appears draft-campbell-oauth-sts-01 can cover a >> draft-richer-oauth-chain-00 case with the on_behalf_of (and/or >> act_as ?) property being an original client token but not 100% >> sure given draft-richer-oauth-chain-00 covers a specific case. >> > >> > One thing I'm not sure about is what is the purpose of specifying a >> > security_token_type of the returned access token >> > >> > Thanks, Sergey >> > >> > On 01/07/15 15:59, Brian Campbell wrote: >> > One problem, I think, with token exchange is that it can be really >> > simple (token in and token out) and really complicated (client >> X wants >> > a token that says user A is doing something on behalf of user B) at >> > the same time. >> > >> > I put forth >> https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in >> > an attempt to simplify things and express what I envisioned as an >> > OAuth based token exchange framework. Though it likely only muddied >> > the waters :) >> > >> > On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin >> <sberyozkin@gmail.com <mailto:sberyozkin@gmail.com> >> > <mailto:sberyozkin@gmail.com <mailto:sberyozkin@gmail.com>>> wrote: >> > >> > Hi Justin >> > >> > https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much >> > easier to read, that I can tell for sure, at least it is >> obvious why >> > a given entity (RS1) may want to exchange the current token >> provided >> > by a client for a new token. Definitely easily implementable... >> > >> > One thing I'm not sure in the draft-richer-oauth-chain-00 >> about is >> > on behalf of whose entity RS1 will be acting once it starts >> > accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO + >> > Client), or may be it is On Behalf Of RO + Act As Client ? >> The last >> > one seems most logical to me... >> > >> > Thanks, Sergey >> > >> > >> > On 01/07/15 13:18, Justin Richer wrote: >> > >> > As it's written right now, it's a translation of some WS-* >> > concepts into >> > JWT format. It's not really OAuth-y (since the client >> has to >> > understand >> > the token format along with everyone else, and >> according to the >> > authors >> > the artifacts might not even be "OAuth tokens"), and >> that's my main >> > issue with the document. Years ago, I proposed an >> OAuth-based >> > token swap >> > mechanism: >> > >> > https://tools.ietf.org/html/draft-richer-oauth-chain-00 >> > >> > This works without defining semantics of the tokens >> themselves, just >> > like the rest of OAuth. I've proposed to the authors of >> the current >> > draft that it should incorporate both semantic (using >> JWT) and >> > syntactic >> > (using a simple token-agnostic grant) token swap >> mechanisms, and >> > that >> > the two could be easily compatible. >> > >> > -- Justin >> > >> > On 7/1/2015 6:35 AM, Sergey Beryozkin wrote: >> > >> > Hmm... perhaps the clue is in the draft title, >> > token-exchange, so may >> > be it is a case of the given access token >> ("on_behalf_of" or >> > "act_as" >> > claim) being used to request a new security token. >> One can >> > only guess >> > though, does not seem like the authors are keen to >> answer >> > the newbie >> > questions... >> > >> > Cheers, Sergey >> > >> > >> > On 30/06/15 13:38, Sergey Beryozkin wrote: >> > >> > Hi, >> > Can you please explain what is the difference >> between >> > On-Behalf-Of >> > semantics described in the >> > draft-ietf-oauth-token-exchange-01 and the >> > implicit On-Behalf-Of semantics a client OAuth2 >> token >> > possesses ? >> > >> > For example, draft-ietf-oauth-token-exchange-01 >> mentions: >> > >> > "Whereas, with on-behalf-of semantics, >> principal A still >> > has its own >> > identity separate from B and it is explicitly >> understood >> > that while B >> > may have delegated its rights to A, any actions >> taken >> > are being taken by >> > A and not B. In a sense, A is an agent for B." >> > >> > This is a typical case with the authorization >> code flow >> > where a client >> > application acts on-behalf-of the user who >> authorized >> > this application ? >> > >> > Sorry if I'm missing something >> > >> > Cheers, Sergey >> > On 25/06/15 22:28, Mike Jones wrote: >> > >> > That’s what >> > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 >> > is >> > about. >> > >> > Cheers, >> > >> > -- Mike >> > >> > *From:*OAuth [mailto:oauth-bounces@ietf.org >> <mailto:oauth-bounces@ietf.org> >> > <mailto:oauth-bounces@ietf.org >> <mailto:oauth-bounces@ietf.org>>] *On Behalf Of *Vivek >> > Biswas >> > -T (vibiswas - XORIANT CORPORATION at Cisco) >> > *Sent:* Thursday, June 25, 2015 2:20 PM >> > *To:* OAuth@ietf.org >> <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org >> <mailto:OAuth@ietf.org>> >> > *Subject:* [OAUTH-WG] JWT Token on-behalf >> of Use >> > case >> > >> > Hi All, >> > >> > I am looking to solve a use-case similar to >> > WS-Security On-Behalf-Of >> > >> > >> <http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1 >> > .4-errata01-os-complete.html#_Toc325658980> >> > >> > >> > with OAuth JWT Token. >> > >> > Is there a standard claim which we can >> define >> > within the OAuth JWT >> > which denote the On-behalf-of User. >> > >> > For e.g., a Customer Representative trying >> to create >> > token on behalf of >> > a customer and trying to execute services >> specific >> > for that specific >> > customer. >> > >> > Regards, >> > >> > Vivek Biswas, >> > CISSP >> > >> > *Cisco Systems, Inc <http://www.cisco.com/>* >> > >> > *Bldg. J, San Jose, USA,* >> > >> > *Phone: +1 408 527 9176 >> <tel:%2B1%20408%20527%209176> >> > <tel:%2B1%20408%20527%209176>* >> > >> > >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org >> <mailto:OAuth@ietf.org>> >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org >> <mailto:OAuth@ietf.org>> >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org >> <mailto:OAuth@ietf.org>> >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org >> <mailto:OAuth@ietf.org>> >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > >> > >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org <mailto:OAuth@ietf.org> >> > https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] JWT Token on-behalf of Use case Vivek Biswas -T (vibiswas - XORIANT CORPORATION at Cisco)
- Re: [OAUTH-WG] JWT Token on-behalf of Use case Mike Jones
- Re: [OAUTH-WG] JWT Token on-behalf of Use case Sergey Beryozkin
- Re: [OAUTH-WG] JWT Token on-behalf of Use case Sergey Beryozkin
- Re: [OAUTH-WG] JWT Token on-behalf of Use case Justin Richer
- Re: [OAUTH-WG] JWT Token on-behalf of Use case Sergey Beryozkin
- Re: [OAUTH-WG] JWT Token on-behalf of Use case Brian Campbell
- Re: [OAUTH-WG] JWT Token on-behalf of Use case Phil Hunt
- Re: [OAUTH-WG] JWT Token on-behalf of Use case Anthony Nadalin
- Re: [OAUTH-WG] JWT Token on-behalf of Use case Sergey Beryozkin
- Re: [OAUTH-WG] JWT Token on-behalf of Use case Brian Campbell
- Re: [OAUTH-WG] JWT Token on-behalf of Use case John Bradley
- Re: [OAUTH-WG] JWT Token on-behalf of Use case Mike Jones
- Re: [OAUTH-WG] JWT Token on-behalf of Use case Phil Hunt
- Re: [OAUTH-WG] JWT Token on-behalf of Use case Brian Campbell
- Re: [OAUTH-WG] JWT Token on-behalf of Use case John Bradley
- Re: [OAUTH-WG] JWT Token on-behalf of Use case Mike Jones
- Re: [OAUTH-WG] JWT Token on-behalf of Use case Anthony Nadalin
- Re: [OAUTH-WG] JWT Token on-behalf of Use case John Bradley
- Re: [OAUTH-WG] JWT Token on-behalf of Use case Phil Hunt
- Re: [OAUTH-WG] JWT Token on-behalf of Use case Brian Campbell
- Re: [OAUTH-WG] JWT Token on-behalf of Use case John Bradley
- Re: [OAUTH-WG] JWT Token on-behalf of Use case Anthony Nadalin
- Re: [OAUTH-WG] JWT Token on-behalf of Use case Brian Campbell
- Re: [OAUTH-WG] JWT Token on-behalf of Use case Justin Richer
- Re: [OAUTH-WG] JWT Token on-behalf of Use case Sam Hartman
- Re: [OAUTH-WG] JWT Token on-behalf of Use case Kathleen Moriarty
- Re: [OAUTH-WG] JWT Token on-behalf of Use case Kathleen Moriarty
- Re: [OAUTH-WG] JWT Token on-behalf of Use case Justin Richer
- Re: [OAUTH-WG] JWT Token on-behalf of Use case Mike Jones