OAuth spec and a shiny new OpenID.net
October 10th, 2007 - Terrell RussellOAuth
A few days ago, the minds behind OAuth launched the site and declared their spec at 1.0-final. This is big news as many sites are duplicating engineering efforts in creating their own APIs. OAuth is a standardized, open way of managing an API handshake for your web application. OAuth can be implemented by the application provider or by the consumer/widget.
From the front page:
An open protocol to allow secure API authentication in a simple and standard method from desktop and web applications.
It’s a valet key for web applications:
Many luxury cars today come with a valet key. It is a special key you give the parking attendant and unlike your regular key, will not allow the car to drive more than a mile or two. Some valet keys will not open the trunk, while others will block access to your onboard cell phone address book. Regardless of what restrictions the valet key imposes, the idea is very clever. You give someone limited access to your car with a special key, while using your regular key to unlock everything.
At claimID, we’re very excited to see this development, as we’ve been planning for an authenticated API for sometime. We hope to work through our own implementation soon. Congratulations to everyone associated with the OAuth progress. This is another step to making the web more open and interoperable.
As always, our friend Chris Messina is all over it:
Cheers and congrats to all the folks who helped to make this happen. It might be a relatively minor step in terms the development of new technology today, but looking out long enough into the horizon, I think we’re adding a significantly important piece of puzzle that’s been missing for some time.
Definitely an important piece, and until this past week, a missing piece.
OpenID.net
Additionally, OpenID.net got a facelift earlier this week. The new site is much cleaner and does a much better job of explaining what OpenID is, as well as what you can do with one. Congratulations to David Recordon and Scott Kveton for their hard work pulling things together. The OpenID Foundation now has a nicer place to call home as well.
Of course, we’re also tickled to be alphabetically blessed - we’re listed first on the “How do I get an OpenID” page:
October 14th, 2007 at 4:03 pm
myID wasn’t expecting anything like this. So imagine our suprise and pleasure when we found myID on the list at the openID website. It’s great to know that we are in the same league as neat providers like claimID and others. Come see us and join the OpenID fun at our blog.
November 7th, 2007 at 7:23 am
[...] OAuth spec and a shiny new OpenID.net (tags: openauth openid identity identity2.0) [...]
November 19th, 2007 at 4:07 am
Speaking of specs and APIs, is there a particularly good reason why I can’t:
GET http://http://claimid.com/api/get_username?microid=mailto+http:sha1:32b56025d21ba8c1c07ff6915b990bcddda5062f
That seemed to me like it’d be an obvious thing to have around, but it’s not there. Actually, there’s not much of an API at all.
November 19th, 2007 at 4:10 am
Bleh, that API call is wrong, should be:
GET http://claimid.com/api/get_username?microid=mailto+http:sha1:32b56025d21ba8c1c07ff6915b990bcddda5062f
November 19th, 2007 at 4:17 am
Also, when claimID generates a microid, what is the value of the http url component being used?
November 19th, 2007 at 2:46 pm
Bob, thanks for the questions.
My first reaction is that it seems there’s a potential privacy concern about pulling the username given a microid query… but it does seem that the point of publishing a microID would be to announce your ownership of a link…
I’ll think on it some more - it would be useful to check microIDs found in the wild against a database of known items (and we’re really the only one at this point in time). Feel free to convince me/us.
As far as the http component is concerned - we’re using the complete URL provided by the user for a particular link. If they leave off a trailing slash, then it’s calculated that way. This sometimes leads to some confusion, but anything else would be arbitrary on our part and more confusing to debug if something unexpected is being seen down the line.
Thanks.