Re: [OAUTH-WG] Call for Adoption
George Fletcher <gffletch@aol.com> Tue, 26 January 2016 19:14 UTC
Return-Path: <gffletch@aol.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 8AD6F1B2BC8 for <oauth@ietfa.amsl.com>; Tue, 26 Jan 2016 11:14:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 MeUTSjnOPap7 for <oauth@ietfa.amsl.com>; Tue, 26 Jan 2016 11:13:54 -0800 (PST)
Received: from omr-a011e.mx.aol.com (omr-a011e.mx.aol.com [204.29.186.59]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAB2B1B2BC5 for <oauth@ietf.org>; Tue, 26 Jan 2016 11:13:53 -0800 (PST)
Received: from mtaout-mab02.mx.aol.com (mtaout-mab02.mx.aol.com [172.26.249.82]) by omr-a011e.mx.aol.com (Outbound Mail Relay) with ESMTP id 88A72380063A; Tue, 26 Jan 2016 14:13:52 -0500 (EST)
Received: from [10.172.102.124] (unknown [10.172.102.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mab02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id C08ED38000334; Tue, 26 Jan 2016 14:07:20 -0500 (EST)
To: Brian Campbell <bcampbell@pingidentity.com>
References: <569E2076.2090405@gmx.net> <CAAP42hC+L-7irdR7Y2pfNWyhP6cWLn0wNyauA5TQb4jr=4UH4Q@mail.gmail.com> <BY2PR03MB442C2801F09B2B7A103E673F5C30@BY2PR03MB442.namprd03.prod.outlook.com> <CABzCy2DehwZh2gd_6oNy69O+qxowva00qZWnX8uWX2n4h+kPLw@mail.gmail.com> <BY2PR03MB442EA7CE4F9728C2E39BBEAF5C30@BY2PR03MB442.namprd03.prod.outlook.com> <EE414329-AA2A-4F99-841B-0581E4F4605F@mit.edu> <CABzCy2A9RCONixTG+ZFD8sz6FTD-o1Do8iV2gX2=pKu+PenT-A@mail.gmail.com> <BY2PR03MB442DE057967872C63A56DF8F5C40@BY2PR03MB442.namprd03.prod.outlook.com> <CABzCy2Co2okoC_hxy3bLTzbGm3nuQiULM3XqkJMwiV_5iU9-=Q@mail.gmail.com> <CA+k3eCSfXQng6PzhWR-Qjyp=SO1LYnfXH7qqzb-5btqWaJJX-A@mail.gmail.com> <BY2PR03MB4422882B74ED659DB47CECDF5C40@BY2PR03MB442.namprd03.prod.outlook.com> <CABzCy2CC8jN6kzxbJ70m900g4J1VW2b65gM_M1dhx6YXfWVhdQ@mail.gmail.com> <CA+k3eCSiEcE-YRG+ej+zJuEHOwqO4oyvvGmKWv5SeMUu4dVPrA@mail.gmail.com> <56A78EEF.4090706@aol.com> <CA+k3eCQh+KfX8+NONECjVj2ZX_e=JFFM4fF7XXcxwWJ-kii9Tw@mail.gmail.com>
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
Message-ID: <56A7C3E8.8080601@aol.com>
Date: Tue, 26 Jan 2016 14:07:20 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <CA+k3eCQh+KfX8+NONECjVj2ZX_e=JFFM4fF7XXcxwWJ-kii9Tw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------070007090200040301030004"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1453835241; bh=xqZY4Y1R/TxqlmkgUUrXflbGxc/P1bCT4fmG7PekDng=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=LnKr7rJm5fZrkUtAPbceSTXDxBZTBaegG079Qhoz5kOnk5My153P8rzZQurbNDiTu 2Y+wrjJzfmaCrFq6bsD+GQBw20U3Dhg9gyQOkJV7Lp+BsA5DDQQizddQqOtqXmKR9L MLUhAiclsP7gIhUQGnXHrfZj5YbCNnWbqpIdUN68=
x-aol-sid: 3039ac1af95256a7c3e83fa0
X-AOL-IP: 10.172.102.124
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/mxeKTxUkjidSSdpVnlAGsrJVZwg>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Call for Adoption
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, 26 Jan 2016 19:14:02 -0000
So I'm fine with not requiring discovery in the simple case of an RS supporting a single AS. However, once the RS moves to supporting multiple authorization servers then I believe that discovery based on the 'iss' string is required. The discovery results can be cached so a discovery lookup per transaction is not required. Thanks, George On 1/26/16 1:58 PM, Brian Campbell wrote: > I'm staying that it's sufficiently unlikely that it shouldn't be part > of the threat model and that a discovery lookup on iss isn't necessary. > > > > On Tue, Jan 26, 2016 at 8:21 AM, George Fletcher <gffletch@aol.com > <mailto:gffletch@aol.com>> wrote: > > While it's a different way of getting the endpoints mixed up, I > don't think that makes it invalid. If we are going to address the > attack vector I believe we should solve it for "all" cases not > just the ones that seem most likely. > > Thanks, > George > > On 1/26/16 8:37 AM, Brian Campbell wrote: >> I'm not sure what's described in the blog post is actually a >> variant of an attack that anyone is really concerned about? A >> client developer would have to change a production system to use >> an unfamiliar value for the token endpoint based solely on a an >> email without even looking at service documentation or metadata. >> >> >> On Fri, Jan 22, 2016 at 6:29 PM, Nat Sakimura <sakimura@gmail.com >> <mailto:sakimura@gmail.com>> wrote: >> >> I wrote a blog on why the current mix-up draft approach does >> not solve the issue. >> >> http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/ >> >> Hopefully, the point I am making is clearer by this. >> >> Best, >> >> Nat >> >> 2016年1月23日(土) 8:32 Mike Jones >> <Michael.Jones@microsoft.com >> <mailto:Michael.Jones@microsoft.com>>: >> >> I like the “from which the authorization server's >> configuration information location can be derived” >> language. Thanks. I’ll plan to incorporate that the >> next time the draft is revised. >> >> -- Mike >> >> *From:*Brian Campbell [mailto:bcampbell@pingidentity.com >> <mailto:bcampbell@pingidentity.com>] >> *Sent:* Friday, January 22, 2016 3:26 PM >> *To:* Nat Sakimura <sakimura@gmail.com >> <mailto:sakimura@gmail.com>> >> *Cc:* Mike Jones <Michael.Jones@microsoft.com >> <mailto:Michael.Jones@microsoft.com>>; Justin Richer >> <jricher@mit.edu <mailto:jricher@mit.edu>>; >> <oauth@ietf.org <mailto:oauth@ietf.org>> <oauth@ietf.org >> <mailto:oauth@ietf.org>> >> >> >> *Subject:* Re: [OAUTH-WG] Call for Adoption >> >> I agree that the language describing OAuth issuer could >> and should be improved. The text now reads like it is the >> exact and full URL where the metadata/discovery document >> is located. Perhaps something more like "the URL from >> which the authorization server's configuration >> information location can be derived" and explain that >> adding the .well-known bits to the issuer is where the >> configuration information can actually be found. >> >> On Thu, Jan 21, 2016 at 7:07 PM, Nat Sakimura >> <sakimura@gmail.com <mailto:sakimura@gmail.com>> wrote: >> >> Re: iss. I discussed this a bit with Nov in more >> details. It probably is a sloppy language of the >> specs that is making it difficult to read what you >> wanted to achieve. >> >> In mix-up-mitigation draft, OAuth issuer is "the URL >> of the authorization server's configuration >> information location". In OAuth discovery draft, >> there is something called "OAuth 2.0 Configuration >> Information Location URL", which is equal to "OpenID >> Connect Issuer". >> >> When I wrote the statement, I thought you were >> pointing to the URL that you can actually pull the >> configuration information by "the URL of the >> authorizaiton server's configuration information >> location" since otherwise you would have used the >> term "OAuth 2.0 Configuration Information Location >> URL". But after all, you probably meant these two are >> the same. Then I would strongly recommend to fix the >> language. >> >> Now, even If that is the case, the relationship like >> >> ·iss + .well-know/openid-configuration = Connect OP >> config endoint >> >> ·OAuth config endpoint - >> .well-known/openid-configuration = OAuth iss >> >> is very confusing. >> >> You also claim that your approach is simpler, but to >> me, your approach seem to be overly complex. It >> requires discovery and the check for the value of the >> discovered config information to work as the >> mitigation. (Right. Draft -01 does not have it, so it >> does not solve the mix-up issue.) With oauth-meta, >> you do not need it. >> >> Finally, your point that HATEOAS reminds you of WSDL, >> it is not. If you want to have something similar to >> WSDL in REST API area, it is Swagger. (Actually, it >> is gaining a lot of momentum recently, but that's >> beside the fact ;-). And the point here is not the >> format but the fact that we need to have a way to >> associate metadata to the data. The root cause of >> this mix-up attack is that the metadata and data is >> not associated properly. We have a standard way of >> associating the data and metadata with link-rel such >> as RFC5988 so why not use it? Link-rel-href pattern >> is used a lot now. Most modern web pages actually >> have it. Using a proper way to associate metadata >> with data will save you from a lot of other attacks >> in the future. Instead of doing patch works, we >> should solve it architecturally. >> >> Nat >> >> 2016年1月22日(金) 10:34 Mike Jones >> <Michael.Jones@microsoft.com >> <mailto:Michael.Jones@microsoft.com>>: >> >> Nat, I’m confused by this statement in the >> message you reference “Unfortunately, this does >> not match the value of OAuth issuer defined in >> Section 2 >> of draft-jones-oauth-mix-up-mitigation-01 nor the >> 'iss' returned as specified in 3.1. As such, >> validation as specified in bullet 1 of Section 4 >> fails in Google's case -- OR it means that the >> document is internally inconsistent.”. The issuer >> definition in draft-jones-oauth-discovery is 100% >> compatible with the one in OpenID Connect >> Discovery, by design. In the Google example, >> both the OpenID issuer and the OAuth issuer >> values would be the string >> “https://accounts.google.com”. What is the >> inconsistency that you perceive? >> >> The discussion of the duplication problem >> happened in the private meetings in Yokohama. >> >> I will admit, in Yokohama, I didn’t speak up in >> the public meetings to point out that a simpler >> alternative to oauth-meta was already being >> discussed there in private, because then I would >> have had to talk about the security issues, which >> we’d decided not to publicly do at that point. So >> I stayed silent during the poll, out of >> politeness. Perhaps I should have found a way to >> say something then anyway, but that’s water under >> the bridge now. >> >> Finally, for what it’s worth, the HATEOAS stuff >> reminds me far too much of Web Services >> Description Language (WSDL) – part of the >> complexity baggage that helped sink Web >> Services. The use of “link rel” to define an >> interaction vocabulary and publish endpoints for >> that vocabulary seems pretty baroque and >> reminiscent of “microformats” – another cute >> “Webby” innovation that never caught on. The >> industry has pretty much voted with its feet and >> is using JSON for publishing discovery data >> structures – not “link rel”. I am against us >> reverting to the “link rel” proposal from 2008 >> that never caught on when JSON is simpler and >> does a better job. >> >> -- Mike >> >> *From:*Nat Sakimura [mailto:sakimura@gmail.com >> <mailto:sakimura@gmail.com>] >> *Sent:* Thursday, January 21, 2016 6:24 AM >> *To:* Justin Richer <jricher@mit.edu >> <mailto:jricher@mit.edu>>; Mike Jones >> <Michael.Jones@microsoft.com >> <mailto:Michael.Jones@microsoft.com>> >> *Cc:* William Denniss <wdenniss@google.com >> <mailto:wdenniss@google.com>>; <oauth@ietf.org >> <mailto:oauth@ietf.org>> <oauth@ietf.org >> <mailto:oauth@ietf.org>> >> >> >> *Subject:* Re: [OAUTH-WG] Call for Adoption >> >> Mike, >> >> You just criticize my draft. That's ok, but I >> would really like to get some response to my >> questions stated in >> https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html . >> To me, it just does not seem to work, and the >> combination of the oauth-meta and PKCE seems to >> be much more elegan, nicer, and much simpler to >> implement. If you just give up the dynamic >> response at the authorization endpoint, then you >> even do not have to touch the code but just >> change a config file. >> >> Please convince me by answering to my questions. >> >> For the record of Yokohama, I do not recall much >> about duplication in OAuth session. The poll in >> the room was 19 for / zero against / 4 persons >> need more information. Indeed, it is not >> duplicating much. And if you move to a new model >> without pre-configured discovery, it is not >> duplicating any but the resource endpoint URI, >> which is optional and is for the cases where the >> client did not know the concrete resource >> endpoint to start with. >> >> I understand your usecases always start from a >> concrete endpoint location. Mine do not. In a >> four party model, it is likely not. The user just >> want to have the service to fetch his data from >> some resource endpoint. He just hits the service. >> He does not hit the resource endpoint directly. >> For example, in the case of a consumer using a >> personal finance platform (PFP)to manage his >> pension fund, he hits the PFP and not the Pension >> fund. Assuming that the pension fund has >> delegated the authorization control to the >> authorization server, then, the authorization >> server should return both the access token and >> the endpoint of the pension fund so that the PFP >> can pull the data using them. A similar model >> holds for personal health service and health care >> providers. >> >> Best, >> >> Nat >> >> 2016年1月21日(木) 21:18 Justin Richer >> <jricher@mit.edu <mailto:jricher@mit.edu>>: >> >> Convergence is exactly what I’m arguing for, >> though. These things ought to work together. >> >> — Justin >> >> On Jan 21, 2016, at 2:55 AM, Mike Jones >> <Michael.Jones@microsoft.com >> <mailto:Michael.Jones@microsoft.com>> wrote: >> >> My memory of the discussions of the >> oauth-meta draft in Yokohama were that >> many people felt that it was >> unnecessarily dynamically duplicating a >> lot of information that the client >> already had. Most of us that were aware >> of the attacks then were in favor of a >> more targeted, minimal approach. You >> were listened to in Yokohama, but that >> didn’t necessarily mean that people >> agreed with the approach. Participants >> were already aware of the oauth-meta >> proposal in Darmstadt but no one spoke up >> in favor of it that I can recall. Rather, >> I think people were thinking that “less >> is more”. >> >> There have also been discussions in the >> last day about how dynamically returning >> a resource URL, which oauth-meta does, is >> both unnecessary (since the client >> initiated the resource authorization >> already knowing what resource it wants to >> access) and often problematic, since many >> authorization servers can authorize >> access to multiple resources. If >> anything, the client should be telling >> the authorization server what resource it >> wants to access – not the other way around. >> >> I’m not saying that there aren’t some >> good ideas in the oauth-meta draft – I’m >> sure there are, just as there are in the >> approach designed by the participants in >> Darmstadt. While I volunteered to write >> the first draft of the mix-up-mitigation >> approach, it really reflects something a >> lot of people have already bought into – >> as evidenced in the passion in the >> high-volume “Mix-Up About The Mix-Up >> Mitigation” thread, and not just my >> personal project. >> >> If you think there are things missing or >> wrong in the mix-up-mitigation draft, >> please say what they are. That will help >> us quickly converge on a solution that >> will work for everyone. >> >> Sincerely, >> >> -- Mike >> >> *From:*Nat Sakimura >> [mailto:sakimura@gmail.com] >> *Sent:* Wednesday, January 20, 2016 11:17 PM >> *To:* Mike Jones >> <Michael.Jones@microsoft.com >> <mailto:Michael.Jones@microsoft.com>>; >> William Denniss <wdenniss@google.com >> <mailto:wdenniss@google.com>>; Justin >> Richer <jricher@mit.edu >> <mailto:jricher@mit.edu>> >> *Cc:* oauth@ietf.org <mailto:oauth@ietf.org> >> *Subject:* Re: [OAUTH-WG] Call for Adoption >> >> Hi Mike. >> >> Conversely, I would like to ask why this >> approach does not work for Mix-up >> attack. As Nov stated, we in fact have >> discussed the approach in quite a length >> back in Yokohama. I really would like to >> know why it does not work. >> >> Besides, for oauth-meta approach, mix-up >> attack is only one of the thing it solves. >> >> Nat Sakimura >> >> 2016年1月21日(木) 16:02 Mike Jones >> <Michael.Jones@microsoft.com >> <mailto:Michael.Jones@microsoft.com>>: >> >> Not to be negative, but I disagree >> with adopting >> draft-sakimura-oauth-meta. We should >> define and promote one mitigation >> approach to the mix-up attacks. >> Having two would confuse implementers >> and cause compatibility problems – >> reducing overall security. >> >> The approach defined in >> draft-jones-oauth-mix-up-mitigation >> was created in collaboration with the >> security researchers who identified >> the problems in the first place, was >> vigorously discussed in the security >> meeting Hannes and Torsten held in >> Darmstadt, and has been since refined >> based on substantial input from the >> working group. And at least three >> implementers have already stated that >> they’ve implemented it. I’m not >> saying that it’s, but if there are >> things missing or things that need to >> be improved in our approach, we >> should do it there, rather >> introducing a competing approach. >> >> Also, standard OAuth deployments >> register the client and then use the >> information gathered at registration >> time for subsequent protocol >> interactions. They do not need all >> the configuration information for the >> authorization server to be >> retransmitted at runtime. The >> oauth-meta draft goes too far in that >> direction, at least as I see it. >> Returning things two ways creates its >> own problems, as discussed in the >> Duplicate Information Attacks >> security considerations section (7.2) >> of the mix-up-mitigation draft. >> >> I’ll note that the mix-up-mitigation >> approach is compatible with existing >> practice in both static and dynamic >> metadata discovery. Replying to >> Justin’s comment that “It's the >> pre-configured discovery document >> that's at the root of the mix-up >> attack in the first place” – this is >> not the case. The attacks can be >> performed without either discovery or >> dynamic registration. >> >> I would be interested in hearing a >> technical discussion on whether there >> are aspects of the oauth-meta >> approach that mitigate aspects of the >> attacks that the mix-up-mitigation >> approach does not. That could help >> inform whether there are additional >> things we should add to or change in >> the mix-up draft. >> >> -- Mike >> >> *From:*OAuth >> [mailto:oauth-bounces@ietf.org >> <mailto:oauth-bounces@ietf.org>] *On >> Behalf Of *William Denniss >> *Sent:* Wednesday, January 20, 2016 >> 10:37 PM >> *To:* Justin Richer <jricher@mit.edu >> <mailto:jricher@mit.edu>> >> *Cc:* oauth@ietf.org >> <mailto:oauth@ietf.org> >> *Subject:* Re: [OAUTH-WG] Call for >> Adoption >> >> +1 to adopt this, and I agree with >> Justin's comments. >> >> On Wed, Jan 20, 2016 at 9:53 PM, >> Justin Richer <jricher@mit.edu >> <mailto:jricher@mit.edu>> wrote: >> >> +1 >> >> Inline discovery and >> pre-configured discovery (ie, >> .well-known) should at the very >> least be compatible and developed >> together. It's the pre-configured >> discovery document that's at the >> root of the mix-up attack in the >> first place. >> >> -- Justin >> >> On 1/19/2016 10:30 PM, Nat >> Sakimura wrote: >> >> Just to give more context, at >> IETF 94, I have done a >> presentation on discovery. >> >> According to the minutes, >> >> (f) Discovery (Nat) >> >> Nat explains his >> document as an example of the >> work that has to be done >> >> in the area of >> discovery, which is a topic >> that has been identified >> >> as necessary for >> interoperability since many >> years but so far there >> >> was not time to >> work on it. Mike, John and >> Nat are working on a new >> >> document that >> describes additional >> discovery-relevant components. >> >> Poll: 19 for / >> zero against / 4 persons need >> more information. >> >> The document discussed there >> was >> <https://tools.ietf.org/html/draft-sakimura-oauth-meta-05>https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. >> This is a simple (only >> 1-page!) but a very powerful >> document that nudges towards >> HATEOAS which is at the core >> of RESTful-ness. It also >> mitigates the Mix-up attack >> without introducing the >> concept of issuer which is >> not in RFC6749. It is also >> good for selecting different >> endpoints depending on the >> user authentication and >> authorization results and >> more privacy sensitive than >> pre-announced Discovery >> document. It also allows you >> to find to which protected >> resource endpoint you can use >> the access token against. >> >> In the last sentence of the >> minutes, it talks about "a >> new document that describes >> additional discovery-relevant >> components". This is >> https://tools.ietf.org/html/draft-jones-oauth-discovery-00. >> It went for the call for >> adoption. However, it is only >> a half of the story. I >> believe >> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that >> was discussed at IETF 94 and >> had support there should be >> adopted as well. >> >> Nat Sakimura >> >> 2016年1月20日(水) 12:05 Nat >> Sakimura <sakimura@gmail.com >> <mailto:sakimura@gmail.com>>: >> >> Thanks Hannes. >> >> I did not find >> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05, which >> was discussed in >> Yokohama, and was largely >> in agreement if my >> recollection is correct. >> Why is it not in the call >> for adoption? >> >> 2016年1月19日(火) 20:39 >> Hannes Tschofenig >> <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>>: >> >> Hi all, >> >> we have submitted our >> new charter to the >> IESG (see >> http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html) >> and >> since some IESG >> members like to see >> an updated list of >> milestones as >> well. For this >> reason, based on a >> suggestion from >> Barry, we are also >> starting a call for >> adoption concurrently >> with the review of >> the charter >> text by the IESG. >> >> We will post separate >> mails on the >> individual documents. >> Your feedback >> is important! Please >> take the time to look >> at the documents and >> provide >> your feedback. >> >> Ciao >> Hannes & Derek >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> <mailto:OAuth@ietf.org> >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth > > -- Chief Architect Identity Services Engineering Work: george.fletcher@teamaol.com AOL Inc. AIM: gffletch Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch Office: +1-703-265-2544 Photos: http://georgefletcher.photography
- [OAUTH-WG] Call for Adoption Hannes Tschofenig
- Re: [OAUTH-WG] Call for Adoption Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption Justin Richer
- Re: [OAUTH-WG] Call for Adoption William Denniss
- Re: [OAUTH-WG] Call for Adoption Mike Jones
- Re: [OAUTH-WG] Call for Adoption Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption Mike Jones
- Re: [OAUTH-WG] Call for Adoption Justin Richer
- Re: [OAUTH-WG] Call for Adoption Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption Mike Jones
- Re: [OAUTH-WG] Call for Adoption Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption William Denniss
- Re: [OAUTH-WG] Call for Adoption Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption Brian Campbell
- Re: [OAUTH-WG] Call for Adoption Mike Jones
- Re: [OAUTH-WG] Call for Adoption Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption Brian Campbell
- Re: [OAUTH-WG] Call for Adoption George Fletcher
- Re: [OAUTH-WG] Call for Adoption Brian Campbell
- Re: [OAUTH-WG] Call for Adoption George Fletcher
- Re: [OAUTH-WG] Call for Adoption Brian Campbell
- Re: [OAUTH-WG] Call for Adoption Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption Hans Zandbelt
- Re: [OAUTH-WG] Call for Adoption sakimura
- Re: [OAUTH-WG] Call for Adoption John Bradley
- Re: [OAUTH-WG] Call for Adoption George Fletcher
- Re: [OAUTH-WG] Call for Adoption Brian Campbell
- Re: [OAUTH-WG] Call for Adoption Antonio Sanso
- Re: [OAUTH-WG] Call for Adoption Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption Justin Richer
- Re: [OAUTH-WG] Call for Adoption Nat Sakimura
- Re: [OAUTH-WG] Call for Adoption Justin Richer
- Re: [OAUTH-WG] Call for Adoption John Bradley
- Re: [OAUTH-WG] Call for Adoption Nat Sakimura