Developers are lazy folks (or at the best, strive to be lazy).
For them, solving a problem is avoiding work. There may be sizable effort required to get something built and running but the main reason they do it is so that they don't have to do something that requires even more effort. To win support for a given idea, you have to convince other folks that your method is also easier and faster than "the other one". Much like electricity and water, developers favor the path of least resistance.
i was kind of reminded of this fact while reading a post from Eran Hammer-Lahav about the death of OAuth. Having watched the OAuth list for a while, i find it kind of interesting that he is the one noting the protocols reported passing, but anyone who's dealt with the arcane dance involved with getting OAuth to work just right (or even understand the very limited problem it was meant to solve) will probably not be surprised by this proclamation.
OAuth is designed to handle the exchange of tokens between three (or four, depending on how you look at things) partners: The Customer, The Application and The Provider. A "token" (or two, again, depending on your point of view on this) merely ensures that the party you were talking to is still the party you're talking to, and that each party can terminate the connection at any time. That's it. That's all it's supposed to do. There's no exchange of information about any of these parties. There's no hard rule about security around the connection being made. Nothing else. To do this magical process, however, requires three separate tokens and associated secrets, a login screen, and a potentially complicated client based signature method. All of which can be completely baffling, which the spec doesn't really help solve. (On a personal note, i read the spec twice and still managed to screw up one portion of the new 1.0a version. Why 1.0a and not 1.1? That's a matter of discussion.)
i'll note that the other paths of least resistance are things like Facebook Connect, Google Login, Yahoo BBAuth, Microsoft Passport, and a host of others. These are generally easier to deal with for sites because you simply point someone at the login page and get a bunch of credential information back, including information about the user. Of course, the biggest issue with using these is that you'll have a handful of login and credential services, but since you can make the security "someone else's problem" you don't have to care as much. You also don't get to own your user's information and are at the whims of a fickle pantheon of user credential gods who may smite your service for any reason, but again, that's par for the course as far as most services are concerned.
Personally, for various paranoid reasons, i'd want to have an "Open Connect" suite of protocols that used OpenID for login, OAuth for credential exchange and Portable Contacts for automatic customer information fetches. Of course, the problem there is that we're dealing with three different protocols which don't always dovetail and may lead to an even uglier mess to actually implement. Which means that the resistance will be higher.
Which means that either it won't get done, or that i need to wait until the other ones become such a pain that someone else builds a better version.
Because that'd be the lazier thing to do.
