Dan rants: Drizzle: A response to HailStorm

(Yes, the name sucks, and is already used by a Puget Sound Internet Provider . Come up with a better one. Please.)

With Microsoft's release of HailStorm there's been call for an open alternative that could be deployed quickly, and in parts, to provide HailStorm like capabilities to other providers, and without entrusting security of personal data to Microsoft (which has shown itself singularly unworthy of such trust).

How It's Used

A SOAP or XML-RPC interface which allows a user or web based application to send a user approved subset of personal data when an application asks for it. This could easily be expanded upon to provide better password tracking and eventually automated contact notification.

Here's the use-case as I envision it:

The user chooses to "check out" their shopping cart at an e-commerce site, or post a message at a discussion forum, and along with the usual sign-up page sees a "Register me via Drizzle" graphic.

They dragging that link URL over to their Drizzle app on the desktop, at which point the Drizzle enabled personal information manager queries the site to find out what information it's requesting, then pops up a confirmation box allowing the user to choose what information to send for each of the fields.

Drizzle then sends all of this data to the site, and the user can hit the "continue" button without having to reenter all that data that sites ask for all the time.

In the background, a Drizzle app could also manage email confirmation automatically, keep track of passwords for different sites, and by simply resending the updated data could easily be expanded to send sites current contact information akin to the HailStorm ICQ/pager/email tracking.

Paranoid users could run a Drizzle client on their own machines, although it's easy to see how a web client app could be written for this too.

An Implementation

I've implemented the first stage for Flutterby, although I'm in the process of learning enough Perl::Tk to clean-up the end-user application before I release this on the world.

When a user is prompted with a sign-up screen on Flutterby, they'll have a button with a URL that looks like:

http://www.flutterby.com/archives/drizzle.cgi?324198

The application takes this URL, extracts the bit before the '?' and uses that as a URL to send XML-RPC calls to, and the bit after the '?' becomes the session ID.

The API that drizzle.cgi implements is:

drizzle.getUserAttributes()

Returns an array of structs. The struct has two fields, the string name which has values like "name" (the user's real name), "password", "email", "handle" (preferred login ID), and a boolean required which is whether the subscription can succeed without this information (ie: my system likes having the email address, but doesn't require it).

drizzle.createUser(string session_id, array userAttributes, array validationUrls)

session_id is the session id derived from the URL, userAttributes is an array of structs with name and value pairs for the proper attributes. validationUrls is a set of XML-RPC URLs that the web site server application can compare against its trusted list to verify information (the details of this have not yet been implemented). This returns the handle (since my system handles spaces, in my implementation this is just the user name) and the password actually used.

If drizzle.cgi gets called with a "GET" or with the "?324198" extension, it redirects to a URL that handles logging in the user with the user attributes that the Drizzle enhanced application sent and setting an appropriate cookie in the browser.

Future Expansion

Things that this needs:

• A list of appropriate attributes. A start might be:
  • name the user's real name
  • password the password the user has selected for this site
  • email the user's email address
  • handle the user's preferred handle if the email address or name aren't used
  • credit card info type, number, expiration date, name as it appears on card
  • billing address
  • shipping address
  • country
  • state
  • zip
  • date of birth
  • gender
• Automated email verification. Some standard for how the email verification message is formatted so that it can be automatically filtered and responded to.
• An "update user information" call that lets a user say "contact me this way now"
• Some thought on security!!!!

Suggestions are very appreciated. Comments on the Flutterby discussion can go below, there's discussion of such things on the WebWide mailing list, and I expect discussion over at Wes Felter's discussion forum .

The Flutterby discussion is off this entry.

Thursday, March 22^nd, 2001 danlyke@flutterby.com