Phil Wainewright at Loosely Coupled has a timely piece on "Identity as a Service" today. He points out that such services would be useful for "Web 2.0" companies who have enough on their plate already to deliver "the next Flickr", and who don't have the time (or probably the expertise either) to develop code to log their users in manually, to automatically log them in if they've already logged in elsewhere, to authenticate XML-based invocations of their Web 2.0 apps, etc. Remember, many "Web 2.0" companies are very small operations, the "long tail" in effect.
It has been rightly said, somewhere, that identity services could be to Web 2.0 what SSL was to Web 1.0. Identity services are a way to identity the customer (who is also usually a "content creator") whereas SSL was (and is) a way to identity the merchant. SSL put a rocket under Web 1.0, so the hope is that identity services could put a similar rocket under Web 2.0 (i.e. a way to add a "monetization widget" to Web 2.0 apps, as somebody else said).
I've written about this before, in the content of authenticated RSS feeds. Here is the complete post on secure RSS, but I've pasted the most relevant parts of it here, in order to save myself from typing it again.
Client authentication isn't easy
Alexis Smirnov hits the nail on the head here. If a user is authenticating to multiple private RSS feeds using a password, there will be a tendency to use the same password for each (the real-world implementation of what is called "simplified sign-on"). Alexis mentions Project Liberty, which would allow authentication to one private feed to then be used for true SSO (i.e. Single Sign-On, not Simplified Sign-On) to other feeds, without the requirement to re-enter a password. Using SAML 2.0 and Liberty, you can take advantage of the new "Single Sign-Out" also (i.e. you sign out of one feed, and you are automatically signed out of all your feeds).
Aside from Liberty, there is also the very clever "safe single password" method described by Jon Udell here.
Another way to authenticate the clients, without storing passwords at the provider side, is PKI of course. But for the small logistical matter (cough cough) of distributing the keys to the clients, PKI would be the slam-dunk solution for enabling private RSS.
Group RSS feeds
I suspect there is a niche for RSS feeds for small groups who don't have the rock-hard access control requirements of an investment bank or a law firm, but would still like to create a private RSS field for "ourselves alone". The requirement would be to have a Yahoo Groups style method of creating the group, allowing users to self-register, choose their own password, be admitted into the group by an administrator, etc. This seems to me to tie in with what Justin Mason describes here.
Passport did a lot of that, but wasn't acceptable in the market for a number of reasons. What many people are looking for is "passport, not from Microsoft, using more federation and less centralization". But, the main requirement is to make it easy to use.
Phil Wainewright focuses on the Web 2.0 folks. Vordel's products expose identity services today, using SAML and WS-Trust and WS-Security, amongst other standards. We also connect to identity services (e.g. from Entrust's products), and you can read a security journal article here about how we deployed a solution using Identity Services for a large customer . But I'm talking here about corporate customers rolling out SOAs and including Identity Services in the "palette" of services in their SOA, not about Web 2.0 companies. As Phil says, there is a space out there for mass-market identity services. The hard problem, though, is that it is a hard problem. Single Sign-On has never been easy, and although we don't call it Single Sign-On in this case, that's one of the problems that must be solved using Identity Services.
Dave Winer is proposing to make the Google API an open standard. I support that, so I'm linking to it (Dave W says If you support this proposal, please point to this page. Making an equivalence between linking and supporting means that even if you link to it and disagree, you look like a supporter in Technorati. This is the equivalent of the assumption that if you beep your car's horn beside political banner-wavers, you support them). Here is my two cents on it though. The Google API uses proprietary tokens, rather than using WS-Security for the tokens. It would not be hard for it to use WS-Security instead (contrary to popular belief, it wouldn't mean dragging in the rest of WS-*). I would not like to see "Google tokens" become the de-facto standard (or, yikes, the standard) for single sign-on tokens in Web 2.0. I would take the opportunity of the Google API standardization as a chance to make it *use* standards, as well as be a standard itself. After all, WS-Security allows you to do all sorts of other great security stuff (sign, encrypt XML messages) that would involve kludges now with the Google API.
Then, these standard tokens (not "Google Tokens", please) would be issued by the kinds of identity services which Phil W describes, can be brokered by other identity services from one domain to another, other identity can do "single sign-on" (using SAML 2.0, i would recommend), etc.
There is also the possibility that however controls the identity services controls an important choke point (i.e. the argument against Passport), in a similar way to how you can see VeriSign's acquisition of weblogs.com as a grab of another important choke point (on the "provider" rather than "consumer" side, though).
12:03:04 PM 
|
|
