By Dave Winer on Monday, August 15, 2011 at 12:20 PM.
Twitter filled a lot of needs when it came on the scene because it had a simple API, and promised to do something that wasn't just useful to people, it was also important for apps. It was a simple lightweight always-up (theoretically) notification service. One app could listen on a Twitter socket for a message that could be sent by any number of other apps, running anywhere on the net. This idea had so much potential and is one of the reasons Twitter was so attractive to developers.
I think the founders of Twitter had this vision too, but from the other side. My guess is they thought it was a neat idea to have something that was both usable by people and apps to do this one very simple thing.
Along the way Twitter became useful for other simple things, for apps. When I wanted to throw together a simple app and make it usable by other people, rather than create my own identity server, I would just use Twitter's. I'd ask the user for his or her Twitter username and password, and throw it over my shoulder to Twitter, asking if there is such a user with that password. It saved me the trouble of having to ask for a username, manage an account, etc. I knew there was only one user with a given name, because Twitter enforced that rule for me. I also used identi.ca and FriendFeed this way in different apps. Basically, any web service that could authenticate a username and password would do.
I realized, in the last year or so, that I wouldn't be able to continue to use Twitter in this way, for a couple of reasons:
1. The simple indentity service is gone, replaced by something more complex, based on OAuth.
2. Twitter has become more of a managed platform, less of a resource that anyone can use any way they would like.
So, I set out to design a very simple, lightweight identity service. One I could use in my own apps, the way I had been using Twitter.
It didn't take long to design because there's plenty of prior art, and because it doesn't do anything more than validate username and password combinations.
A few weeks ago I had a draft spec with a working implementation. I sent the spec to a small number of distinguished reviewers: Marco Arment, Dries Buytaert, Phillip Greenspun, Andrew Grumet, Joe Hewitt, Joe Moreno, Joel Spolsky, Sandy Wilbourn, Phil WIndley.
I got a whole bunch of ideas and critiques, and implemented many of them, updating the spec accordingly.
I found this way worked a lot better than developing something and then offering it immediately, publicly. Normally I wouldn't get this much feedback and it wouldn't be so thoughtful.
Anyway, this is a heads-up that I will be publishing the spec as a draft in the next few days. But first I want to establish the motivation (that's the purpose of this piece), then explain the philosophy about standards (this is in no way intended to be one) and what prior art influenced me. If other people find this useful, I hope there will be implementations in other languages. And there will need to be ancillary services.
One of the reviewers said he couldn't believe there wasn't already something like this out there. The answer is of course, there was -- it's one of the things Twitter could have been. If I were in their shoes, three or four years ago, I might have stripped the service down to just identity and let a thousand flowers bloom in services built around it. That was certainly one of the possibilities. But they didn't go that way, so the need for an alternate simple lightweight identity service was created.