Journal Journal: Proposal for an User ID API
As a website developer and administrator, I've explored the OpenID site, read the recent articles about Microsoft's tentative endorsement of it, studied the comments about the announcement on Slashdot, and I confess it still doesn't fully make sense to me. What would make sense is a User ID API along the lines of what Google is now offering with their GData API suite. It wouldn't necessarily have to be Google, but it would probably have to be an established email or login broker like Google, Yahoo!, MSN, perhaps even Wikipedia or Myspace. More ideally, still, it might be a non-profit or government organization. (If we're going to have a SSN or national ID card, why not a national email address? The states of CA or MA could lead the way if necessary, though I admit I'd have more faith in a Google or Yahoo.) More than one API would be fine, as long as they were simple to deploy, as protective as possible of user's privacy, reliable and convenient, and attractive to smaller site admins.
How would it work? Here's a rough scenario based on how the Google API functions. Imagine you have a blog where you'd like to limit comments from new, unidentified visitors but don't want to put them through the hassle of registering with your site or solving a CAPTCHA every time they visit. You have your comment form with email field. When unknown visitor submits comment, the info gets relayed to the appropriate API server, which then could return relevant authenticating data. This data might include:
boolean indicating if active cookie is currently set for visitor
unix timestamp indicating when this account was created/registers
unix timestamp indicating last time this account was active
user's display name
url for hot-linkable user profile image (opt-in)
other opt-in profile information
The API would enable the site admin to define restrictions and hurdles based on the data returned. For instance, if the site admin finds she is getting a lot of spam for Gmail account created within the last three days, she could create script to require CAPTCHA validation for accounts less than 3 days old, etc.
The incentive for account authenticating services like Google or Yahoo would be obvious.
The drawbacks? The first one that springs to mind would be the leviathan one: do we want to centralize this service and trust public ID authentication to a large corporation (Auth Super Site) like Google or Yahoo? Wouldn't they be in perfect position to abuse this power down the line? Perhaps. The service would necessarily require aggregation of data with a large, central authority. But this has already been done with the major webmail and social networking site, which is why they make perfect candidates. And the data does not have to be that personal. Basically, just a user id and something indicating that the user has been around for a while and is not a spammer or hacker.
Also, the service could allow site admins to send data back to the Auth Super Site on abusive behavior. For example, code:900 (possible spam) user input:love your site, hey check out mine.
Such a service would seem to fit hand-in-glove with what Google is doing with their ClientLogin API and Analytics and Website Tool services. (Perhaps they have something like this in the works?) I'm a big proponent of this kind of service. Is anyone else hoping for something like this? Is there some falsifier or are there other drawbacks that I'm missing?
