> Most of the people involved were doing it as part of their day job. A > community does not implies the lack of corporate presence. At the time this > extension was proposed, everyone was included and was invited to contribute > and provide feedback. It was done openly and Yahoo! actively seeks feedback > and advice from all the key contributors. It is hypocritical to complain > about Yahoo!'s implementation a year after the extension was released because > you are now forced to implement it to make a living. You can only blame > yourself for purposely boycotting Yahoo!'s implementation until now > (according to your own rant).
Lots of people were doing this as part of their day job, but lots of people were also doing it on their own dime. I agree with you that the extension was proposed on the extensions list. I did not monitor that list as closely as I should. I am now making a living implementing it as I mentioned. As I am not being sponsored by a large company to deal with this I can't monitor every single thing going on about OAuth. > I don't care about what people told you in private. I trust the research I > got from more reliable sources. This entire rant is your personal view on > what is damaging the community. If I thought any of Yahoo!'s actions were > damaging the community I would not be working there anymore. My *job* is to > make sure Yahoo! works with the community and adjust its internal process and > attitude to be only positive and supportive. And contrary to the bleak > picture you are trying to paint, getting Yahoo! to do the right thing is an > effortless part of my job. Yes my rant was my personal view. And yes many people are in agreement with me. It is your choice who you believe. > >> 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. > > That's a funny way to show respect and appreciation. Come on Eran at no point have I attacked you or criticized you directly. As I have said earlier you are in a difficult place and I accept that. I have only good things to say about all the people I have met and talked to within Yahoo, who have been involved with OAuth. What I dislike is when internal policies and politics get moved out into public specs, standards and licenses that those of us who are in startups and are developing OSS code are forced to deal with. > It's not like you didn't know where to reach Yahoo! team members and start by > asking questions instead of a detailed public attack. I do take this > personally because what you are saying is that me and others have failed to > do our job and don't have the best of the community in mind. Yahoo! has been > nothing but supportive of this community from the very first moment it got > involved - it is an important *member* or the community. I also resent the > implication in "what you are up against". You truly have no idea what you are > ranting about. It appears that you don't understand the frustrations that every day developers have had to deal with trying to support OAuth. We as a community are trying to create a standard that allows us to interoperate, that allows us to get rid of the reprehensible practice of password sharing. Some level of complexity is needed to do that, but read the lists. People have found it very difficult to deal with. Imposing an additional Yahoo tax on top of it to pay off your own internal technical debt is not realistic. Most people will go back to using passwords again. > >> 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. > > This paragraph is full of so many false claims... If "everyone had agreed to" > there would not be any problem, but obviously not everyone agreed. Beside > Google (and maybe Twitter and Dig, not sure if the individuals from those > companies were acting on their behalf), no other company signed that > agreement. The community knowingly used Yahoo!'s intellectual assets (Flickr > and BBAuth) when it created the specification so it was clear we had to seek > their approval once we decided to deal with IPR. I don't know what is false about it. This is exactly what you explained to me. But again this is not about IPR. These were my complaints from last year for those of you interested: http://stakeventures.com/articles/2008/06/26/openness-and-the-oauth-legal-dance > > The process was never secret but for practical purposes it included those who > needed to sign it and it had enough community review to make sure the > corporation are not doing anything wrong. You don't have to trust me, but I > am sure everyone here trusts Gabe Wachob (who initiated this entire IPR > process) and David Recordon who wrote the book on community-drive IPR process. Yes I trust Gabe and I trust David. But still don't try and get out of the fact that it was secret. It was secret and at the request of Yahoo legal. That is a fact. > No. It was about trying to embarrass Yahoo! using anything you could find, > even if it had nothing to do with your main plot line. In my original post I mentioned this extremely briefly. Not to embarrass Yahoo, but to show how this had happened before. You are the one who is bringing it up again and again. > Also, you were the only person who had a problem with the process (another > unjustified rant), and once we made the document available for community > review, neither you nor anyone else had any substantive feedback. I did have feedback that I did bring up at the Summit. We had a perfectly readable plain English Non Assertion Covenant before that everyone but Yahoo had agreed to. This was turned into unreadable legalese gracefully provided by Yahoo legal. I did object to this quite vocally. > Most of the libraries merely sign requests. The few that perform token > management for the user work based on a few early implementation. OAuth does > not have error codes or error handling so anything that spells it out is > extending the standard. OAuth does not mention token size. Any expectation > about that shows lack of understanding of the design and goals of the > protocol. Being able to encode state into the token itself was always the > goal. Same goes for using non-URI-safe characters in tokens. Tokens can be > anything and a library that does not accommodate that is just a bad library > (whether the spec should spell it out is a separate issue - either way it > doesn't). I already mentioned that your chosen token size is fully valid, just inconvenient. The ruby libraries do absolutely accommodate this, but most people have made the assumption when developing their schema that a token size would never reach more than 256 bytes. When you want developers to write towards your API's it would be a good idea to at least mention this in a list of common pitfualls in your otherwise decent OAuth documentation. >> 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. > > This doesn't change the fact that most libraries are of poor quality or > incomplete and that still more developers refuse to use them. The *fact* is > that most people are still trying to write their own code and have issues. In > other words, Yahoo!'s developers both internally and externally find the spec > itself too hard and find the libraries either incompatible with their > platforms or their architecture. And don't get me started about feedback I > have seen from the enterprise world. We have a good 1.0 spec. We are working > to make 2.0 great and part of that will use innovative ideas from many > sources, one of which is Yahoo!'s experience. I have only been looking at the Ruby code and a little bit at the Python implementation. I believe we have a great, but not perfect Ruby library. Leahs library also seems good. Seth who is also from Yahoo took over from me as the maintainer of the Ruby Gem and has done a great job. What you are saying "Yahoo!'s developers both internally and externally find the spec itself too hard and find the libraries either incompatible with their platforms or their architecture." makes it sound like OAuth has been a complete failure. Rather than working on improving this, Yahoo is making it worse by imposing further complexity. If this is the way the standard is going I shudder to think of all the earmarks and special cases that are going to be in OAuth 2.0 with even less library support. > This ignores the fact that this refresh step is a security and deployment > requirement. Yahoo! is committed to working with the community to make sure > the next version of the spec accommodates these needs. And Yahoo! is far from > alone. Google, Microsoft, AOL, and others all share these requirements which > the current spec fails to support. Should these companies brought it up > during the 1.0 process? Sure. But the fact that they are here now and are > telling us what they need to make this work isn't a bad thing. This is not a security requirement. Equivalent and better security can be done by expiring access tokens and having users refresh them, just like is done in Yahoo's FireEagle api. The whole reason for the OAuth Sessions spec is spelled out in the original email and deep at the bottom of the spec: "Allowing Access Tokens to be revoked before they expire requires Service Providers to perform a database lookup before serving a Protected Resource. For performance reasons, Service Providers may want to issue Access Tokens that can be validated without a database lookup, provided that the Access Token lifetime is less than then the Service Provider's allowable latency for Access Token revocation." http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html#anchor11 Basically because Yahoo and other providers wish to avoid a database lookup you are imposing an extra tax on us the developers. I can think of all kinds of different ways this could be handled avoiding database lookups on every request, without having to expose the limitations of your architecture on us. > None of this leads to the conclusion that Yahoo! is hurting the spec or the > community. PERIOD. Other companies should implement the extension if they > find Yahoo!'s API worth the extra work. The entire argument that somehow this > extension hurts anyone else (other than theoretically Yahoo! itself) is > absurd. Yahoo! has not changed a single thing in the core spec, didn't come > up with a new competing signature method, or told developers to do anything > other than what the core spec does. A library written to work with Yahoo! > will easily work with everyone else. It simply added the ability to issue > short-lived tokens without requiring the end user to re-authorize access. Yes the main victims of this extension is Yahoo. I agree. However it also hurts legions of junior programmers trying to follow OAuth tutorials and connecting to Yahoo's libraries and failing. It also affects those of us who try to help these people out by providing libraries that support the complexity. While you didn't change anything in the core spec, you did add extra requirements for people wanting to use OAuth with Yahoo. This means that you break the infrastructure of code examples, documentation, tutorial, libraries etc for people wanting to access their users Yahoo address book. This while only having one small note in your documentation that something is different here: "You can use the Access Token for one hour until it expires. To get a new Access Token for continued use, use the same expired token and the get_token call to be provided a new Access Token. (OAuth Session 1.0 Draft 1, Section 4)" Now those of us who know the OAuth spec by heart would immediately see that this does not follow the regular standard and that something else is up here. But 99% of all developers will not have a clue. They will see OAuth and then go google a tutorial on how to do it in their language. After failing to connect to Yahoo they will return to asking for username and password. > Everything you raised amount to a rant about Yahoo! making you work harder. > The only issue here is whether the extension is costing Yahoo! developers > unwilling to do more work to use its API, but that has nothing to do with the > community. Look, I am billing for the extra work I'm doing. I'm happy to be able to make some extra money due to Yahoo's internal architectural issues, really I shouldn't be complaining. I'm uncertain if by Yahoo developers you mean developers on your payroll or developers working towards your apis. And yes it has a lot to due with the community. OAuth is being sold as a standard. If you use OAuth you can use the same code to connect to Google, Yahoo, Twitter etc. Yes so far it has mainly been used for proprietary apis such as twitter. PortableContacts, webfinger, OpenTransact (the OAuth payment standard I'm working on) rely on being able to do discovery and use common API's without having to fill our code with ungodly amounts of if YAHOO then .... end statements. It is true that none of these standards are finished yet, but all of them rely on having a single canonical OAuth standard. If not what good is all the work you are doing on discovery protocols. Think about it for once as an implementer. API's and standards need to be consistent, testable and usable. It is not a standard if every provider has their own peculiar flow. > I wasn't talking about Yahoo!'s investment to benefit itself. I was talking > about its investment to benefit the community, and in that regard, very few > other companies match up. That is exactly what I am mentioning as well. Many individuals have used many of their own hours tirelessly promoting OAuth, writing libraries, tutorials and helping people out in forums and mailing lists. Don't they also deserve a little respect? > We can discuss the technical details of the extension or how libraries should > be architected in the future to better accommodate this and other extensions > - I am actively doing that at the OAuth IETF working group and you are > welcome to join us. We can discuss how legal frameworks could be made better > and how to improve legal negotiation for community-based projects - I am > actively doing that at the OWF and you are welcome to join us. I have joined the IETF group and will be joining in the conversation there. About the OWF legal group. I was in it and I appreciated your attempt at a plain English approach. I won't comment more here on it as this isn't the space. > You have completely failed to show how Yahoo!'s implementation hurts anyone. > If your point was that this is bad for Yahoo! and hurt its API adoption, it > would at least be a valid perspective of one developer. But turning your need > to do some extra work into an attack on a company that does not merit or > deserve it make this entire rant completely pointless and self serving. I think I have shown above how it hurts the standard. And seriously Eran do not take any of this personally. This is not and has never been an attack on you. Just because I happen to like the people working within Yahoo doesn't mean that I am going to hold my punches. And if Microsoft/Google or anyone else tried to do something like this, I would be the first one out complaining here. It just happens that due to Yahoo probably being the oldest company involved in the process, it is having the hardest time dealing with the concept of open. Respectfully Pelle -- 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
