Yes this post is negative, but it comes out of frustration. OAuth was a community generated standard. All the libraries supporting it were created by the community and all the people helping out on mailing lists, irc etc are part of the community.
I find it very hard not to be negative about large companies trying to force everyone into damaging community created standards. I am just saying what a lot of people I have talked to are thinking and have told me privately Eran, I have a lot of respect for you and I really appreciate all the work you have done, please do not take this as being anything against you. I know what you are up against and have the utmost respect for you and your vision for open standards. But yes the open IPR process that everyone had agreed to got intercepted and turned into a secret process due to Yahoo as you say taking the lead. Everyone was frustrated with that whole process, including I am sure you. This stalled the whole ratification of OAuth for a unnecessarily long time. I know Microsoft also joined in there and well, have they implemented OAuth as a result of your hard work? I don't know what they have done since the OAuth Summit, but a quick google search shows me that there is nothing yet from them more than a year later. But my rant was not about that IPR process, I fumed back then and whatever life goes on. Harder to live with is broken standards and yes the OAuth Session Extension is not compatible with higher level OAuth libraries as used by the majority of developers. The individually authenticated OAuth requests still follow the standard, there I agree. But the storage of 3-4 extra fields along with an oversize token and having to implement code to refresh the token when certain errors happen does not follow the OAuth standard. The large token you provide does follow the standard, but is just very inconvenient for lots of people who have to make database changes to support it. The problem with OAuth signatures is a low level problem for people developing libraries. People trying to write their own OAuth implementations from scratch are I'm sorry to say doing the wrong thing. Regular developers should use libraries that encapsulate the complexity or security really will be comprised. This is the thing I think the security and infrastructure engineers who designed the Session Extension don't realize. The migration to OAuth 1.0a was necessary but has caused people a lot of problems because it changes the flow. OAuth as well as OpenID are these strange specs that are a mix of API and a Spec. They are complex because they to a certain extent need to be complex. However they need to be written and standardized in a standard way so library builders can hide the complexity of this for the every day developer. This encapsulating is what breaks when you create something like the refresh step that you can not hide behind a simple method call. Right now there are probably 100s of developers who are good at their job using the Ruby OAuth libraries. There are of course also lots of others using various php libraries, the Python library etc. Most of them do not and should not have to understand enough to go in and deal with Yahoo's OAuth extensions just like that. Yes other providers have added little things, like Googles scope parameter etc. But none of them so drastically change the flow as the OAuth Session Extension does. Lots of people have tried dealing with Yahoo OAuth. I know of only one company besides my client who is actually doing it with Ruby as it has proven so difficult to support. Yes I should have followed the extensions list a bit more closely, but I also think that Yahoo's engineers could have been a bit more creative about a solution. Or at least spell out on your OAuth API documentation that you are not following the normal OAuth flow. With regards to the work and money Yahoo has spent on promoting OAuth, I applaud it, but remember that you are not the only ones who have made a large investment in OAuth. I also don't understand how you can support OAuth so fully on some levels, but not where it counts in your implementation. I would also like to extend a hand of gratitude to all the other people who have contributed to this on their own dime. Like you did originally. I like many others have spent 100s of hours promoting OAuth and supporting it through the OAuth Gem and Plugin. I have made it my personal goal for the OAuth ruby code to be as easy as possible for people to use. I have easily spent over a 100 hours of time that could have been billable on this, which is probably a considerably larger percentage of my revenues than Yahoo's investment in OAuth. This is why I don't take it lightly when a large company like Yahoo attempts to destroy all the hours of education, coding and help that we as a community have put into getting people to adopt OAuth. This is why I am upset. So I am sorry if Yahoo does not like what I say and if it is negative. This is nothing but me saying enough is enough. Support the standard as specified or label it as something else. Yahoo can do what they want, but I would encourage others implementers to not support their extensions until they change their implementation. Alternatively they could provide patches to the major libraries to support their implementation in a transparent manner. Transparent being key. Sincerely Pelle On Mon, Oct 5, 2009 at 7:11 PM, Eran Hammer-Lahav <[email protected]> wrote: > I rarely speak on behalf of Yahoo! but I find this post misleading and > unnecessarily negative. I was not working for Yahoo! at the time most of this > took place. > > Yahoo! approached the community soon after the OAuth specification was > completed to find ways to accommodate their unique requirements. For many > reasons, Yahoo! was unable to participate in the specification creation > process (the Flickr engineers who participated and contributed greatly use > very little of the Yahoo! infrastructure and generally do not represent > Yahoo! needs). > > In their attempt to address significant shortcomings in the specification, > they reached out to other large providers (AOL, Google, MySpace, Microsoft > were some) as well as to individual community leaders (Blaine Cook, Chris > Messina, David Recordon, and myself). It turned out that Yahoo!'s issues were > not unique and were shared by others large providers. I will not speak for > any other company but some of those currently supporting OAuth wish it was > better suited for large providers (and are constantly looking for both > alternatives and enhancements). > > When it was clear that Yahoo!'s requirements were not completely addressed by > the specification (being fully aware that it was largely their fault for not > participating when they could have had an impact), Yahoo!, lead by Allen Tom, > started drafting a proposed extension in the open with active collaboration > from other community members. The result was the Session Extension draft. > During this entire process Yahoo!'s CTO made it clear that whatever Yahoo! > used must be based on open standards and if we need to make changes, they > must be created in an open process. > > The extension is required for using OAuth with Yahoo! but it does not break > OAuth or changes it. Yes, you need additional code to make existing libraries > work but you do not need to change any existing libraries. It is not > different from any API parameters or other requirements by other vendors, > except that it was proposed as an open spec. > > You write "The IPR group bent over backwards to the requests from Yahoo legal > to get them into the OAuth process" - that's completely false. For most of > the IPR process *I* was the IPR group. Yahoo! was *asked* to sign the > agreement due to Flickr's involvement. The proposed agreement was > unacceptable not just to Yahoo! but other companies involved. So what did > Yahoo! legal do? They took the leadership and drafted a new agreement (based > directly on OpenID), coordinated with other companies, and spent many hours > (both internally and by outside counsel) to produce an agreement that was > acceptable by the community. They even spend hours on the phone with other > companies after they were fully satisfied to increase the reach of this > agreement. > > I also want to point out that this direct attack on a vendor who has been one > of the biggest supporter of the OAuth community is how communities destroy > their credibility and reputation. Yahoo! has invested more resources into > promoting OAuth and developing it than most other companies. They are the > only company employing someone (me) full time with the sole job of working on > OAuth and related efforts for the community. Ask anyone inside or outside > Yahoo! who has worked with me and they will tell you that the fact my > paycheck comes from Yahoo! has never influenced my work on OAuth, OWF, and > the best interest of the community. And the only way I can do that is with > the full support and encouragement of my employer. > > Remember the OAuth Session Fixation Attack? How many other companies will > dedicate an employee to work for the benefit of so many other companies? How > about the OAuth Summit? > > As for the difficulty people have with working with OAuth, from extensive > market resource conducted by Yahoo! and other large providers the reasons > people are having a problem with OAuth (Yahoo!'s or otherwise) has nothing to > do with the need to refresh tokens. It is the complexity of the signature > process more than anything else. > > Yahoo! has been one of OAuth's larger and most important supporters. The > session extension will be discussed at the IETF OAuth working group and will > hopefully make it into the next version of the core specification together > with other important contributions made by other companies since OAuth was > designed over 2 years ago. > > You have chosen to attack and insult instead of engaging in a productive > dialog which is always welcomed. And it's not like it would have been hard to > ask these questions given the constant presence of Yahoo! on every related > list. How is that benefiting the community? > > EHL > > > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf >> Of Pelle Braendgaard >> Sent: Monday, October 05, 2009 2:47 PM >> To: [email protected] >> Subject: [oauth] YAuth is not OAuth >> >> >> Hi Guys, >> I am not trying to troll with this post, but I do feel that this is >> very important if we don't want OAuth to fragment. >> >> I have intentionally been avoiding work with Yahoo's OAuth >> implementation until a client of mine asked me to do so. Doing that >> I've been working on Yahoo support in the Rails OAuth Plugin. >> >> http://github.com/pelle/oauth- >> plugin/blob/019761c04b690cb92bf4dc7280e977f0e1c6eb36/lib/oauth/models/c >> onsumers/services/yahoo_token.rb >> >> So I missed this proposed OAuth Session Extension standard the first >> time around. In case you don't know what this is, I didn't until >> recently. This is the reason everyone is having difficulties writing >> OAuth apps towards Yahoo using standard libraries. Google "yahoo >> oauth" and you will find lots of links to threads of people trying and >> giving up on this. >> >> The spec is here: >> http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html >> >> The Yahoo description is here: >> http://developer.yahoo.com/oauth/guide/oauth-auth-flow.html >> >> I was wondering then, what is the reason for this "YAuth" standard? A >> look in the spec gives no clue of the reasoning for this extra >> complexity and I finally discovered it in the original proposal on the >> OAuth Extensions list: >> >> http://groups.google.com/group/oauth- >> extensions/browse_thread/thread/8413622c6e585054# >> >> Allen Tom from Yahoo says >> >> "Large service providers may have difficulty adopting OAuth in its >> current form. In order to simply integration for developers, we'd like >> to conform with the current OAuth specification as much as possible. >> We'd like to propose the following OAuth Session extension for SPs who >> have web services which run mostly independently from from their Auth >> service." >> >> So in order to simplify integration for us they have given us a really >> complex standard we have to deal with. >> >> Allen continues: >> >> "Very large service providers may have a distributed architecture in >> which the service endpoints are able to cryptographically verify the >> authentication credentials without calling back to a central database. >> Permission revocation is implemented by issuing consumers a relatively >> short lived session credential, and requiring consumers to >> periodically obtain new session credentials from a central >> authorization service. The authentication service performs the >> necessary checks before issuing new session credentials." >> >> So the problem is one of Yahoo's internal architecture. I can >> appreciate the mathematical beauty of cryptographically verifying the >> credentials, but this seems a case of outsourcing your architectural >> debt to your customers. I assume this also explains the giant 800 byte >> tokens Yahoo issues. >> >> "Although it is technically possible for SPs to build an OAuth >> translation layer on top of their existing services, the cost may >> involve additional latency and decreased reliability if OAuth >> verification required a query to a database located in a very distant >> datacenter. " >> >> Exactly, it is possible even in a very large and distributed SP to do >> so. Just look at Google, who were able to cleanly work within the >> OAuth standard. >> >> I find it extremely bad and damaging to the OAuth world as a whole >> when you can't stick with standards. I have no problems with true >> extensions, such as the OpenID/OAuth extension as they are optional. >> But the OAuth Session Extension or YAuth as I think it really should >> be called requires core changes to the basic OAuth layer for us who >> actually implement these things. >> >> So what do I want from this rant? I want Yahoo to face up to their >> responsibilities to their developers and implement what they advertise >> they implemented an actual OAuth compliant SP. The IPR group bent over >> backwards to the requests from Yahoo legal to get them into the OAuth >> process. Now they want all of us developers (the foot soldiers of the >> OAuth war) to handle their dirty work. >> >> I would prefer Yahoo sticking with BBAuth than calling what they >> support OAuth. >> >> OAuth is complicated as it is for the average developer as evidenced >> by many of the questions I get on my blog, on the mailing lists, >> stackoverflow etc. Developing the Ruby OAuth library and the Rails >> plugin, I've tried to hide the complexity for your average developer. >> YAuth directly sabotages this as it destroys the whole standard OAuth >> flow, that developers are finally able to understand. >> >> Yahoo needs to implement OAuth if they want the support of us >> developers. Until they do so, I will remove support for Yahoo from the >> OAuth Rails Plugin library. >> >> I will implement Yahoo support for my client, but I have stopped >> development of it for the OAuth Ruby Plugin as I think that will only >> encourage such behavior in the future. >> >> Yahoo has great people working within them whom I really respect. If >> they won't change their flow they should at least be willing to put >> some of their developers at work to support the developers. >> >> P >> >> >> -- >> http://agree2.com - Reach Agreement! >> http://extraeagle.com - Solutions for the electronic Extra Legal world >> http://stakeventures.com - Bootstrapping blog >> >> > > > > -- http://agree2.com - Reach Agreement! http://extraeagle.com - Solutions for the electronic Extra Legal world http://stakeventures.com - Bootstrapping blog --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
