Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

Nat Sakimura <sakimura@gmail.com> Tue, 16 February 2016 00:38 UTC

Return-Path: <sakimura@gmail.com>
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 7E37F1A8AD4 for <oauth@ietfa.amsl.com>; Mon, 15 Feb 2016 16:38:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_MESSAGE=0.001, SPF_PASS=-0.001] 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 zUu_Gpu484aI for <oauth@ietfa.amsl.com>; Mon, 15 Feb 2016 16:38:16 -0800 (PST)
Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (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 4AB7B1A92B3 for <oauth@ietf.org>; Mon, 15 Feb 2016 16:38:16 -0800 (PST)
Received: by mail-qg0-x22a.google.com with SMTP id b35so122169276qge.0 for <oauth@ietf.org>; Mon, 15 Feb 2016 16:38:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=+H7RYFekH+oVjtX3Eio8doNirH1Bcyg9w24u1SGZiCw=; b=TZSs2svufln+Y+tWuuxIuz/ivAmR4cI54ISaDFqwfgJ2c86fTZsJOTYW9kZSTxYQZ4 n0cnqR3bn5LyJ6bDdW/0qVc7BI/H9mlgQ0hHRhplUuxQZA5fc5zV7rcidZJrm/+ttP/c WNMs1/kp3L/sV4wh929GDAcIHzXvReoT52qCXQqH/F8Y3K1hJdtmSU95NjAIIVXqxJMP MmVUYPYiZ5ZYDN6LLhifQMFtxO4WU35tl4QQsnWzclabmrgzZEDkHOaw+dTloqJPkhTO NYuLpGGphtjodhueR5tRSCZJMlUpOpiHIR7SiIIio5tV120wPSgK3HYhDrFWd6a+EW8L 1vDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=+H7RYFekH+oVjtX3Eio8doNirH1Bcyg9w24u1SGZiCw=; b=X6KeCGeGWxTsJFWsNMwEBXlZ7MhORallozKuRKao//DMA8Tbs+3NPay9HFEEnJfxNX XqBfNN0Guse2bpW/USiz8sLbTTOJ3COs/MB0Jo2yKpDaWS/u7Zvf6Zn9WvQ1Eu3LeYMa JEO72v5U5vSTbHFcZefYHen/EDtA0xSnGVDmzvfyPIDaERsIhv7B0qqFQFZuLjOa54Jy bm8H8KG+AFz4RbcDTer8dyTsSE+OHkIv5+Bsi0FRXIZ+UTdJRqiVF2cY8FAdBbgI8AON FtCvuXbWXmMpFKHNuiQHORa524giHEb6ShLAqDAw/IbGo51zPdx8N9y8LFQg85mhZLhQ 9XMg==
X-Gm-Message-State: AG10YOQJMw0AwODZH3q/qHUxh7zBlFWsMrWobXxkqcLtFS8dRV+fWsZAwaWwKZoBLC/hSuxT5fHBqz1sku6hAQ==
X-Received: by 10.140.22.139 with SMTP id 11mr24413753qgn.34.1455583095363; Mon, 15 Feb 2016 16:38:15 -0800 (PST)
MIME-Version: 1.0
References: <BL2PR03MB433E8ACD3609AF27BB9315CF5AA0@BL2PR03MB433.namprd03.prod.outlook.com> <rbrketsshbps53oogq7ovmrw.1455379158417@com.syntomo.email> <D1B1293D-2811-466E-8F10-94AA3F55F82F@oracle.com> <95DA4443-B94B-4A99-ADE4-4C238DDAB1AD@mit.edu> <BL2PR03MB433BDBFABB72EE4CFD14925F5AA0@BL2PR03MB433.namprd03.prod.outlook.com> <CAAP42hA=Ja5eaiWKQPzxv2Y38bhVyJt6+KPRSfFkN=VCsCxT_A@mail.gmail.com> <56C0816B.8070005@lodderstedt.net> <CAAP42hD_uU=Cu-dVk7G6Cz8FdGNNst2Ohw0_F82MsGM1fij_1w@mail.gmail.com> <59471C32-2F08-41A1-9744-EC603C6DD97D@manicode.com> <FA50F4EF-CC4F-442B-B185-39060932784C@ve7jtb.com> <CE2CBBA6-7AEA-4ACF-8913-4D5ED9EAAB8E@oracle.com>
In-Reply-To: <CE2CBBA6-7AEA-4ACF-8913-4D5ED9EAAB8E@oracle.com>
From: Nat Sakimura <sakimura@gmail.com>
Date: Tue, 16 Feb 2016 00:38:04 +0000
Message-ID: <CABzCy2D06hA-5PPu_JypY1FGg5xDXWSH7=_wZwbHdTTuz2dw2A@mail.gmail.com>
To: "Phil Hunt (IDM)" <phil.hunt@oracle.com>, John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary=001a11c151e25720e7052bd859bb
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/5h-TnL3ZuYeWjffbTg75Fx49ryY>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
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, 16 Feb 2016 00:38:22 -0000

+1 Those login and logout ceremonies giving false impression of security
probably will diminish its importance pretty quickly. I recon those more as
a privacy feature than security.
2016年2月16日(火) 9:35 Phil Hunt (IDM) <phil.hunt@oracle.com>om>:

> +1
>
>
> Phil
>
> On Feb 15, 2016, at 16:50, John Bradley <ve7jtb@ve7jtb.com> wrote:
>
> The question is what counts as re-authentication.
>
> It may be that the environment is changing.  Re-prompting for a password
> in many cased just tells you the user has a form filler.
>
> It may be better to use risk based factors such as prompting for a pin, or
> using a local passive biometric, eg has the phone got screen lock and is it
> in proximity to the persons smart watch etc.
>
> What google seems to be doing is using the amr to say how they did the
> last authentication and leave it up to the client to decide if it is good
> enough.
>
> Simple always ask for a password may no longer provide the security that
> most people think it is giving.
>
> Looking at what enterprise customers are asking for, they are becoming
> more concerned with checking the MDM posture of the device at
> authentication.
>
> This is a larger conversation about authentication context and methods.
>
> The establishment of the amr registry will provide a place to document a
> part of this, however authentication context (there is already a registry)
> and amr values themselves are probably out of scope for this WG.
>
> John B.
>
>
> On Feb 15, 2016, at 8:22 PM, Jim Manico <jim@manicode.com> wrote:
>
> Polite comment, Google in general is pretty "open" about session
> management in general - long idle timeout and no apparent absolute timeout.
> For a bank or other organization that produces high risk software, this is
> not standard practice. Re-authentication is a critical security boundary,
> not prompting the user for re-authentication credentials is unacceptable in
> those environments.
>
> I may be jumping in out of context, but fair?
>
> --
> Jim Manico
> @Manicode
> +1 (808) 652-3805
>
> On Feb 15, 2016, at 3:36 PM, William Denniss <wdenniss@google.com> wrote:
>
> We return 'amr' claims in ID Tokens if "max_age" is requested (per OpenID
> Connect), e.g.:
>
>
> https://accounts.google.com/o/oauth2/auth?redirect_uri=https%3A%2F%2Fdevelopers.google.com%2Foauthplayground&response_type=code&client_id=407408718192.apps.googleusercontent.com&scope=openid+profile&approval_prompt=force&access_type=offline&max_age=1
>
> The reason we do this is to be explicit about how we are processing the
> "max_age" reauth request, specifically that we don't always prompt the user
> to reauthenticate directly (but do perform in-session risk analysis).
>
> I can see us potentially using the more generic amr values like "user",
> and "mfa" but we will probably avoid very specific ones like "sms" or "otp"
> to avoid brittle relationships with RPs. That said, I don't object to those
> being in the registry, perhaps there is value in some tightly coupled
> enterprise configurations.
>
>
> On Sun, Feb 14, 2016 at 5:30 AM, Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
>
>> Hi Denniss,
>>
>> out of curiosity: Does Google use amr values?
>>
>> best regards,
>> Torsten.
>>
>>
>> Am 14.02.2016 um 02:40 schrieb William Denniss:
>>
>>
>>
>> On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones <Michael.Jones@microsoft.com
>> > wrote:
>>
>>> It's an acceptable fallback option if the working group decides it
>>> doesn't want to register the values that are already in production use at
>>> the time we establish the registry. But add William points out, Google is
>>> already using some of these values. Microsoft is using some of them. The
>>> OpenID MODRNA specs are using some of them. So it seems more efficient to
>>> register them at the same time.
>>>
>>> That would be my preference.
>>>
>>
>> +1, it is also my preference to register the current values.
>>
>> I don't see any harm in the spec that establishes the registry also
>> seeding it with all known values in use at the time of drafting, regardless
>> of the group that originally specified them. Makes the original spec more
>> useful, and avoids the need to submit each value for consideration
>> separately – they can be all be reviewed at the same time.
>>
>>
>> From: Justin Richer <jricher@mit.edu>
>>> Sent: ‎2/‎13/‎2016 11:11 AM
>>> To: Phil Hunt <phil.hunt@oracle.com>
>>>
>>> Cc: <oauth@ietf.org><oauth@ietf.org> <oauth@ietf.org>
>>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call
>>> for Adoption Finalized
>>>
>>> Can we just do that, then? Seems to be the easiest way to address
>>> various needs and concerns.
>>>
>>>  — Justin
>>>
>>> On Feb 13, 2016, at 11:08 AM, Phil Hunt (IDM) <phil.hunt@oracle.com>
>>> wrote:
>>>
>>> Yes
>>>
>>> Phil
>>>
>>> On Feb 13, 2016, at 07:59, " <torsten@lodderstedt.net>
>>> torsten@lodderstedt.net" <torsten@lodderstedt.net> wrote:
>>>
>>> So basically, the RFC could also just establish the new registry and
>>> oidf could feel in the values?
>>>
>>> (just trying to understand)
>>>
>>>
>>> -------- Originalnachricht --------
>>> Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call for
>>> Adoption Finalized
>>> Von: Mike Jones < <Michael.Jones@microsoft.com>
>>> Michael.Jones@microsoft.com>
>>> An: torsten@lodderstedt.net,John Bradley < <ve7jtb@ve7jtb.com>
>>> ve7jtb@ve7jtb.com>
>>> Cc: oauth@ietf.org
>>>
>>> The context that most people on this thread probably don’t have is that
>>> an IANA registry can only be established by an RFC.  Non-RFC
>>> specifications, such as OpenID specifications, can **register** values
>>> in a registry, but they cannot **establish** a registry.  The OpenID
>>> Foundation inquired about this with the IETF before OpenID Connect was
>>> finalized and learned that its specifications could not establish IANA
>>> registries.  Otherwise, they would have.
>>>
>>>
>>> Instead, RFCs need to be created to establish registries – even for
>>> values first defined in non-RFC specifications.  This specification is one
>>> example of doing this.
>>>
>>>
>>>                                                           -- Mike
>>>
>>>
>>>
>>> *From:* OAuth [ <oauth-bounces@ietf.org>mailto:oauth-bounces@ietf.org
>>> <oauth-bounces@ietf.org>] *On Behalf Of * <torsten@lodderstedt.net>
>>> torsten@lodderstedt.net
>>> *Sent:* Saturday, February 13, 2016 6:37 AM
>>> *To:* John Bradley < <ve7jtb@ve7jtb.com>ve7jtb@ve7jtb.com>
>>> *Cc:* <oauth@ietf.org>oauth@ietf.org
>>> *Subject:* Re: [OAUTH-WG] Authentication Method Reference Values: Call
>>> for Adoption Finalized
>>>
>>>
>>> We clearly have this problem between oauth and oidc. Just take a look at
>>> the discovery thread.
>>>
>>> According to you argument I see two options:
>>> (1) amr stays an oidc claim, is used in oidc only and the oauth wg just
>>> publishes the registry entries. In this case, the spec should clearly
>>> explain this.
>>> (2) amr is of any use in oauth (although it has been invented in oidc) -
>>> than define it and motivate it's use in oauth in this spec.
>>>
>>> Right now, I think it creates the impression oauth is for
>>> authentication.
>>>
>>>
>>>
>>> -------- Originalnachricht --------
>>> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for
>>> Adoption Finalized
>>> Von: John Bradley < <ve7jtb@ve7jtb.com>ve7jtb@ve7jtb.com>
>>> An: torsten@lodderstedt.net
>>> Cc: roland.hedberg@umu.se,oauth@ietf.org
>>>
>>> This is not a issue between oauth and OIDC.
>>>
>>>
>>> This has to do with the registry for JWT being in OAuth.   Many
>>> protocols that use JWT are going to want to register claims.
>>>
>>> We can’t ask them to all move the parts of there specs that use JWT to
>>> OAuth.
>>>
>>>
>>> Perhaps JWT should have been part of JOSE, but that is water under the
>>> bridge.
>>>
>>>
>>> The OAuth WG is responsible for JWT and it’s registry, and we will need
>>> to deal with registering claims.
>>>
>>>
>>> I guess that we can tell people that they need to publish the specs
>>> defining the claims someplace else, and just do the registry part.
>>>
>>> However doing that will probably not improve interoperability and
>>> understanding.
>>>
>>>
>>> This document defines the claim for JWT in general.  We still have
>>> almost no documentation in the WG about what a JWT access token would
>>> contain other than the POP work.
>>>
>>>
>>> John B.
>>>
>>> On Feb 13, 2016, at 9:18 AM, <torsten@lodderstedt.net>
>>> torsten@lodderstedt.net wrote:
>>>
>>>
>>> I basically support adoption of this document. Asserting authentication
>>> methods in access tokens (in this case in JWTS format) is reasonable. We
>>> use it to pass information about the authentication performed prior issuing
>>> an access token to the _resource_ server.
>>>
>>> What worries me is the back and forth between oauth and oidc. The amr
>>> claim is defined in oidc (which sits on top of oauth) but the oauth wg
>>> specifies the registry? Moreover, the current text does not give a
>>> rationale for using amr in context of oauth.
>>>
>>> As a WG we need to find a clear delineation between both protocols,
>>> otherwise noone will really understand the difference and when to use what.
>>> We create confusion!
>>>
>>> For this particular draft this means to either move amr to oauth or the
>>> registry to oidc.
>>>
>>> best regards,
>>> Torsten.
>>>
>>>
>>>
>>> -------- Ursprüngliche Nachricht --------
>>> Von: Roland Hedberg < <roland.hedberg@umu.se>roland.hedberg@umu.se>
>>> Gesendet: Friday, February 12, 2016 05:45 PM
>>> An: <oauth@ietf.org>oauth@ietf.org
>>> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for
>>> Adoption Finalized
>>>
>>> +1
>>>
>>> > 12 feb 2016 kl. 16:58 skrev John Bradley < <ve7jtb@ve7jtb.com>
>>> ve7jtb@ve7jtb.com>gt;:
>>> >
>>> > +1 to adopt this draft.
>>> >
>>> >> On Feb 12, 2016, at 3:07 AM, Mike Jones <
>>> <Michael.Jones@microsoft.com>Michael.Jones@microsoft.com> wrote:
>>> >>
>>> >> Draft -05 incorporates the feedback described below - deleting the
>>> request parameter, noting that this spec isn't an encouragement to use
>>> OAuth 2.0 for authentication without employing appropriate extensions, and
>>> no longer requiring a specification for IANA registration.  I believe that
>>> it’s now ready for working group adoption.
>>> >>
>>> >>                                                           -- Mike
>>> >>
>>> >> -----Original Message-----
>>> >> From: OAuth [ <oauth-bounces@ietf.org>mailto:oauth-bounces@ietf.org
>>> <oauth-bounces@ietf.org>] On Behalf Of Hannes Tschofenig
>>> >> Sent: Thursday, February 4, 2016 11:23 AM
>>> >> To: <oauth@ietf.org>oauth@ietf.org
>>> >> Subject: [OAUTH-WG] Authentication Method Reference Values: Call for
>>> Adoption Finalized
>>> >>
>>> >> Hi all,
>>> >>
>>> >> On January 19th I posted a call for adoption of the Authentication
>>> Method Reference Values specification, see
>>> <http://www.ietf.org/mail-archive/web/oauth/current/msg15402.html>
>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15402.html
>>> >>
>>> >> What surprised us is that this work is conceptually very simple: we
>>> define new claims and create a registry with new values. Not a big deal but
>>> that's not what the feedback from the Yokohama IETF meeting and the
>>> subsequent call for adoption on the list shows. The feedback lead to mixed
>>> feelings and it is a bit difficult for Derek and myself to judge consensus.
>>> >>
>>> >> Let me tell you what we see from the comments on the list.
>>> >>
>>> >> In his review at
>>> >> <http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html>
>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html James
>>> Manger asks for significant changes. Among other things, he wants to remove
>>> one of the claims. He provides a detailed review and actionable items.
>>> >>
>>> >> William Denniss believes the document is ready for adoption but
>>> agrees with some of the comments from James. Here is his review:
>>> >> <http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html>
>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html
>>> >>
>>> >> Justin is certainly the reviewer with the strongest opinion. Here is
>>> one of his posts:
>>> >> <http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html>
>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html
>>> >>
>>> >> Among all concerns Justin expressed the following one is actually
>>> actionable IMHO: Justin is worried that reporting how a person
>>> authenticated to an authorization endpoint and encouraging people to use
>>> OAuth for authentication is a fine line. He believes that this document
>>> leads readers to believe the latter.
>>> >>
>>> >> John agrees with Justin in
>>> >> <http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html>
>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html that
>>> we need to make sure that people are not mislead about the intention of the
>>> document. John also provides additional comments in this post to the
>>> >> list:
>>> <http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html>
>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html
>>> >> Most of them require more than just editing work. For example,
>>> methods listed are really not useful,
>>> >>
>>> >> Phil agrees with the document adoption but has some remarks about the
>>> registry although he does not propose specific text. His review is here:
>>> >> <http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html>
>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html
>>> >>
>>> >> With my co-chair hat on: I just wanted to clarify that registering
>>> claims (and values within those claims) is within the scope of the OAuth
>>> working group. We standardized the JWT in this group and we are also
>>> chartered to standardize claims, as we are currently doing with various
>>> drafts. Not standardizing JWT in the IETF would have lead to reduced
>>> interoperability and less security. I have no doubts that was a wrong
>>> decision.
>>> >>
>>> >> In its current form, there is not enough support to have this
>>> document as a WG item.
>>> >>
>>> >> We believe that the document authors should address some of the
>>> easier comments and submit a new version. This would allow us to reach out
>>> to those who had expressed concerns about the scope of the document to
>>> re-evaluate their decision. A new draft version should at least address the
>>> following issues:
>>> >>
>>> >> * Clarify that this document is not an encouragement for using OAuth
>>> as an authentication protocol. I believe that this would address some of
>>> the concerns raised by Justin and John.
>>> >>
>>> >> * Change the registry policy, which would address one of the comments
>>> from James, William, and Phil.
>>> >>
>>> >> Various other items require discussion since they are more difficult
>>> to address. For example, John noted that he does not like the use of
>>> request parameters. Unfortunately, no alternative is offered. I urge John
>>> to provide an alternative proposal, if there is one. Also, the remark that
>>> the values are meaningless could be countered with an alternative proposal.
>>> James wanted to remove the "amr_values" parameter.
>>> >> Is this what others want as well?
>>> >>
>>> >> After these items have been addressed we believe that more folks in
>>> the group will support the document.
>>> >>
>>> >> Ciao
>>> >> Hannes & Derek
>>> >>
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> OAuth mailing list
>>> >> <OAuth@ietf.org>OAuth@ietf.org
>>> >> <https://www.ietf.org/mailman/listinfo/oauth>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>> >
>>> > _______________________________________________
>>> > OAuth mailing list
>>> > <OAuth@ietf.org>OAuth@ietf.org
>>> > <https://www.ietf.org/mailman/listinfo/oauth>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> — Roland
>>>
>>> ”Everybody should be quiet near a little stream and listen."
>>> >From ’Open House for Butterflies’ by Ruth Krauss
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> <OAuth@ietf.org>OAuth@ietf.org
>>> <https://www.ietf.org/mailman/listinfo/oauth>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> <OAuth@ietf.org>OAuth@ietf.org
>>> <https://www.ietf.org/mailman/listinfo/oauth>
>>> 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 listOAuth@ietf.orghttps://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
>