People in the address bar with Webfinger

I've been following the discussion of Webfinger with a lot of excitement, lately. I think it is an idea that could really move the Personal Web forward.

The essential idea of Webfinger is this: your online identity tag should be readable.

The decades-old finger protocol provided readable identity tags. By simply typing the finger command, a username-domain pair, usually an email address, ("joe@somewhere.com") was converted to a free-form text message ("Hi, this is Joe. I work on whizbangs at Somewhere Labs.").

This was such a minor feature of the early Internet that we hardly noticed when it went away. But go away it did, and it left a hole. There is now no reliable way to convert a short, user-friendly identity token to a public information snippet.

What we have instead is a confusing set of overlapping, sometimes contradictory, products and features. OpenID tried to define a user endpoint as a URL, but most normal users are confused by that - we've taught them that URLs are for documents. The large consumer web services have tried offering personally-branded profile pages, but the information on those pages is incomplete.

What I really like about the WebFinger protocol is that it took a step back and said, "what are the users doing?". What is the identifier that end-users are really using, and how can we make that readable? The identifier, of course, is an email address. They're on business cards, brochures, and billboards, and every user of the Internet understands that they are personal and unique.

The technical details are a subject for another post. But the core user proposition is this: with Webfinger, email addresses (or email-address-like-things) are readable. That doesn't mean they have to be readable. It doesn't mean you are required to disclose personal information keyed on your email address. But it creates a discovery mechanism, keyed on an identifier that end-users understand, for per-person information, in a human- and machine-readable format.

WebFinger in the browser

WebFinger has a server piece and a client piece. The server piece is two-fold: first, a new piece of metadata needs to be provided by the domain controller, explaining where to find the user's data and how to ask for it, and second, some server has to present an XRD document when asked for the user's info. Discussion is ongoing about how to serve up that metadata -- it could be in a well-known location on your webserver, or in the DNS system, or some combination of the two. The XRD piece is pretty simple: Google and Yahoo have prototyped it already, and I have a prototype up and running for Mozilla.com that talks to our internal LDAP server. (update: it's not running right now!)

The client piece requires that the requester retrieve the metadata, interpret it, create a URL that defines the end-user, and retrieve that URL.

I've implemented an experimental add-on that does the client piece and displays the XRD in the browser. Since the XRD is XML, I just add an XSL directive to it indicating how to turn it into pretty HTML for humans. I also tried out a proposal for embedding Portable Contact data into the XRD, so I could put some human-useful information right into the page. For my protocol handler, I used the 'acct' scheme, which has been proposed for WebFinger... in a final version, I would really prefer to find a way to make that disappear for the end user, and put some clever disambiguation logic into the address bar.

Here's how it looks to the user:

And here's how it looks to a computer (you'll notice I made up a bunch of stuff -- this is just for demo purposes!):

Interfaces, Descriptors. and Discovery

So why does this matter? Eran Hammer-Lehav said it well in his IIW 009 presentation:

When we define a discovery process for a group of objects, we can easily match our capabilities to the interfaces of new objects in the group.

What we are trying to create is an open, participatory, generative identity platform for the Internet. That means that we need the set of services that are associated with a user needs to be flexible -- hackable, even. A lightweight description of what information a user provides, and what services they provide or consume, could be a really useful foundation for that experience.

There's a ton of stuff missing, of course: in the current incarnation, WebFinger is only useful for public information, there's a ton of security issues to work through, and there's a bunch of issues related to phishing and spam that need to be worked through. But it is a really interesting experiment.