SLIde API
Simple Lightweight Identity (SLIde)
What is it? 
SLIde is an HTTP service that returns yes or no for a given username and a signature derived from the user's password.
Checking a username
The server receives a GET request for / with four parameters and returns a simple JSON-encoded response.
The parameters are: 1. username, 2. signature, 3. timestamp. 4. version.
username is sent in the clear.
signature is generated as an RFC2104-compliant HmacSHA1 hash, using timestamp (explained below) and the user's password as the key.
timestamp is the current time as a Unix date, the number of seconds since January 1, 1970 in GMT. The time stamp must be within 5 minutes of the time on the server when the request is received. A timestamp can only be used once per username.
version is a number like 0, 1 or 2. It must be present but in the current implementation, its value could be anything. It's strictly informative. In future versions it may be possible that the version number is used to provide varying functionality.
All params are url-encoded.
The server returns two values: 1. response, literally yes or no, case insensitive. 2. message, a human-readable message indicating, if there was an error, what the error was. Examples of messages: "Timestamp too old or too new," "Bad signature," "No user with that name."
If the response is "yes" the message is the empty string.
Details
Any response other than what is specified above is interpreted as no.
The message is only for display to human users. Software should not try to interpret the message. The server only has two possible responses, yes or no.
Since clients can make requests in bursts, they may cache results for a short period of time. It seems reasonable to remember that bull's password of jerseyshore probably still works up to three minutes from the last time you asked. That keeps the load on the server down.
Example
I find it helps to have a working example to stare at when debugging code that does stuff like this.
For these values:
username = "bull", password = "jersey", timestamp = "1313012245", version = 0
The paramstring is:
username=bull&signature=%E6%2F%B5%BF%F7%A5%05%A9%E3%83%9D%9C%E9%92md%14%90%CB%B9×tamp=1313012245&version=0
Getting the timestamp from the server
To avoid replays of your requests, we require the timestamp in the request to be within 5 minutes of the system time.
You can get the current timestamp from the server and then use that as the time stamp for your request and the string for your signature.
To do so, make a GET request on /timestamp. It returns a single value, "timestamp" which contains the Unix-formatted timestamp.
Example: blorker.com/timestamp
Use-case
SLIde is a server-to-server protocol.
You might have two web-based apps, running on different servers, that want to share a namespace.
So if you're "phil" on one service, you're also "phil" on the other.
Previously I was using Twitter or FriendFeed for this function, but Friendfeed sold to Facebook and Twitter hasn't been as friendly to developers as they once were. It's better to be able to provide this functionality ourselves.
This protocol is meant to fill this need, without relying on commercial services.
SLIde not a banking security system. It's meant to provide access in relatively light security situations, like creating and editing blog posts and tweets. (Hence the "lightweight" part of the name.)
User experience
I suppose there are two ways to approach this, one where the user tells you which server to ask to authenticate him, and one where the domain is assumed.
In the former case, you'd prompt the user for a username that is a full hostname, like dave.blorker.com.
If you knew you were using blorker.com for identity, and only blorker.com, you'd ask for a user name like dave.
A password is a password in all contexts.
In both cases, you would send an HTTP GET, as described above, to blorker.com inquiring about a user named dave.
The connection to DNS
If myname.com is the name of the identity server, then each user has a host that can link to a single document, that provides information the user wants to share with services that he or she has authenticated with. The address for that document is xxx.myname.com where xxx is the username.
We envision that as an OPML file that links to the user's feeds, subscription lists and rivers.
From there, a flow of news can be derived.
Creating a standard?
I was using Twitter for this function, to validate a username/password combination (as are a lot of devs) but they made it more complicated, and I'm not so interested in requiring people to have Twitter accounts these days. Or any commercial brand of identity.
So we do need a standard here. I looked at OpenID and found it was too complicated for what I wanted to do.
I have no particular stake in it being a standard or not, but truth is we do need one.
Design methodology
This is pretty much industry best-practice security but a factored-for-simplicity version.
Prior art
This protocol borrows ideas from Flickr API, OAuth and the latest APIs from AWS. The one it most closely resembles is the Amazon Route 53 API. But it's simpler, yet no less secure, imho.
Amazon Route 53 developer guide: Authenticating REST Requests.
Credits
Thanks to the reviewers: Phil Windley, Joel Spolsky, Ben Adida, Andrew Grumet, Dries Buytaert, Sandy Wilbourn, Philip Greenspun, Marco Arment, Joe Hewitt, Joe Moreno.
Their insights and the questions they raised have helped to make the spec more specific and the format more useful.
Dave Winer
New York, July-August 2011
Updates -- 8/10/11 by DW
Four changes based on reviewer comments.
One more change.
Update -- 8/11/11 by DW
Changed the spec and implementation to allow one request per account per second. Limiting it to one request per second is too much.
Added note about caching under details, and a note about being lightweight under use-case.
Update -- 8/18/11 by DW
Announced on Scripting News.
blog comments powered by Disqus
Last udpate: 8/18/2011; 11:59:18 AM