WebFinger

I was thrilled to see work begin on WebFinger, particularly caught by the very simple premise of John Panzer in his description of the problem:

The Personal Web Discovery Problem: Given a person, how do I find out what services that person uses?

He breaks it down further by noting that the email address is a powerful personal identifier. That strikes me as the core of what is needed, that is, a way to go from an email address to an HTTP URI. Once you get to a resource on the web all the good infrastruture in place kicks in, and you get hypertext, caching, redirects, etags, etc. all 'for free' once you make that jump.

Since then work has progressed on the WebFinger mailing list and I stopped paying attention. My attention was brought back to it recently because of a conversation on atom-protocol.

For something with such a very simple premise, what exists now under the name WebFinger strikes me as very large and complex solution with a lot of moving parts. The current proposed solution now involves URI Templates, the XRD format (which involves signatures and thus Canonical XML), the .well-known URI space, a new URI scheme: 'acct', and maybe even some DNS records.

I believe the solution can be much simpler:

1. Parse the email address into local-part and domain.
2. Use the domain from the email address to construct the finger URI:

   http://<domain>/.well-known/finger

3. GET the JSON document at the finger URI. The body of the response will be a JSON object:

   {
     "finger": "http://example.org/{local}"
   }

   The object has a key of 'finger', and the value at the key 'finger' is a string, a URI Template with a single variable: 'local'.
4. Substitue the local-name part of the email address for the {local} part of the URI Template and expand the URI Template.
5. Do a GET on the generated URI to retrieve a JSON document, a dictionary:

   {
     "OpenID": "http://...",
     "blog" : "http://bitworking.org",
     ...
   }

You will note that there are no special DNS records used, no XRD, no new URI scheme, and no Canonical XML. All the representations involved are JSON. I don't see any reason to restrict what the values are for the second dictionary, so the value of 'blog' could just as easily be an array of strings if there was more than one:

{
  "OpenID": "http://...",
  "blog" : ["http://bitworking.org", "http://wellformedweb.org"]
  ...
}

Now the one thing you might point out is that there could be conflicts over key names in the dictionary, but that could be easily resolved by having a simple wiki-based registration for keys, just like is done for 'rel' extensions in HTML5. That same registry could also document what the values for the key are expected to be. For example, the entry for 'blog' could explain that the value is a list of strings, where the strings are URIs.

Even though this is extremely simple there are still two points of extensibiliity: adding new 'key' values to each of the two JSON objects returned along the way.

Ideas are fine, but code is better, so I started with DeWitt's previous working code and modified it to follow the above algorithm. The web interface is running at http://webfingerclient-jcgregorio.appspot.com/ and the code, a branch of DeWitt's code, is available as http://code.google.com/r/joegregorio-webfingerclient/. Kudos to DeWitt, it was his very clean code that make creating this demo easy. The only address that supports the above algorithm right now is joe@bitworking.org.

Note: This was also posted to the WebFinger Mailing List, but it doesn't seem to have cleared the moderation queue yet.