The Ident Engine will accept 4 different ways of inputting a web account address

• http://twitter.com/glennjones
• twitter.com glennjones
• twitter glennjones
• glennjones@twitter.com

There is currently a lot of discussion about finding the easiest way for a user to describe their ownership of a web account. Most systems currently provide a URL that represents an individual, but these can be long and hard to remember i.e.:

• http://twitter.com/glennjones
• http://upcoming.yahoo.com/user/62673/
• http://www.mybloglog.com/buzz/members/glennjones/hcard
• http://www.linkedin.com/in/glennjones

The OpenID community has found that asking users to type in their full URL causes some user experience issues and often creates a barrier to the user.

Any type of web identity discovery system needs two visible pieces of information to work. The DNS name of the service to query and an identifier for the user. The hidden third element is the context of the query i.e. we are searching for information about a person and not some other type of entity.

To facilitate easy parsing it is useful to have a delimiting character that divides the two pieces of information.

How you then construct the input string to identify an individual is less of a technical problem and more an issue of ease and convention. The one I personally find easiest to use is an abbreviated version of the URL: /> /> http://twitter.com/glennjones becomes twitter.com glennjones

The pattern is the web sites DNS then a space and then the user identifier i.e. username. With a closed system like Ident Engine you can go one step further and accept just the name for the website.

The other pattern gaining traction at the moment is the Webfinger email structure. This aims to make the most use of the fairly well ingrained understanding of how you construct an email address and translate that convention into creating an address for any web account:

http://twitter.com/glennjones becomes glennjones@twitter.com

This works best when there is a corresponding email account but can feel a little strange where one does not exist like the Twitter example above.

I have yet to find any publically available user research which backs up either approach.