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 > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
