Re: [OAUTH-WG] Need for Extending OAuth with AuthN (was Re: Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt)

Nat Sakimura <sakimura@gmail.com> Fri, 02 August 2013 04:34 UTC

Return-Path: <sakimura@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 18D5421E8054 for <oauth@ietfa.amsl.com>; Thu, 1 Aug 2013 21:34:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.565
X-Spam-Level:
X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XORVNyuWfG5S for <oauth@ietfa.amsl.com>; Thu, 1 Aug 2013 21:34:40 -0700 (PDT)
Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 79D4621E805D for <oauth@ietf.org>; Thu, 1 Aug 2013 21:34:39 -0700 (PDT)
Received: by mail-la0-f54.google.com with SMTP id ea20so119308lab.41 for <oauth@ietf.org>; Thu, 01 Aug 2013 21:34:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nIc8elgx4w0K+IZ4CxWO9j6iNghgJn+Bgi/ymFPbLvQ=; b=0e53ydo5vEFJeiresSlA7uEV2m03DlxNQ9LcnsPGN48P6TEp2xetf/qZRdIDtDFgZ0 nERPgQa7kS/0Zwzo2bsOt3sj/GZPkQzHnv1vzbyG5lqstJxE0fGcSNyWLhsh7VjcjKbS AG6vMdX614dHE1ANyFpqzMjdqxkAe2AZytdBchCxANozdDJ1nRA2rfuBmgAJgR2gvfxO 2UCPmuh/Hxm2d3ANfdZzICzHeD95qh+TYiOiFDYJ/LRYq0dF0AequoPfh+Be/J2fF8Eo c/nxHcBBkMr0LGks20LZ1mco9h4HolZqSFs/AoBuL84Qb3nCgTO/Xx6CKd6BiZm6feTN 8q7g==
MIME-Version: 1.0
X-Received: by 10.112.89.42 with SMTP id bl10mr2654810lbb.77.1375418078248; Thu, 01 Aug 2013 21:34:38 -0700 (PDT)
Received: by 10.112.134.38 with HTTP; Thu, 1 Aug 2013 21:34:37 -0700 (PDT)
In-Reply-To: <6F19AC80-0BB9-4387-AA77-77D02CE1E772@oracle.com>
References: <787A2184-CE90-49F4-ABB6-B8D049AE3941@oracle.com> <E2282016-1953-48A4-B0AC-7F138D29AB80@oracle.com> <BAB6DA63-5831-49D0-8CB9-13CF57F78806@ve7jtb.com> <CABzCy2C=DXtFUOZh=55xH_BwMz1Z8gb2ShUHAG7ZmATtc4E4zw@mail.gmail.com> <51F983E3.1020400@oracle.com> <1375307375.98370.YahooMailNeo@web142804.mail.bf1.yahoo.com> <5c5c607231e644f697c5a60b75688013@BY2PR03MB189.namprd03.prod.outlook.com> <5D020B1E-531D-444E-A492-046D444D48D2@mitre.org> <e68801da9fa547c69fee43b9cd7b22b8@BY2PR03MB189.namprd03.prod.outlook.com> <2117136733141454493@unknownmsgid> <8E6F38BA-E6BF-40E5-818A-45F506BB181D@mitre.org> <f4b99e49fbdd4e22b19391cdb720b15d@BY2PR03MB189.namprd03.prod.outlook.com> <CABzCy2Aou0eMqHKjxOh01mtfzQ8-mvU5BHF84kHHsnPsO3di=Q@mail.gmail.com> <6F19AC80-0BB9-4387-AA77-77D02CE1E772@oracle.com>
Date: Fri, 02 Aug 2013 06:34:37 +0200
Message-ID: <CABzCy2BA-fXy86NU+vZd96jV9yVo9GEBAmm_AoMeZoR-ECgyyQ@mail.gmail.com>
From: Nat Sakimura <sakimura@gmail.com>
To: Phil Hunt <phil.hunt@oracle.com>
Content-Type: multipart/alternative; boundary="001a11c374a6f8c7af04e2ef79fd"
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Need for Extending OAuth with AuthN (was Re: Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Fri, 02 Aug 2013 04:34:43 -0000

Not necessarily. Why would it be inappropriate?

I call it NIH syndrome.
Respecting the work which is done outside is a good thing.
Just taking the content and taking a credit for it is a bad practice.

Forking is also bad.



2013/8/2 Phil Hunt <phil.hunt@oracle.com>

> OpenId specs can depend on oAuth. Having OAuth depend on OpenId is not
> appropriate here.
>
> Phil
>
> On 2013-08-01, at 18:07, Nat Sakimura <sakimura@gmail.com> wrote:
>
> Like Bill says, it can just be a profile of OpenID Connect.
> IETF specs already references OpenID Foundation specs.
> It should not be a problem.
> I do not think we want to folk.
>
>
> 2013/8/1 Anthony Nadalin <tonynad@microsoft.com>
>
>>  I believe it beneficial to have a common format and common values, and
>> 1 way to handle the format and values. I believe that having this in oauth
>> is beneficial, I believe that it would also be beneficial for OpenID if
>> this were in oauth. There are cases for signed and unsigned formats. ****
>>
>> ** **
>>
>> *From:* Richer, Justin P. [mailto:jricher@mitre.org]
>> *Sent:* Thursday, August 1, 2013 7:15 AM
>> *To:* Nat Sakimura
>> *Cc:* Anthony Nadalin; Bill Mills; Prateek Mishra; oauth@ietf.org WG
>>
>> *Subject:* Re: [OAUTH-WG] Need for Extending OAuth with AuthN (was Re:
>> Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt)***
>> *
>>
>>  ** **
>>
>> Also, it's (optionally) a token in the proposed document we're discussing
>> (§2.4.1), which means there are two ways to parse the same information.
>> OIDC uses JWTs for everything, signed and unsigned. This means that OIDC is
>> actually simpler from an implementation perspective, wouldn't you say?
>> Instead of having two parsers, you have one to cover both cases.  ****
>>
>> ** **
>>
>> (And given your tendency to throw signed assertions at every problem, I
>> would have thought that you'd prefer this anyway.) ****
>>
>> ** **
>>
>>  -- Justin****
>>
>> ** **
>>
>> On Aug 1, 2013, at 9:40 AM, Nat Sakimura <sakimura@gmail.com>****
>>
>>  wrote:****
>>
>>
>>
>> ****
>>
>>  Yes, it is a Token. ****
>>
>> No, it does not have to be signed. ****
>>
>> ** **
>>
>> As to be a token or not to be a token question, it has been discussed in
>> the WG before, and if I remember correctly,  Microsoft argued for token
>> saying that it is just base64 decoding and I lost there.  ****
>>
>> Nat****
>>
>>
>> On Aug 1, 2013, at 14:24, Anthony Nadalin <tonynad@microsoft.com> wrote:*
>> ***
>>
>> You can’t do this, first openid uses a token and second it’s signed,
>> third there is no specification to just return a authentication JSON
>> structure****
>>
>>  ****
>>
>> *From:* Richer, Justin P. [mailto:jricher@mitre.org <jricher@mitre.org>]
>> *Sent:* Thursday, August 1, 2013 5:15 AM
>> *To:* Anthony Nadalin
>> *Cc:* Bill Mills; Prateek Mishra; Nat Sakimura; oauth@ietf.org WG
>> *Subject:* Re: [OAUTH-WG] Need for Extending OAuth with AuthN (was Re:
>> Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt)***
>> *
>>
>>  ****
>>
>> Tony, you can already return the authn result from the token request (we
>> discussed this specifically in May as I recall). That's what the "idtoken"
>> and "code idtoken" responses are for in OpenID Connect. The proposed draft
>> is nearly a duplicate of the core functionality of OIDC. ****
>>
>>  ****
>>
>>  -- Justin****
>>
>>  ****
>>
>> On Aug 1, 2013, at 7:31 AM, Anthony Nadalin <tonynad@microsoft.com>****
>>
>>  wrote:****
>>
>> ** **
>>
>>  The proposal does not duplicate what OpenID does, there is clear
>> benefit for returning an authentication result in the token request result.
>> This is being proposed as optional JSON structure.****
>>
>>  ****
>>
>> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On
>> Behalf Of *Bill Mills
>> *Sent:* Wednesday, July 31, 2013 2:50 PM
>> *To:* Prateek Mishra; Nat Sakimura
>> *Cc:* oauth@ietf.org WG
>> *Subject:* Re: [OAUTH-WG] Need for Extending OAuth with AuthN (was Re:
>> Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt)***
>> *
>>
>>  ****
>>
>> Rather than extending OAuth for something OpenID already does...  why
>> don't we get a simple informational example doc to show how to implement
>> the most basic OpenID service, which is the same functionality on a
>> standard that's already written?****
>>
>>  ****
>>
>> This is sounding more and mor elike a documentation problem.****
>>
>>  ****
>>    ------------------------------
>>
>> *From:* Prateek Mishra <prateek.mishra@oracle.com>
>> *To:* Nat Sakimura <sakimura@gmail.com>
>> *Cc:* "oauth@ietf.org WG" <oauth@ietf.org>
>> *Sent:* Wednesday, July 31, 2013 2:38 PM
>> *Subject:* [OAUTH-WG] Need for Extending OAuth with AuthN (was Re: Fwd:
>> New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt)****
>>
>>  ****
>>
>> Nat -
>>
>> thanks for the detailed response. I did review the links you sent out but
>> it remained unclear to me which
>> features are MTI and which are not. For example, there is nothing in the
>> Basic Client Profile that suggests
>> that Section 2.3 is optional. I also could not find any definition for "
>> non-dynamic OpenID Connect Server".
>>
>> I dont think there is a need to duplicate portions of the draft
>> specification text in a new document. One solution
>> that was used in SAML 2.0 was to define a conformance document which
>> described several different
>> operational modes and explained how only a small set of features needed
>> to be implemented in certain modes.
>>
>> http://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf
>>
>> There are probably other smarter ways to achieve the same effect.
>>
>> Given this situation, I do think its a reasonable task for the OAuth
>> community to consider the need for
>> a minimal extension to OAuth that accommodates authentication. The
>> community should be made aware that
>> RFC 6749 is being misused for federated authentication, as explained in
>> -
>>
>>
>> http://www.independentid.com/2013/07/simple-authentication-for-oauth-2-what.html
>>
>>
>> and that there doesn't appear to be a simple solution that is currently
>> available. It would be great if it turned
>> out that OpenID Connect offered such a solution but that isn't clear to
>> me.
>>
>> Thx,
>> prateek****
>>
>>  ****
>>
>>   ****
>>
>> Inline: ****
>>
>> 2013/7/31 Prateek Mishra <prateek.mishra@oracle.com>****
>>
>>  Nat -
>>
>> your blog posting is helpful to those of us who are looking for a minimal
>> extension of OAuth with
>> an authenticator.  Many implementors are seeking a modest extension of
>> OAuth, not an entire new protocol
>> stack.   I believe that is the point of Phil Hunt's proposal to the OAuth
>> committee.
>>
>> I do have some questions for about the statements made in the blog -
>>
>> A) Can you direct me to a single OpenID Connect draft specification
>> document where steps 1 and 2 are described?****
>>
>>    ****
>>
>> Actually, it is not a single spec, that the Standard is referencing
>> others. ****
>>
>> The Standard is kind of cluttered because it has 6 response types and
>> three request types in it. ****
>>
>> I suppose it would be much easier for the readers to split them into
>> coherent pieces, though that means duplicate texts. ****
>>
>>  ****
>>
>> The easiest approach here is to read the Basic Client Profile.
>> http://openid.net/specs/openid-connect-basic-1_0-28.html****
>>
>> Then, read OAuth 2.0 Multiple Response Type Encoding Practices
>> http://openid.net/specs/oauth-v2-multiple-response-types-1_0-08.html . **
>> **
>>
>>  ****
>>
>>
>> B) If I implement steps 1 and 2, do I then have a conformant OpenID
>> Connect implementation? Are there no
>> other MTI protocol exchanges in OpenID Connect?****
>>
>>    ****
>>
>> Yes, for a non-dynamic OpenID Connect Server. ****
>>
>>  ****
>>
>> Nat****
>>
>>   ****
>>
>>
>> Thanks,
>> prateek****
>>
>>
>>
>>    ****
>>
>>  ****
>>
>>  I have written a short blog post titled "Write an OpenID Connect server
>> in three simple steps<http://nat.sakimura.org/2013/07/28/write-openid-connect-server-in-three-simple-steps/>
>> ". ****
>>
>>  ****
>>
>> Really, there is not much you need to on top of OAuth 2.0. ****
>>
>>  ****
>>
>> It puzzles me why you need to create a draft with only minor variances in
>> parameter names. ****
>>
>>  ****
>>
>>  e.g., ****
>>
>> session instead of id_token****
>>
>> lat instead of iat****
>>
>> alv instead of acr****
>>
>> etc. ****
>>
>>    ****
>>
>> If you change those parameter names, you will have a conformant profile
>> of OpenID Connect. ****
>>
>>  ****
>>
>> Nat****
>>
>>  ****
>>
>> 2013/7/31 John Bradley <ve7jtb@ve7jtb.com>****
>>
>>  Connect dosen't require a userinfo endpoint.   It is required for
>> interoperability if you are building an open IdP.   For an enterprise type
>> deployment discovery, registration, userifo are all optional.****
>>
>>  ****
>>
>> The server is required to pass the nonce which is equivalent to a request
>> ID through to the JWT if the client sends it in the request.****
>>
>>  ****
>>
>> Justin is correct.****
>>
>>  ****
>>
>> John B.****
>>
>>  ****
>>
>> On 2013-07-30, at 5:30 PM, Phil Hunt <phil.hunt@oracle.com> wrote:****
>>
>>
>>
>> ****
>>
>>   Forgot reply all.
>>
>> Phil****
>>
>>
>> Begin forwarded message:****
>>
>>  *From:* Phil Hunt <phil.hunt@oracle.com>
>> *Date:* 30 July, 2013 17:25:46 GMT+02:00
>> *To:* "Richer, Justin P." <jricher@mitre.org>
>> *Subject:* *Re: [OAUTH-WG] New Version Notification for
>> draft-hunt-oauth-v2-user-a4c-00.txt*****
>>
>>   The whole point is authn only. Many do not want or need the userinfo
>> endpoint.
>>
>> Phil****
>>
>>
>> On 2013-07-30, at 17:17, "Richer, Justin P." <jricher@mitre.org> wrote:**
>> **
>>
>>  What do you mean? You absolutely can implement a compliant OIDC server
>> nearly as simply as this. The things that you're missing I think are
>> necessary for basic interoperable functionality, and are things that other
>> folks using OAuth for authentication have also implemented. Namely:****
>>
>>  ****
>>
>>  - Signing the ID token (OIDC specifies the RS256 flavor of JWS, which is
>> easy to do with JWT). Without a signed and verifiable ID token or
>> equivalent, you're asking for all kinds of token injection problems.****
>>
>>  - Session management requests (max auth age, auth time)****
>>
>>  - Not fall over with other parameters that you don't support (display,
>> prompt, etc).****
>>
>>  ****
>>
>> See here for more information:****
>>
>>  ****
>>
>>  http://openid.net/specs/openid-connect-messages-1_0.html#ServerMTI****
>>
>>  ****
>>
>> Additionally, something that's really important to support is the User
>> Info Endpoint, so you can actually get user profile information beyond just
>> the simple "someone was here" claim -- this was the real value of Facebook
>> Connect from an RP's perspective. Some people will probably want to use
>> SCIM for this, too, and that's fine.****
>>
>>  ****
>>
>>  -- Justin****
>>
>>  ****
>>
>> On Jul 30, 2013, at 10:54 AM, Phil Hunt <phil.hunt@oracle.com>****
>>
>>  wrote:****
>>
>>
>>
>> ****
>>
>>  The oidc specs do not allow this simple an implementation. The spec
>> members have not shown interest in making changes as they say they are too
>> far down the road.****
>>
>>  ****
>>
>> I have tried to make my draft as close as possible to oidc but maybe it
>> shouldn't be clarity wise. I am interested in what the group feels is
>> clearest. ****
>>
>>  ****
>>
>> From an ietf perspective the concern is improper use of the 6749 for
>> authn. Is this a bug or gap we need to address?
>>
>> Phil****
>>
>>
>> On 2013-07-30, at 16:46, "Richer, Justin P." <jricher@mitre.org> wrote:**
>> **
>>
>>  From what I read, you've defined something that uses an OAuth 2 code
>> flow to get an extra token which is specified as a JWT. You named it
>> "session_token" instead of "id_token", and you've left off the User
>> Information Endpoint -- but other than that, this is exactly the Basic
>> Client for OpenID Connect. In other words, if you change the names on
>> things you've got OIDC, but without the capabilities to go beyond a very
>> basic "hey there's a user here" claim. This is the same place that OpenID
>> 2.0 started, and it was very, very quickly extended with SREG, AX, PAPE,
>> and others for it to be useful in the real world of distributed logins.
>> You've also left out discovery and registration which are required for
>> distributed deployments, but I'm guessing that those would be modular
>> components that could be added in (like they are in OIDC). ****
>>
>>  ****
>>
>> I've heard complaints that OIDC is complicated, but it's really not. Yes,
>> I agree that the giant stack of documents is intimidating and in my opinion
>> it's a bit of a mess with Messages and Standard split up (but I lost that
>> argument years ago). However, at the core, you've got an OAuth2
>> authorization server that spits out access tokens and id tokens. The id
>> token is a JWT with some known claims (iss, sub, etc) and is issued along
>> side the access token, and its audience is the *client* and not the
>> *protected resource*. The access token is a regular old access token and
>> its format is undefined (so you can use it with an existing OAuth2 server
>> setup, like we have), and it can be used at the User Info Endpoint to get
>> profile information about the user who authenticated. It could also be used
>> for other services if your AS/IdP protects multiple things.****
>>
>>  ****
>>
>> So I guess what I'm missing is what's the value proposition in this spec
>> when we have something that can do this already? And this doesn't seem to
>> do anything different (apart from syntax changes)?****
>>
>>  ****
>>
>>  -- Justin****
>>
>>  ****
>>
>> On Jul 29, 2013, at 4:14 AM, Phil Hunt <phil.hunt@oracle.com> wrote:****
>>
>>
>>
>> ****
>>
>>  FYI.  I have been noticing a substantial number of sites acting as
>> OAuth Clients using OAuth to authenticate users.****
>>
>>  ****
>>
>> I know several of us have blogged on the issue over the past year so I
>> won't re-hash it here.  In short, many of us recommended OIDC as the
>> correct methodology.****
>>
>>  ****
>>
>> Never-the-less, I've spoken with a number of service providers who
>> indicate they are not ready to make the jump to OIDC, yet they agree there
>> is a desire to support authentication only (where as OIDC does IDP-like
>> services).****
>>
>>  ****
>>
>> This draft is intended as a minimum authentication only specification.
>>  I've tried to make it as compatible as possible with OIDC.****
>>
>>  ****
>>
>> For now, I've just posted to keep track of the issue so we can address at
>> the next re-chartering.****
>>
>>  ****
>>
>> Happy to answer questions and discuss. ****
>>
>>  ****
>>
>> Phil****
>>
>>  ****
>>
>> @independentid****
>>
>> www.independentid.com****
>>
>> phil.hunt@oracle.com****
>>
>>  ****
>>
>>
>>
>> ****
>>
>>  ****
>>
>> Begin forwarded message:****
>>
>>
>>
>> ****
>>
>>  *From:*internet-drafts@ietf.org****
>>
>> *Subject: New Version Notification for
>> draft-hunt-oauth-v2-user-a4c-00.txt*****
>>
>> *Date:*29 July, 2013 9:49:41 AM GMT+02:00****
>>
>> *To:*Phil Hunt <phil.hunt@yahoo.com>, Phil Hunt <None@ietfa.amsl.com>,
>> Phil Hunt <>****
>>
>>  ****
>>
>>
>> A new version of I-D, draft-hunt-oauth-v2-user-a4c-00.txt
>> has been successfully submitted by Phil Hunt and posted to the
>> IETF repository.
>>
>> Filename: draft-hunt-oauth-v2-user-a4c
>> Revision: 00
>> Title: OAuth 2.0 User Authentication For Client
>> Creation date: 2013-07-29
>> Group: Individual Submission
>> Number of pages: 9
>> URL:
>> http://www.ietf.org/internet-drafts/draft-hunt-oauth-v2-user-a4c-00.txt
>> Status:
>> http://datatracker.ietf.org/doc/draft-hunt-oauth-v2-user-a4c
>> Htmlized:
>> http://tools.ietf.org/html/draft-hunt-oauth-v2-user-a4c-00
>>
>>
>> Abstract:
>>   This specification defines a new OAuth2 endpoint that enables user
>>   authentication session information to be shared with client
>>   applications.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available attools.ietf.org.
>>
>> The IETF Secretariat****
>>
>>    ****
>>
>> _______________________________________________
>> 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****
>>
>>
>>
>> ****
>>
>>  ****
>>
>> --
>> Nat Sakimura (=nat)****
>>
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en****
>>
>>
>>
>> ****
>>
>> _______________________________________________****
>>
>> OAuth mailing list****
>>
>> OAuth@ietf.org****
>>
>> https://www.ietf.org/mailman/listinfo/oauth****
>>
>>    ****
>>
>>
>>
>> ****
>>
>>  ****
>>
>> --
>> Nat Sakimura (=nat)****
>>
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en****
>>
>>   ****
>>
>>
>> _______________________________________________
>> 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****
>>
>>   ****
>>
>>   ** **
>>
>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en