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
- [OAUTH-WG] Fwd: New Version Notification for draf… Phil Hunt
- Re: [OAUTH-WG] Fwd: New Version Notification for … Anthony Nadalin
- Re: [OAUTH-WG] New Version Notification for draft… Richer, Justin P.
- Re: [OAUTH-WG] New Version Notification for draft… Phil Hunt
- Re: [OAUTH-WG] New Version Notification for draft… Richer, Justin P.
- [OAUTH-WG] Fwd: New Version Notification for draf… Phil Hunt
- Re: [OAUTH-WG] New Version Notification for draft… Richer, Justin P.
- Re: [OAUTH-WG] Fwd: New Version Notification for … John Bradley
- Re: [OAUTH-WG] Fwd: New Version Notification for … Nat Sakimura
- Re: [OAUTH-WG] New Version Notification for draft… Brian Campbell
- Re: [OAUTH-WG] New Version Notification for draft… Paul Madsen
- Re: [OAUTH-WG] New Version Notification for draft… Richer, Justin P.
- Re: [OAUTH-WG] New Version Notification for draft… Todd W Lainhart
- Re: [OAUTH-WG] New Version Notification for draft… Nat Sakimura
- Re: [OAUTH-WG] Fwd: New Version Notification for … Prateek Mishra
- Re: [OAUTH-WG] Fwd: New Version Notification for … Nat Sakimura
- [OAUTH-WG] Need for Extending OAuth with AuthN (w… Prateek Mishra
- Re: [OAUTH-WG] Need for Extending OAuth with Auth… Bill Mills
- Re: [OAUTH-WG] Need for Extending OAuth with Auth… Richer, Justin P.
- Re: [OAUTH-WG] Need for Extending OAuth with Auth… Prateek Mishra
- Re: [OAUTH-WG] Need for Extending OAuth with Auth… William Mills
- Re: [OAUTH-WG] Need for Extending OAuth with Auth… Nat Sakimura
- Re: [OAUTH-WG] Need for Extending OAuth with Auth… Anthony Nadalin
- Re: [OAUTH-WG] Need for Extending OAuth with Auth… Richer, Justin P.
- Re: [OAUTH-WG] Need for Extending OAuth with Auth… Anthony Nadalin
- Re: [OAUTH-WG] Need for Extending OAuth with Auth… Nat Sakimura
- Re: [OAUTH-WG] Need for Extending OAuth with Auth… Richer, Justin P.
- Re: [OAUTH-WG] Need for Extending OAuth with Auth… Anthony Nadalin
- Re: [OAUTH-WG] Need for Extending OAuth with Auth… Torsten Lodderstedt
- Re: [OAUTH-WG] Need for Extending OAuth with Auth… Nat Sakimura
- Re: [OAUTH-WG] Need for Extending OAuth with Auth… Phil Hunt
- Re: [OAUTH-WG] Need for Extending OAuth with Auth… Mike Jones
- Re: [OAUTH-WG] Need for Extending OAuth with Auth… Phil Hunt
- Re: [OAUTH-WG] Need for Extending OAuth with Auth… Nat Sakimura
- Re: [OAUTH-WG] Need for Extending OAuth with Auth… Bill Mills
- Re: [OAUTH-WG] Need for Extending OAuth with Auth… Nat Sakimura
- Re: [OAUTH-WG] Need for Extending OAuth with Auth… Phil Hunt
- Re: [OAUTH-WG] Need for Extending OAuth with Auth… Nat Sakimura