Re: [OAUTH-WG] OAuth 2.1: dropping password grant

Dick Hardt <dick.hardt@gmail.com> Sat, 22 February 2020 01:42 UTC

Return-Path: <dick.hardt@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 CFAEF1200F8 for <oauth@ietfa.amsl.com>; Fri, 21 Feb 2020 17:42:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 uGiqCIoyOAA0 for <oauth@ietfa.amsl.com>; Fri, 21 Feb 2020 17:42:02 -0800 (PST)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 3033B12006B for <oauth@ietf.org>; Fri, 21 Feb 2020 17:42:02 -0800 (PST)
Received: by mail-lj1-x234.google.com with SMTP id e18so4101219ljn.12 for <oauth@ietf.org>; Fri, 21 Feb 2020 17:42:02 -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=r/7sU6/2KU+nOxdK1Jy4yByDNK/YQsDzmgKxVfj7ToM=; b=Sn+6kAhY6QMBMm5+n9V1UHuh5/pvj0Sv278eFjH6vw/bsHov1lC5JiuT1OVpxeXIcf /OQEdfzd3Wf1ZDHShy8Sn33tQywLx6T4wk6AUex8yie3gozMKxib2Q0OVsBw75PEpmgw isVsCQF2/NqBaFL1AqZ0xbIIT3mtOC7BHNLDNI9tEi6pq228EEfGzmcfroMRSTzn+9w0 TU91x1RuJmwe3DDECnI+VzRbtQ9jP13CXm/EO97wQ8TQ1TSjyufL1pgUeM2g6IvOYP8H vG8JJrZOtZmkc4J/mIMhZu0px3pMfBHwwaLkGxdOSPxo+pMdmX6vh1p0I9+Ij0ctv0jH V96w==
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=r/7sU6/2KU+nOxdK1Jy4yByDNK/YQsDzmgKxVfj7ToM=; b=Yj52CiHYdkPo8tkRZiPUtH2+Px6gXiifzdxi5FIX0XwctyMEotxCkaWrMcr1QN77B9 ysr04vzMEA24r5SOi5Cwhp4U71FEhawIu0G9gJNoK1w9BT2uxen8ynSbf1jBIi6hWDnN TWnGgQQmBSl7cjlCtNUNMgsIe4EEmUzrzri3cj/h9oseh1vs3TZDR5N8N3+RFGuMIku8 T3M8LVVG1K8L3BqFHNDA1oRz6mPjpWcW3605EB2c1ezWXYj0lRFoqnkuHKpfOKXErEab caF2t/pAU9ggQ+rkdlB2XEE4upA1pmrjz2PgJ0l8dB7OGRIuOPLcXm3VTkIb1X0j3pcN 6OZQ==
X-Gm-Message-State: APjAAAWO/nMv1QypEEu6wrCH9GqX+9nXk47qgpJZo3ZFNLcCqwcnRezP m6IJhl3pUYpTHSFE9UDByROn/ApmJQ2sL0v/sc8=
X-Google-Smtp-Source: APXvYqzXVnrkJZtvWMsv5lUBHma1d+3Dq4MBtjlsd4Wfxtqkai8K/RMASqVPAL5avym1r9Q3sdanzZd+ptHIfkibmzk=
X-Received: by 2002:a2e:84d0:: with SMTP id q16mr24043235ljh.138.1582335720251; Fri, 21 Feb 2020 17:42:00 -0800 (PST)
MIME-Version: 1.0
References: <3A39A586-7ABE-4CA2-BAE0-ED3FD197C4BB@forgerock.com> <7C28AD9B-428E-4FB3-B41A-E707D0C1A296@lodderstedt.net> <E37187C7-9DD0-4C3B-990D-55CB8C39BD21@forgerock.com> <CAD9ie-trV02ifD8HU1JQ-FDS0=eLnikM7SWfd1hSHkn5_3m03Q@mail.gmail.com> <649A1EF4-EB80-4FB0-82D4-4F6E3535F774@forgerock.com> <CANsTMfEAoOa6ts8xPc5eZi+D09EOC11-07uUq9R5gD425EbUJg@mail.gmail.com> <9D8B2697-7B09-4CB1-9000-524AACB36D67@forgerock.com> <0C4103FE-12A1-4CB2-8D07-3CEF7D3B4340@lodderstedt.net> <3E680750-FDA1-4513-A2FE-B3E900EBE806@forgerock.com> <55991949-9B1A-44E1-B412-1BB8EAEA4A43@lodderstedt.net> <AAE487F7-776C-472B-B6DF-CB60D434F95A@forgerock.com> <6AFD3B88-CEE5-4857-845D-A866DF5C3DFE@amazon.com> <09C67C29-74D0-4723-826B-17698F566669@forgerock.com> <39B732FC-3401-4003-BDE6-9A3678D96CAD@amazon.com>
In-Reply-To: <39B732FC-3401-4003-BDE6-9A3678D96CAD@amazon.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Fri, 21 Feb 2020 17:41:21 -0800
Message-ID: <CAD9ie-t4-V1OFrq-LPwCyd4ccxXNzDFG8Vs4j6-9HfikhcSG2w@mail.gmail.com>
To: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
Cc: Neil Madden <neil.madden@forgerock.com>, Matthew De Haast <matt=40coil.com@dmarc.ietf.org>, "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000856461059f203e10"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/vsiXXJXw8c3xAFrp1kMKPcUA9Fc>
Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant
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: Sat, 22 Feb 2020 01:42:08 -0000

I'm a little confused on where this thread is going. If we take ROPC out of
OAuth 2.1 then:

1) Existing deployments can keep using ROPC - why break it if it is working.

2) New deployments can use ROPC and be OAuth 2.0 compliant.

3) New deployments that don't need ROPC can be OAuth 2.1 compliant

ᐧ

On Fri, Feb 21, 2020 at 5:05 PM Richard Backman, Annabelle <richanna=
40amazon.com@dmarc.ietf.org> wrote:

> ROPC without a client ID or authentication is functionally equivalent to
> Client Credentials grant with client secret authentication in the request
> body. You've just renamed "client_id" to "username" and "client_secret" to
> "password".
>
> The AS simply needs to be able to resolve the client ID to the service
> account. You could use any of the following strategies, depending on the
> environment:
> * Use service account identifiers as client IDs
> * Use encrypted blobs containing service account identifiers as client
> IDs, so someone can't choose a client ID by creating a service account with
> a specific identifier
> * Use opaque values that the AS can resolve to service account
> identifiers, e.g., via a database lookup
>
> If the AS needs the service account's password because it's authenticating
> against a legacy system, then use the service account password as the
> client secret. Stack mTLS on top, if you want. If the AS just needs to
> resolve the account so it can put it in tokens that RSes will look at, then
> you can use whatever client authentication mechanism you want.
>
> Is there a scenario I'm missing here?
>
> –
> Annabelle Backman (she/her)
> AWS Identity
> https://aws.amazon.com/identity/
>
>
> On 2/21/20, 1:53 PM, "Neil Madden" <neil.madden@forgerock.com> wrote:
>
>     The AS doesn’t issue the service account IDs, that’s the whole point -
> integration with existing systems. Lot’s of people don’t have the luxury of
> rebuilding systems from scratch to fit in with the preferences of the OAuth
> WG.
>
>     ROPC doesn’t require client authentication, or even a client
> identifier. If you’re using a service account you indeed don’t need to
> bother issuing client credentials. The same is true when using the JWT
> bearer grant. If you want to increase security you can use cert-bound
> access tokens.
>
>     > On 21 Feb 2020, at 20:28, Richard Backman, Annabelle <
> richanna@amazon.com> wrote:
>     >
>     > The client IDs can still be opaque identifiers provided by the AS,
> they just happen to be associated with specific service accounts. Or they
> could be the opaque IDs that the AS already issued for the service account.
> Either way, the AS could issue a token with the appropriate subject and
> other claims for the service account.
>     >
>     > If your client identity is bound to a specific service account
> identity (i.e., the resource owner), then ROPC reduces down to Client
> Credentials. What's the point in passing two identifiers and two
> credentials for the same identity?
>     >
>     > –
>     > Annabelle Backman (she/her)
>     > AWS Identity
>     > https://aws.amazon.com/identity/
>     >
>     >
>     > On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" <
> oauth-bounces@ietf.org on behalf of neil.madden@forgerock.com> wrote:
>     >
>     >    Sorry, I missed that message.
>     >
>     >    While this may be a solution in specific circumstances, I don’t
> think it’s a general solution. e.g. an AS may not allow manually choosing
> the client_id to avoid things like
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13
> or may return different introspection results for client credentials tokens
> (e.g. with no “sub”) and so on. In practice, this adds even more steps for
> somebody to migrate from existing ROPC usage.
>     >
>     >    This is asking people to make fundamental changes to their
> identity architecture rather than simply switching to a new grant type.
>     >
>     >    — Neil
>     >
>     >> On 21 Feb 2020, at 14:34, Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
>     >>
>     >> I see - we have gone full cycle :-)
>     >>
>     >> Annabelle’s proposal would solve that. Relate a client id to a
> service account and obtain the token data from there.
>     >>
>     >>> On 21. Feb 2020, at 15:31, Neil Madden <neil.madden@forgerock.com>
> wrote:
>     >>>
>     >>> Yes, that is great. But mTLS doesn’t support service accounts (!=
> clients). Maybe it should? Should there be a mTLS *grant type*?
>     >>>
>     >>> — Neil
>     >>>
>     >>>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
>     >>>>
>     >>>> Have you ever tried the client credentials grant with mTLS? After
> reading your description it seems to be simpler than JWT Bearer.
>     >>>>
>     >>>> * work out if the AS even supports mTLS
>     >>>> * work out how to configure the AS to trust my cert(s)
>     >>>> * Create key pair and cert using openssl
>     >>>> * Register your (self-signed) cert along with your client_id
>     >>>> * Configure the HTTP client to use your key pair for TLS Client
> Authentication
>     >>>>
>     >>>> Works very well for us.
>     >>>>
>     >>>>> On 21. Feb 2020, at 15:12, Neil Madden <
> neil.madden@forgerock.com> wrote:
>     >>>>>
>     >>>>> No failures, but it is a much more complex grant type to set up,
> when you consider everything you have to do:
>     >>>>>
>     >>>>> * work out if the AS even supports JWT bearer and how to turn it
> on
>     >>>>> * work out how to configure the AS to trust my public key(s)
>     >>>>> - do I have to create a new HTTPS endpoint to publish a JWK Set?
>     >>>>> * determine the correct settings for issuer, audience, subject,
> etc. Does the AS impose non-standard requirements? e.g. RFC 7523 says that
> the JWT MUST contain a “sub” claim, but Google only allows this to be
> present if your client is doing impersonation of an end-user (which
> requires additional permissions).
>     >>>>> * do I need a unique “jti” claim? (OIDC servers do, plain OAuth
> ones might not) If I do, can I reuse the JWT or must it be freshly signed
> for every call?
>     >>>>> * locate and evaluate a JWT library for my language of choice.
> Monitor that new dependency for security advisories.
>     >>>>> * choose a suitable signature algorithm (‘ere be dragons)
>     >>>>> * figure out how to distribute the private key to my service
>     >>>>>
>     >>>>> Compared to “create a service account and POST the username and
> password to the token endpoint” it adds a little friction. (It also adds a
> lot of advantages, but it is undeniably more complex).
>     >>>>>
>     >>>>> — Neil
>     >>>>>
>     >>>>>
>     >>>>>> On 21 Feb 2020, at 13:41, Matthew De Haast <matt=
> 40coil.com@dmarc.ietf.org> wrote:
>     >>>>>>
>     >>>>>> I have a feeling that if we had more concise JWT libraries and
> command line tools, where using the JWT Bearer grant became a one-liner
> again then we wouldn’t be having this conversation. So perhaps removing it
> is an incentive to make that happen.
>     >>>>>>
>     >>>>>> Neil could you elaborate more on this please. What failures are
> you currently experiencing/seeing with the JWT Bearer grant?
>     >>>>>>
>     >>>>>> Matt
>     >>>>>>
>     >>>>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden <
> neil.madden@forgerock.com> wrote:
>     >>>>>> I have a feeling that if we had more concise JWT libraries and
> command line tools, where using the JWT Bearer grant became a one-liner
> again then we wouldn’t be having this conversation. So perhaps removing it
> is an incentive to make that happen.
>     >>>>>>
>     >>>>>>
>     >>>>>>> On 19 Feb 2020, at 22:01, Dick Hardt <dick.hardt@gmail.com>
> wrote:
>     >>>>>>>
>     >>>>>>> Neil: are you advocating that password grant be preserved in
> 2.1? Or do you think that service account developers know enough about what
> they are doing to follow what is in 6749?
>     >>>>>>> ᐧ
>     >>>>>>>
>     >>>>>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden <
> neil.madden@forgerock.com> wrote:
>     >>>>>>> OAuth2 clients are often private to the AS - they live in a
> database that only the AS can access, have attributes specific to their use
> in OAuth2, and so on. Many existing systems have access controls based on
> users, roles, permissions and so on and expect all users accessing the
> system to exist in some user repository, e.g. LDAP, where they can be
> looked up and appropriate permissions determined. A service account can be
> created inside such a system as if it was a regular user, managed through
> the normal account provisioning tools, assigned permissions, roles, etc.
>     >>>>>>>
>     >>>>>>> Another reason is that sometimes OAuth is just one
> authentication option out of many, and so permissions assigned to service
> accounts are preferred over scopes because they are consistently applied no
> matter how a request is authenticated. This is often the case when OAuth
> has been retrofitted to an existing system and they need to preserve
> compatibility with already deployed clients.
>     >>>>>>>
>     >>>>>>> See e.g. Google cloud platform (GCP):
> https://developers.google.com/identity/protocols/OAuth2ServiceAccount
>     >>>>>>> They use the JWT bearer grant type for service account
> authentication and assign permissions to those service accounts and
> typically have very broad scopes. For service-to-service API calls you
> typically get an access token with a single scope that is effectively “all
> of GCP” and everything is managed at the level of permissions on the RO
> service account itself. They only break down fine-grained scopes when you
> are dealing with user data and will be getting an access token approved by
> a real user (through a normal auth code flow).
>     >>>>>>>
>     >>>>>>> — Neil
>     >>>>>>>
>     >>>>>>>> On 19 Feb 2020, at 21:35, Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
>     >>>>>>>>
>     >>>>>>>> Can you explain more in detail why the client credentials
> grant type isn’t applicable for the kind of use cases you mentioned?
>     >>>>>>>>
>     >>>>>>>>> Am 19.02.2020 um 22:03 schrieb Neil Madden <
> neil.madden@forgerock.com>gt;:
>     >>>>>>>>>
>     >>>>>>>>> I very much agree with this with regards to real users.
>     >>>>>>>>>
>     >>>>>>>>> The one legitimate use-case for ROPC I’ve seen is for
> service accounts - where you essentially want something like
> client_credentials but for whatever reason you need the RO to be a service
> user rather than an OAuth2 client (typically so that some lower layer of
> the system can still perform its required permission checks).
>     >>>>>>>>>
>     >>>>>>>>> There are better grant types for this - e.g. JWT bearer -
> but they are a bit harder to implement. Having recently converted some code
> from ROPC to JWT bearer for exactly this use-case, it went from a couple of
> lines of code to two screens of code. For service to service API calls
> within a datacenter I’m not convinced this resulted in a material increase
> in security for the added complexity.
>     >>>>>>>>>
>     >>>>>>>>> — Neil
>     >>>>>>>>>
>     >>>>>>>>>> On 18 Feb 2020, at 21:57, Hans Zandbelt <
> hans.zandbelt@zmartzone.eu> wrote:
>     >>>>>>>>>>
>     >>>>>>>>>> I would also seriously look at the original motivation
> behind ROPC: I know it has been deployed and is used in quite a lot of
> places but I have never actually come across a use case where it is used
> for migration purposes and the migration is actually executed (I know that
> is statistically not a very strong argument but I challenge others to come
> up with one...)
>     >>>>>>>>>> In reality it turned out just to be a one off that people
> used as an easy way out to stick to an anti-pattern and still claim to do
> OAuth 2.0. It is plain wrong, it is not OAuth and we need to get rid of it.
>     >>>>>>>>>>
>     >>>>>>>>>> Hans.
>     >>>>>>>>>>
>     >>>>>>>>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki <
> aaron@parecki.com> wrote:
>     >>>>>>>>>> Agreed. Plus, the Security BCP is already effectively
> acting as a grace period since it currently says the password grant MUST
> NOT be used, so in the OAuth 2.0 world that's already a pretty strong
> signal..
>     >>>>>>>>>>
>     >>>>>>>>>> Aaron
>     >>>>>>>>>>
>     >>>>>>>>>>
>     >>>>>>>>>>
>     >>>>>>>>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer <
> jricher@mit.edu> wrote:
>     >>>>>>>>>> There is no need for a grace period. People using OAuth
> 2..0 can still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.
>     >>>>>>>>>>
>     >>>>>>>>>> — Justin
>     >>>>>>>>>>
>     >>>>>>>>>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin <tonynad=
> 40microsoft.com@dmarc.ietf.org> wrote:
>     >>>>>>>>>>>
>     >>>>>>>>>>> I would suggest a SHOULD NOT instead of MUST, there are
> still sites using this and a grace period should be provided before a MUST
> is pushed out as there are valid use cases out there still.
>     >>>>>>>>>>>
>     >>>>>>>>>>> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Dick
> Hardt
>     >>>>>>>>>>> Sent: Tuesday, February 18, 2020 12:37 PM
>     >>>>>>>>>>> To: oauth@ietf.org
>     >>>>>>>>>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping
> password grant
>     >>>>>>>>>>>
>     >>>>>>>>>>> Hey List
>     >>>>>>>>>>>
>     >>>>>>>>>>> (Once again using the OAuth 2.1 name as a placeholder for
> the doc that Aaron, Torsten, and I are working on)
>     >>>>>>>>>>>
>     >>>>>>>>>>> In the security topics doc
>     >>>>>>>>>>>
>     >>>>>>>>>>>
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.4
>     >>>>>>>>>>>
>     >>>>>>>>>>> The password grant MUST not be used.
>     >>>>>>>>>>>
>     >>>>>>>>>>> Some background for those interested. I added this grant
> into OAuth 2.0 to allow applications that had been provided password to
> migrate. Even with the caveats in OAuth 2.0, implementors decide they want
> to prompt the user to enter their credentials, the anti-pattern OAuth was
> created to eliminate.
>     >>>>>>>>>>>
>     >>>>>>>>>>>
>     >>>>>>>>>>> Does anyone have concerns with dropping the password grant
> from the OAuth 2.1 document so that developers don't use it?
>     >>>>>>>>>>>
>     >>>>>>>>>>> /Dick
>     >>>>>>>>>>> _______________________________________________
>     >>>>>>>>>>> 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
>     >>>>>>>>>> --
>     >>>>>>>>>> ----
>     >>>>>>>>>> Aaron Parecki
>     >>>>>>>>>> aaronparecki.com
>     >>>>>>>>>> @aaronpk
>     >>>>>>>>>>
>     >>>>>>>>>> _______________________________________________
>     >>>>>>>>>> OAuth mailing list
>     >>>>>>>>>> OAuth@ietf.org
>     >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>     >>>>>>>>>>
>     >>>>>>>>>>
>     >>>>>>>>>> --
>     >>>>>>>>>> hans.zandbelt@zmartzone.eu
>     >>>>>>>>>> ZmartZone IAM - www.zmartzone.eu
>     >>>>>>>>>> _______________________________________________
>     >>>>>>>>>> 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
>     >>>>
>     >>>
>     >>
>     >
>     >    _______________________________________________
>     >    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
>