Actually, I don’t have a well-thought, proven, and complete case to make.

What I have instead is some loose consensus from a small group of people and a lot of experience trying other ideas. Historically, this is a bad way to start a discussion about new URI schemes. Getting consensus for new URI schemes is often more difficult than solving American healthcare.

The proposed ‘acct’ URI scheme is designed to identify an account. ‘Account’ is a pretty straight-forward concept. It is some sort of identifier – a string – that is specific to an authority – usually a server or domain. For most people, their account is also their email address, and in recent years, the emphasis on email has surpassed the concept of an account. When I started using the web 20 years ago, I had an account on a server. It just happened that this account has a mailbox associated with it.

A Grand Vision

Almost every single social web protocol and idea starts with the notion of each user having some kind of identifier. This identifier allows us to share pictures, send messages, and control access to our data. When this is done in a closed environment everything is straight forward and simple. But when we try to extend this model to a distributed, federated system, we quickly get stuck on how these discrete systems can identify users across system lines.

Now, granted, we don’t really know how to make the social web truly distributed. We have grand ideas and a lot of good intentions but for the most part, none of that translates into products the average web user can actually understand and use (today). Most web users still don’t get Twitter, and that’s the centralized kind.

The Bootstrapping Approach

But what we do know is that we are stuck in a chicken-and-egg situation where we are forced to use either HTTP URIs or email addresses. Neither one really works / worked. HTTP URIs are good because they are easy to deploy. From an infrastructure perspective, HTTP URIs can be used today, and don’t require any new special servers, software, DNS, etc. But our experience with OpenID has proved (beyond reasonable doubt) that web users just don’t get it. For most people, using an http://something to identify themselves is weird, counter-intuitive, unmemorable, and awkward to use.

Recent usability testing from Yahoo!, Google, and others have shown that when a user is asked for an email address, their success rate using OpenID increases significantly. Which brings us to the other alternative, using email addresses as identifiers. Here we face a different set of problems, mostly dealing with spam and privacy. Because of the critical role email plays today, people are often reluctant to share their email address, and rarely publish it publically. Furthermore, large companies will simply not allow such practices.

Appearances Matter

In a perfect world, it should not matter how accounts are represented internally. Given the right context, we should be able to ask the user the right question and turn that into the answer we need. Instead of asking the user for their OpenID URI (which we know does not work), we could ask them for their screen name at Yahoo! or AOL. Or we can give them a shiny Facebook button to press which will send them over to Facebook and back to us with the identifier we need.

But reality has proved that these internal identifiers leak, and that coming up with a UI that works is extremely difficult. We have all seen blog comments posted using OpenID that look like this:

Posted by http://example.com/identifier/guid/3392830912/asde0

This doesn’t work for humans. What does is:

Posted by 3392830912@example.com

Or even:

Posted by acct:3392830912@example.com

Why? Because as pattern seeking creatures, we can immediately identify the syntax and it makes intuitive sense to us. Something that looks like an email address is acceptable for a person while something that looks like an address for a web page is not. And what we also learned is that asking for an email address as an identifier, is easier and an effective user experience. It is just that we don’t really want their email address but their account. And yes, in many cases, they will be the same.

Why does it Need to be a URI?

Because URIs are how we identify stuff on the web. It is the namespace convention for naming things. It is also too late to change many existing framework to accept some other identifier that is not a URI. The most obvious example is links. Links are the most fundamental building block of the web. If we cannot link from one resource to an account, we lose a lot of functionality. When my identifier is a URI, I can do this:

<link rel=”me” href=”acct:eran@hueniverse.com” />

Without having to create a new context-specific relation type, or any other extension to the link framework. And the semantics of this are pretty straight-forward too.

Can’t it be an HTTP URI?

Yes, an HTTP URI does solve many problems as indicated earlier. But it lacks in a few areas that have proved to be detrimental in getting adoption (using our OpenID experience). Because this is going to be the part most of the discussion is going to revolve around, I am going to repeat some points made earlier and sum it up in one place:

• Inefficient - No direct way of telling what the URI is without performing some discovery on it (or at least a GET). Unless we do something like a well-known URI prefix (like http://webfinger.info/account/authority/local-part), which is, well, awful. Having to perform discovery on an HTTP URI to figure out that it denotes an account is wasteful and doesn’t scale. It also requires a discovery framework that, while is in the works, has to stand on its own first before it can be relied upon (that chicken-and-egg again).
• Disliked by Grandmas – An HTTP URI as an account identifier is completely unintuitive to people as we have learned from OpenID. We want something that looks like email (and works like email in most cases), but is not tied to the SMTP infrastructure (or the XMPP one). These URIs tend to leak out of the machine world and appear in front of users (again, a lot of OpenID experience). It also creates either conflict (if an account URI is also used as a profile page) or confusion (users having both an HTTP profile and an HTTP account URIs).
• Unpredictable - No easy way to ask people to manually enter their account information and construct an HTTP URI for it. Services can assign HTTP URIs to accounts, but knowing my account (username and domain where I login) does not allow me to construct that URI. This means I have no way of providing it to services without either a fixed template (which violates the namespace of the service) or a hardcoded conversion template for each service. Yes, we can use discovery to define such a template for each domain, which is what we are proposing for WebFinger with host-meta, but it’s an interaction that is not necessary unless you want to get more information about the account and not simply name it.
• Context Sensitive – It needs context when used in links. It is clear what <link rel=”me” href=”acct:joe@example.com” /> means. No so much for <link rel=”me” href=”http://example.com/account/joe” />. The first means “I am known as Joe at example.com”. The second means I own the web page at that URI. Not really the same.

How does it Avoid Making Spam Worse?

Since in many cases the account is also an email address, it is reasonable to question how it will avoid the pitfalls of spam and privacy. The new scheme does nothing to solve spam. But it accomplishes not making it worse by not requiring the identifier to be a valid SMTP address. People can ask their providers to mint them account names that are either completely opaque (3297328732) or that are intuitive but not their email address (mailto:eran@hueniverse.com vs. acct:ehl@hueniverse.com). Many systems already offer aliases, so the concept of an alias that is only good for distributed login or identity isn’t a hard concept.

Also, account discovery protocols like WebFinger should accept an account URI that was produced by transforming an email address. I can go to a site and give it my email address as my identifier. The site will then transform it into an account URI (mailto:eran@hueniverse.com -> account:eran@hueniverse.com) and perform WebFinger on that. However, when they get the account descriptor (an XRD document), it will provide a different account URI as my canonical identifier. It is that canonical identifier that will be used to identify me by the service and on the web.

So again, why not make that canonical identifier an HTTP URI? Because users will still see it and will get confused. But more importantly, the future should hold the promise of web users actually understanding the concept of a web account or identity and start using it directly.

Is this a New Idea?

Nope.

XRI attempted something very similar but with a lot more complexity (or, richness, depending on your point of view). One of the use cases XRI was trying to solve was the creation of an abstract identifier that can be used to identify individuals. However, XRI uses a completely new syntax (like ‘=eran’) which requires learning a new format and made it less attractive to most people than HTTP URIs.

Also, in the process of building the Google Social Graph API, Brad Fitzpatrick and the Google team came up with the Social Graph Node Mapper and the ‘sgn://’ URI scheme. SGN’s scope is greater than what the account URI is trying to accomplish, and those extra requirement force it to be less user-friendly. But it clearly shows that there is a need to identify individuals beyond what HTTP URIs offer, as they are widely used today across the social web. It also shows the complexity and customization needed to extract account information today.

Case Closed?

Far from it.

None of these arguments are enough to form a complete picture of what exactly this new account URI is. The reason is that we got here from trying other, easier options, and failed to get the desired result. So we are driven to this solution more out of lack of other options than a clear idea of how it answers all our questions.

I don’t expect everyone to like this idea. I wish I could say I love it, but I am simply content with it. But I am becoming more convinced that playing with an account URI and trying it out, even before we fully appreciate its meaning and operations, is the only way to move forward. We need an identity solution for the web, and we need to start somewhere.

What does it Mean to Click on an Account Link?

I’m not sure. We first need to decide if we want to bind the ‘acct’ scheme with a specific protocol like WebFinger, or to allow it to stand as an identifier that can be used with multiple protocols. ‘tel’ is an example of such identifier that can be used by many different protocols (you can dial it, use VOIP, etc.). I would like to see browsers perform WebFinger when faced with such an identifier and get back the public description of the account (just like in the finger protocol days), or something similar.

This is where all this experimentation is critical.

BTW, What does it Look Like?

For those interested in the proposed syntax of this new scheme, it will look something like this:

acct:username@host

It is compatible with enterprise account systems like Windows Active Directory and UNIX.