WebFinger is an updated take on the Name/Finger protocol using HTTP, XRD, and host-meta (instead of a direct TCP connection on port 79) to obtain information about user accounts. It works by defining a new account URI scheme and a protocol for resolving it into an extensible descriptor of the account and its owner.

The account URI, using the newly proposed ‘acct‘ scheme, is used to identify user accounts at a given host which are typically used for the purpose of resource management and establishing local identity (at the host). User accounts include a local identifier (username, screenname, or handle), and a host which can resolve and (usually) authenticate the local identifier.

The protocol consists of:

• A URI scheme to identify accounts using a familiar syntax.
• A simple protocol for resolving account URIs into an extensible descriptor.

Account URIs are useful in most places HTTP URIs are accepted. For example, web pages or blog comments can link to it in order to establish an author relation, address books can use it to point elsewhere for contact information instead of maintaining a local copy, and users can use it to log into websites with a familiar, yet portable identifier.

The account descriptor provides public information about the account capabilities and owner. It also provides a way to link to private resources which require authentication or authorization to access. The public information can include as much as the user wishes to expose without requiring authorization.

What Problem is WebFinger Trying to Solve?

WebFinger is trying to address the lack of adoption and usability of current HTTP-URI-based user identifier solutions, most notably OpenID. While some vanity HTTP URIs do gain traction, people associate them as their address on the web, not their identity. Using HTTP URIs as login credentials is still a foreign concept for the vast majority of web users.

Consider the following two login prompts:

Enter your email to login:

Enter the address of your blog or profile page to login:

Or the following input boxes prompts to enter the information of someone to share a photo with:

Enter your friend’s email address:

Enter the web address of your friend’s blog or profile page:

It just doesn’t make sense. It is perfectly valid for machines to use HTTP URIs to identify objects or people internally. But HTTP URIs (or URIs in general) are not at this time, something people associate with their user account (username, screenname, handle, etc.), not to mention identifier.

What seems to work well is email as an identifier. What WebFinger does is take this familiar syntax and use it in its most literal meaning: some ‘at’ somewhere. In a way it is claiming back the rightful place of user accounts as a higher concept than email address. Email is really just one facility enabled by having an account.

In the days of the original Finger protocol, people used local accounts on network-connected servers. Those accounts usually had an inbox associated with it for receiving mail, but the account username was the primary identity, not the email address which was simply a byproduct of having a local identifier on a network host. In other words, you had an account which was email-capable, not an email address used to login to the server.

By defining a way for people to identify themselves and their work online, that does not conflict with email or existing deployment of mailto: URIs (and their expected behavior in browsers and other software), WebFinger opens the door to a wide range of new opportunities to build new and rich experiences that begin with “this is me, Joe AT example.com”.

WebFinger does not attempt to replace any existing protocols. What it is trying to do is provide a method to use an existing successful pattern, email-like addresses, as an identifier. It does not interacts with SMTP or has anything to do with email servers.

Is WebFinger Replacing the Use of HTTP URIs?

No. It is simply offering an alternative that can live side by side and even enrich the current framework.

HTTP URIs made perfect sense for OpenID when the protocol was first introduced because of their massive support and deployment. Using HTTP URIs as an identifier in OpenID meant the protocol could be deployed with the existing infrastructure with very little (if any) changes. The idea is that since HTTP URIs can be easily resolved into documents, users can enter a URI into a login box which provides the service with enough information to send the user over to the right place to authenticate and come back.

What didn’t work out is the idea of entering a URI. From recent usability studies done by Google and Yahoo! it was made clear that the biggest barrier to adoption of OpenID is the lack of intuitiveness in using my blog address to login. On top of that, if you accept the Semantic Web view of URIs for people (aka HttpRange14), those HTTP URIs should not even resolve to a web page. Go explain that to an average web user.

At the same time, HTTP URIs are extremely powerful. As discovery becomes more mainstream and widely deployed, HTTP URIs will be easier to work with as account identifiers. Also, with popular services offering short vanity URIs to their users, the idea of an HTTP address on a business card for your Facebook or Twitter profile will also help change how people view these string.

WebFinger is an attempt to apply a pattern that works today in a way that will enable a grander social web vision. It is a tool for experimentation and trying out new ideas.

Wasn’t this Tried Before?

The idea of using email addresses as OpenID identifiers isn’t new. It was suggested by many people over the past few years and each time hit a wall. The arguments against email as identifiers usually include concerns over spam and privacy, as well as the fact that these identifiers “belong” to the SMTP protocol and can only be used by mail servers. Also, the technical solutions offered to make it work never reach wide enough consensus.

But the real blocker was always the lack of infrastructure allowing the association of metadata about the account with the email identifier. You can’t ‘HTTP GET’ an email address (well, you can – it just won’t produce anything useful). And trying to change SMTP is practically impossible. Previous proposals included fixed mapping of email to HTTP, complex DNS records, and vendor specific services.

There were also much more ambitious attempts at creating a whole new framework of structured identifiers such as XRI. If you encounter a user identifier that looks like ‘=joe’, that’s an identifier for a person. XRI went too far by not relying on a lot of useful existing infrastructure and by trying to do too much. The end result was an extremely complex solution that to many people sounded like a replacement for DNS and other basic web facilities.

It is important to note however, that both the XRI and OpenID experiences are critical inputs into the WebFinger protocol. Not only do they provide us with the more valuable data as to what works and what does not work, they also produced or inspired a significant amount of new work that is critical to how WebFinger operates. XRD is one such technology.

How does WebFinger Work?

The core component of the WebFinger protocol is focused on resolving account identifiers. Its input is an ‘acct’ URI and its output is an XRD document describing the account and related resources. The core flow is:

1. Start with an account identifier: acct:joe@example.com.
2. Fetch the host-meta document for example.com (using DNS and HTTP) and validate the document.
3. Find the WebFinger URI template for transforming the account URI into the HTTP URI of the XRD document.
4. Fetch the XRD document using the template output URI and validate the document.
5. Do something useful with the information provided by the XRD.

In practice, the protocol flow depends on the context in which the account identifier is obtained. A flow in which a person types something into a text box is somewhat different from one in which a person click on a link or visits a web page. Here is a rough overview of the different flows.

A typical User Interface Manual Entry flow:

1. Ask user to enter their email, URI, click shiny logo button, whatever, as long as you end up with either a web address or something that includes a username at a host which you can easily transform into an account URI.
2. If you get an a string with slashes, normalize it into an HTTP URI, HTTP GET/HEAD it, and look for an HTML <Link> element or HTTP Link: header with a WebFinger ‘rel’ value (TBD). The link’s ‘href’ will get you the account URI. Perform the core flow.
3. If you get a string that includes a single @ but does not include slashes, normalize it into an account URI and perform the core flow.

A typical browser HTML <A> flow:

1. While reading a web page, a user click on a link (HTML <A> element) that has an account URI ‘href’ value.
2. Browser performs the core flow on the account URI.
3. Browser displays the received XRD data in a way that is useful to the user (with optional buttons to follow, add as contact, send email, etc.).

A typical browser HTML <Link> flow:

1. While visiting a web page, the browser detects the presence of a link (HTML <Link>) to an account URI with a meaningful ‘rel’ value (such as author, contact, friend, etc.).
2. Browser presents some useful UI to the user to do something with the link (similar to RSS buttons or indicators).
3. If clicked, browser perform the core flow and does something useful. In some cases, the browser can pre-fetch the XRD to enhance the services it offers the user.

Still Have Questions?

Please use the comments section to post your questions, feedback, or concerns and I will do my best to answer them. I will update the content of this post with new information and additional details as we figure them out.

For implementation details, read Implementing WebFinger.

Image inspired by a foam finger photo from promobrands.com.