Re: [OAUTH-WG] Need for Extending OAuth with AuthN (was Re: Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt)
Torsten Lodderstedt <torsten@lodderstedt.net> Thu, 01 August 2013 15:05 UTC
Return-Path: <torsten@lodderstedt.net>
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 AECCF21E8150 for <oauth@ietfa.amsl.com>; Thu, 1 Aug 2013 08:05:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[AWL=0.861, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=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 yXAxVk4a+8QW for <oauth@ietfa.amsl.com>; Thu, 1 Aug 2013 08:05:14 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.25]) by ietfa.amsl.com (Postfix) with ESMTP id F295821E80FF for <oauth@ietf.org>; Thu, 1 Aug 2013 08:05:10 -0700 (PDT)
Received: from [80.67.16.116] (helo=webmail.df.eu) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1V4uR8-0006zT-SD for oauth@ietf.org; Thu, 01 Aug 2013 17:05:06 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_5f514e0eced4ef7784555da6ec50d0cc"
Date: Thu, 01 Aug 2013 17:05:06 +0200
From: Torsten Lodderstedt <torsten@lodderstedt.net>
To: oauth@ietf.org
In-Reply-To: <CABzCy2A2PDZ-We_ZCkYTz1qn2y5HhyfX_HJeFwdDQTztqZNh4Q@mail.gmail.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> <51F83EF7.6040201@oracle.com> <CABzCy2D4CJUMEQ32JNba8H4veBfgXOvj_J0rT7VmTtT-N_7BKQ@mail.gmail.com> <51F983E3.1020400@oracle.com> <1375307375.98370.YahooMailNeo@web142804.mail.bf1.yahoo.com> <E53E403B-BC52-4221-91E4-4884D7520A13@mitre.org> <CABzCy2A2PDZ-We_ZCkYTz1qn2y5HhyfX_HJeFwdDQTztqZNh4Q@mail.gmail.com>
Message-ID: <e8c67520b2a42f5de111e8aa1f75f204@lodderstedt-online.de>
X-Sender: torsten@lodderstedt.net
User-Agent: Roundcube Webmail/0.8.1
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
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: Thu, 01 Aug 2013 15:05:18 -0000
Hi Nat, I think your are going in the right direction. Here are my comments: - Authentication and attribute providing can be treated separately. I therefore would recommend you move the claim stuff into a separate specification, which includes standard claims, respective scope values, user info endpoint and the claims parameter. This would leave the base specification a small but reasonable extension to OAuth to handle authentication properly. Everyone interested in claims can implemented the complementary claims spec. Service provider wishing to use other interfaces for claim providing can do that. I would not care. - Use normativ language only to ensure proper implementation of the protocol, e.g. with respect to security, not for MTI requirements. As an example: "id tokens must be signed when sent via the user agent, they may be signed when issued at the token endpoint" - I would recommend to handle MTI in a separate document. Do not clutter the base spec with MTI stuff, such as "OpenID Providers that are not Self-Issued OPs MUST support this "response_type"." First, you are forward referencing to concepts introduced in other documents. Moreover, there are so many different scenarios I can think of where Connect could be used. They have rather different requirements, so having a document with different profile definitions is better suited (IMHO). A good starting point is section 13, where the definition of open and closed systems and respective MTIs is given. - Omit duplication of OAuth text. For example, there is another description of the state parameter or there is this statement: "In OpenID Connect, this communication MUST be over TLS." As far as I remember, the same holds true for plain OAuth. - 3.2. Server Processings - it is the discretion of the server when the id token is actually created. So don't make this part of the normative text. - I would recommend to move "3.2.1. ID Token after the authz response section". The description of the ID Token contents does not help the reader at that point. - I would suggest to organize the doc around the response types, i.e. describe the whole flow for code. Right now it is distributed over 2 sections (incl. Section 4 "Tokens Endpoint"). regards, Torsten. Am 01.08.2013 06:27, schrieb Nat Sakimura: > +1 > > I am trying to figure out how we can streamline the documentations. > Now that we are done with the implementer's draft vote that diff is not that important any more as technical content is determined and IPR is locked in, now is the time to do a major surgery to fix the documentation clutter that is caused by its history. > > There are several proposals on the table right now in the AB/Connect WG at OIDF. > > My proposal at the moment is to reorganize the doc into: > > * OpenID Connect Core > * OpenID Connect Discovery > * OpenID Connect Dynamic Registration > * OpenID Connect Advanced Claims Extension > * OpenID Connect Advanced Client Authentication Methods Extension > * OpenID Connect Self-Issued Provider Extension > * OpenID Connect JSON Based Request Extension > > Currently, I am experimenting with whether keeping the different flows in the Core makes sense or it is better to split them out. > > Here is the link to the Core draft I am experimenting with: http://bit.ly/19yHvJB [14] > XML and HTML versions are in the same repository as well. > > Your input will be most welcome. > > Nat > > 2013/8/1 Richer, Justin P. <jricher@mitre.org> > >> +1 >> >> On Jul 31, 2013, at 5:49 PM, Bill Mills <wmills_92105@yahoo.com> wrote: >> >>> 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 [12] >>> >>> 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 [13] >>> >>> 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 [10] >>>> Then, read OAuth 2.0 Multiple Response Type Encoding Practices http://openid.net/specs/oauth-v2-multiple-response-types-1_0-08.html [11] . >>>> >>>>> 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, >>>> >>>>> px solid; margin-left:5px; width:100%"> >>>>> I have written a short blog post titled "Write an OpenID Connect server in three simple steps [8]". >>>>> >>>>> 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 [7] >>>>>>>>> >>>>>>>>> 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 [5] 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 [1] >>>>>>>>>>>>> Status: http://datatracker.ietf.org/doc/draft-hunt-oauth-v2-user-a4c [2] >>>>>>>>>>>>> Htmlized: http://tools.ietf.org/html/draft-hunt-oauth-v2-user-a4c-00 [3] >>>>>>>>>>>>> >>>>>>>>>>>>> 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 at tools.ietf.org [4]. >>>>>>>>>>>>> >>>>>>>>>>>>> The IETF Secretariat >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth [6] >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth [6] >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth [6] >>>>> >>>>> -- >>>>> Nat Sakimura (=nat) >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ [9] >>>>> @_nat_en >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth [6] >>>>> >>>>> -- >>>>> Nat Sakimura (=nat) >>>>> Chairman, OpenID Foundation >>>>> h >>>> imura.org/ >>>> @_nat_en >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth [6] >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth [6] > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ [9] > @_nat_en > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth [6] Links: ------ [1] http://www.ietf.org/internet-drafts/draft-hunt-oauth-v2-user-a4c-00.txt [2] http://datatracker.ietf.org/doc/draft-hunt-oauth-v2-user-a4c [3] http://tools.ietf.org/html/draft-hunt-oauth-v2-user-a4c-00 [4] http://tools.ietf.org/ [5] http://www.independentid.com/ [6] https://www.ietf.org/mailman/listinfo/oauth [7] http://openid.net/specs/openid-connect-messages-1_0.html#ServerMTI [8] http://nat.sakimura.org/2013/07/28/write-openid-connect-server-in-three-simple-steps/ [9] http://nat.sakimura.org/ [10] http://openid.net/specs/openid-connect-basic-1_0-28.html [11] http://openid.net/specs/oauth-v2-multiple-response-types-1_0-08.html [12] http://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf [13] http://www.independentid.com/2013/07/simple-authentication-for-oauth-2-what.html [14] http://bit.ly/19yHvJB
- [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