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

Dick Hardt <dick.hardt@gmail.com> Mon, 02 March 2020 13:20 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 BF5273A0BA9 for <oauth@ietfa.amsl.com>; Mon, 2 Mar 2020 05:20:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 I99k3csVy-7l for <oauth@ietfa.amsl.com>; Mon, 2 Mar 2020 05:20:06 -0800 (PST)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 80EA03A0BBD for <oauth@ietf.org>; Mon, 2 Mar 2020 05:20:05 -0800 (PST)
Received: by mail-lj1-x22c.google.com with SMTP id a12so10642103ljj.2 for <oauth@ietf.org>; Mon, 02 Mar 2020 05:20:05 -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=msSGCSM0rxykK4Y1qpDvKrmv+yDWxtxQ5O7HAD+V6HI=; b=G8XtaLhxvHUQghGJjP3s1ghIWa83IRxJLX1a2PoH1sQhUIiNTRjaiKK5lySDtFS7Z0 wJHjcI0MJXwRsgvYkOp7S9FPHbwM3KJ9keFMx0s3TTKU83DlTB/9taER1caf+cWZ2OWa l98nUp4u6S9KZXHrLmo1NdkHmdAG/CiwCEzDP4wkcTcqQllgABpsVa/qL+0MMYsUF7sD yGyMH0M9eZZuhUn+u5GDV3PWY+/JAUJD+EWUtumvW9a9mZEOFj5EUXU3v/rE0CfAvZTh GPIwE2kZrt6LXWw2jpG/NplC+0RUkjLorIICaNaaM5rf7tHCcZiAjvxe/RIUtdjKjHe5 Un1Q==
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=msSGCSM0rxykK4Y1qpDvKrmv+yDWxtxQ5O7HAD+V6HI=; b=rEVP1nkwdIYX0PfpitH0kSfNtFEW+kedBh+5LS3YkqVs6mYUgmXT2smSgXc9gkY7KG 6b3D1FhQqN7H0ZADcXcPrv9EBluV4TpL+Xj1q2WaEo5kPUuTSAkjVYs1Hv5wOGnHb0Hv xE60u34LGSuPRwUhBekP+PGGTyyrpX11WG99R+MEURKOUauEOJUC5YidhXynNk7d8dul 7YmgPGFYzpXHX9kROSB84aPYQRa4Lxlf332vTDKtxQXwhnePCxnS7KoetHqfssRpqXMw DLV0kw02IPpHHChSAQwZFtNcRy50mBdydY0ZJRToeviNof9/S2pBAUhqy7IZxd20wnSM 5QaA==
X-Gm-Message-State: ANhLgQ17qdxbNh95R4H71lupEVCaRjjfJm7Hi31pSnMrQ4fIF9uApSC1 BoEz9FdRhDm3619M5J+m2reajwIcK0jTjRquizM=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vu1ddaWnW/6SBqTvgi13GuFyYpX8G6RDvDm8b1W?= =?utf-8?q?7j4e7t/byWtM1Huol0sMO7cgVTKwrjzH2r7VSBvCEnMnGlo=3D?=
X-Received: by 2002:a2e:570f:: with SMTP id l15mr11797929ljb.236.1583155203467; Mon, 02 Mar 2020 05:20:03 -0800 (PST)
MIME-Version: 1.0
References: <CAO7Ng+uQo1zTpTHLoxSiG4Px5Ohv4pEuen-jfDKz2CqXgTh8yQ@mail.gmail.com> <16D918BA-1466-4906-A696-9F7598616F4E@independentid.com>
In-Reply-To: <16D918BA-1466-4906-A696-9F7598616F4E@independentid.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Mon, 2 Mar 2020 05:19:36 -0800
Message-ID: <CAD9ie-v2KpjMgZrHsDmdDgKp1=ScDQvVWepfd7WTv4xGz2Mzkg@mail.gmail.com>
To: Phillip Hunt <phil.hunt@independentid.com>
Cc: Dominick Baier <dbaier@leastprivilege.com>, Nat Sakimura <sakimura@gmail.com>, Matthew De Haast <matt=40coil.com@dmarc.ietf.org>, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, "oauth@ietf.org" <oauth@ietf.org>, "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="00000000000086eca2059fdf0bc7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/eEs8ADWim8QkzQaLELZKKXoMO_Y>
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: Mon, 02 Mar 2020 13:20:19 -0000

That sounds like a good addition to a separate document Phil.
ᐧ

On Sun, Mar 1, 2020 at 8:33 AM Phillip Hunt <phil.hunt@independentid.com>
wrote:

> Why not just require service accounts to use mutually acceptable http
> method of authentication?  Eg instead id/password, service acnt client
> could use mtls auth or http basic or some other method.
>
> AFAIK this is already widely done.
>
> Is there so much interop value that specifying only the weakest form of
> authentication is warranted?
>
> Phil
>
> On Mar 1, 2020, at 4:09 AM, Dominick Baier <dbaier@leastprivilege.com>
> wrote:
>
> 
> 2) write an OAuth 2.1 extension for service account grants. (the grant
> type could continue to be "password", but now clearly in the context of a
> service account in a different document)
>
> IMHO - if such a thing gets defined, it should be a separate document.
> Keep 2.1 as simple as possible.
>
> ———
> Dominick Baier
>
> On 28. February 2020 at 22:04:10, Dick Hardt (dick.hardt@gmail.com) wrote:
>
> It looks like there is consensus to remove ROPC for a user -- but that the
> password grant is not a bad practice for service accounts. That leads to
> providing clarity on service accounts.
>
> 1) add service account grant to the OAuth 2.1 document
>
> 2) write an OAuth 2.1 extension for service account grants. (the grant
> type could continue to be "password", but now clearly in the context of a
> service account in a different document)
>
> With the goal of OAuth 2..1 being a capture of all the best practices, (2)
> makes more sense as it could discuss all aspects of service accounts
> including mapping a client to a service account.
>
> What do others think?
>
>
> ᐧ
>
> On Tue, Feb 25, 2020 at 6:17 AM Nat Sakimura <sakimura@gmail.com> wrote:
>
>> Let us do it then and deprecate ROPC.
>> There definitely are use-cases that need this pattern around me as well,
>> but we are using JWT bearer grant instead. Standardizing the behavior is
>> good. I am fine with new service_account grant type as well, btw.
>>
>> Nat
>> 2020年2月25日 20:41 +0900、Neil Madden <neil.madden@forgerock.com> のメール:
>>
>> I’d be open to defining a new service_account grant type and
>> removing/deprecating the ROPC grant. I’d also be happy if we just said that
>> service account flows should use the JWT bearer grant, and we document the
>> best practices around that and encourage client libs to implement support
>> for it.
>>
>> Should there be a dedicated draft for best practices for
>> service-to-service usage?
>>
>> — Neil
>>
>> On 25 Feb 2020, at 00:13, Aaron Parecki <aaron@parecki.com> wrote:
>>
>> I think we might be going about this discussion the wrong way.
>>
>> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell <bcampbell=
>> 40pingidentity.com@dmarc.ietf.org> wrote:
>> Concur with the sentiment expressed by Neil here.
>>
>> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden <neil.madden@forgerock.com>
>> wrote:
>> I’m not really sure the WG should be telling people what they “ought to
>> be doing” unless we have concrete security or interoperability reasons for
>> doing so.
>>
>> I 100% agree that the job of a standard is not to tell people "what they
>> ought to be doing". Instead, a standard is more about documenting the
>> current state of the art as deployed in existing implementations.
>>
>> With that in mind, I think that leaves us with two concrete problems with
>> the password grant:
>>
>> 1) The actual problem with the password grant is end users entering
>> passwords in applications, which the group (mostly) agrees on
>> 2) People are re-appropriating the password grant for things like service
>> accounts or backends that are inflexible, not actually using it for end
>> user credentials
>>
>> So it seems like there's actually something missing from OAuth which is
>> leading people to find the password grant and use that because it's the
>> only thing that most closely fits their existing model. It seems like we'd
>> be better off defining a new extension that captures the use case people
>> are actually doing, instead of encouraging the continuing use of the
>> password grant for this purpose.
>>
>> ----
>> Aaron Parecki
>> aaronparecki.com
>> @aaronpk
>>
>>
>>
>> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell <bcampbell=
>> 40pingidentity.com@dmarc.ietf.org> wrote:
>> Concur with the sentiment expressed by Neil here.
>>
>> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden <neil.madden@forgerock.com>
>> wrote:
>> I’m not really sure the WG should be telling people what they “ought to
>> be doing” unless we have concrete security or interoperability reasons for
>> doing so.
>>
>> I also don’t agree that people doing this are doing anything wrong. I
>> don’t always agree with what our customers do, but I’ve learnt over the
>> years not to second-guess their reasons for doing it.
>>
>> Are Google wrong for using the JWT bearer grant (not client credentials)
>> and service accounts? They even go so far as to say “scopes are not a
>> security mechanism” [1] and tell people to use service account roles
>> instead. (Precisely because they also support non-OAuth auth methods, which
>> bypass any scopes).
>>
>> Are we really going to tell them to rewrite it all to use the client
>> credentials grant?
>>
>> [1]:
>> https://cloud.google.com/compute/docs/access/service-accounts#accesscopesiam
>>
>> On 21 Feb 2020, at 21:04, Justin Richer <jricher@mit.edu> wrote:
>>
>> +1. I’ve seen this anti-pattern deployed all over the place, and it’s
>> time to get rid of it and send people toward what they really ought to be
>> doing.
>>
>> Another thing I’ve seen is using different service accounts to get
>> different sets of access for one client — if you’re doing that, you’ve got
>> a client pretending to do two different things, or your APIs should be
>> using scopes to differentiate access instead of client/user identity.
>>
>> — Justin
>>
>> On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle <richanna=
>> 40amazon.com@dmarc.ietf.org> 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>om>:
>>
>> 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
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited..
>> If you have received this communication in error, please notify the sender
>> immediately by e-mail and delete the message and any file attachments from
>> your computer. Thank you._______________________________________________
>> 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
>
>