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