Yesterday morning I left a comment on Mark Suster's Power of Twitter post, relating to the challenges of identity convergence across namespaces (clarifications added).
Can twitter be challenged by an open protocol/channel like Evan (Prodromou) and others believe with ostatus? I believe so, but the relationship between identity and feed source needs to be resolved (UI). When I retweet a post the context and relevance of @username has significance in the twittersphere. Outside of twitter webfinger to bothsidesofthetable.com becomes a symbol for Mark Suster (specifically user@domain). This is the design issue I got caught on while working on OpenGard.in an open social feed reader and it's non-trivial. I plan to follow up and keep working it as resources allow.
Mr. Suster's post was a tip of the hat to the incredible consumption power of twitter as a news and information routing tool. Mark's response to my comment alluded to an identity glue between two popular services.
I had friends who built integrations where if you Tweeted an @ sign and sent to Facebook it converted to your Facebook name. It's true that we need a better integration across namespaces
As a developer I'm aware of the problems with converging symbols across namespaces. Instead of @victusfate a more web friendly description of my twitter identity is twitter.com/victusfate, the URL to my stream. The form webfinger utilizes is username@domain.extension which by no coincidence is the same format as an email address.
People have been trying to use URLs as identifiers for people (as OpenID does), as it has great readability/discoverability properties, but this effort has largely failed because of UI/UX design failings, user confusion about URLs, etc.
It's now increasingly accepted that email addresses would be good identifiers for people (since that's what people are used to already, and have on business cards and in their addressbooks, etc.), but we're back to the original problem that email addresses are write-only.
If I give you my email address today, you can't do anything with it except email me. I can't attach public metadata to my email address to give you more information.
WebFinger is about making email addresses more valuable, by letting people attach public metadata to them. That metadata might include:
public profile data
pointer to identity provider (e.g. OpenID server)
a public key
other services used by that email address (e.g. Flickr, Picasa, Smugmug, Twitter, Facebook, and usernames for each)
a URL to an avatar
profile data (nickname, full name, etc)
whether the email address is also a JID, or explicitly declare that it's NOT an email, and ONLY a JID, or any combination to disambiguate all the addresses that look like something@somewhere.com
or even a public declaration that the email address doesn't have public metadata, but has a pointer to an endpoint that, provided authentication, will tell you some protected metadata, depending on who you authenticate as.
... but rather than fight about the exact contents of that file, WebFinger is about making that file discoverable at all. The community can explore and innovate within that discovery file later.
This way victusfate on service X isn't in conflict with victusfate on twitter or any other service. A URL based global ID approach is implemented by the openID initiative and requires a server (self hosted or third party) hold your web identity and credentials.
OpenID was created in the summer of 2005 by an open source community trying to solve a problem that was not easily solved by other existing identity technologies. As such, OpenID is decentralized and not owned by anyone, nor should it be. Today, anyone can choose to use an OpenID or become an OpenID Provider for free without having to register or be approved by any organization.
Another identity method which I don't have time to go into great detail in the remainder of this post is OAuth. OAuth uses a third party service to hold your identity like OpenID, but in this case control of identity is restricted to platform providers (Twitter, Facebook, Google, etc).
No matter which tactic is used for identity on the Internet, there are hindrances to portable ID which I hope (and work) to see solved in the next couple of years. Services, URLs, email addresses, and authentication methods all have limited ability to enable cross service compatibility without requiring repeated effort from developers and repeat account creation by users.