All webfinger does is take "something that looks like an email address" and returns a machine-readable resource for it.
-- Regards, Kingsley Idehen President & CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Eric,
OpenID uses URLs much like what you’re proposing in order to allow a user to log into a network. However, as other said, Webfinger takes something that looks like an email address and provides information about it. It “looks like” and email address and, in fact, it might be. Or, it might be an acct: URI. That was debated for a while, though I’m not sure if any consensus was reached.
Personally, I like the idea of using an email address as the URI for webfinger. The reason is that email addresses are ubiquitous. That said, it does raise the question as to what one does when a non-email provider has users and wants to provide information about the user. For Twitter, the acct: URI scheme might be just what one needs. In fact, perhaps it might be reasonable practice for one requesting information about “pau...@packetizer.com” to query mailto: and acct:, in that order, to look for information. One or both might return 404.
Paul
I think that The acct: and mailto: protocol portion is the missing piece in my identifier scheme that is needed in order to allow for unique identification of both http://twitter.com/bill and mailto:bi...@twitter.com. An API that retrieves data for both email system users and web profiles can then require that the protocol portion be included in any uses of the webfinger email address-type-things.
I agree. We definitely do not want to re-introduce URIs that are hard for users.
If a user types “bi...@twitter.com”, then the software into which the user entered that identifier should translate that into acct:bi...@twitter.com or email:bi...@twitter.com. Whatever URI scheme we decide, we should choose one and we definitely should not provide different information for, from the user’s perspective, is the same identifier.
Perhaps Eran was right to introduce the acct: scheme to avoid this issue. A twitter ID not an email address, after all. Perhaps input boxes that request this information should not ask for your email address, but ask for your “Internet ID”. If it happens to be the same as your email ID, fine. In the case of Twitter, it’s not. Then we use acct: to query information and an email ID can be one of the data elements returned as a link relation in the XRD.
Paul
For instance, if Twitter ever got into the email business, then could
we infer that mailto:bi...@twitter.com is the same person as
acct:bi...@twitter.com ? Same goes for xmpp:bi...@twitter.com
It would be incredibly confusing if these weren't the same person, but
I could see a company doing something like this. (for legacy reasons)
I think it's definitely reasonable to assume such, not because the ID really is an email ID, but simply because users should not be expected to know whether it is or isn't. Users will not enter the URI scheme.
Technically, the identifier used with webfinger could be either an email ID or an acct: ID. We should just go with one and I'm more included to go with acct:, the more I think on this twitter example. Email clients could also use Webfinger to discover a user's email ID given their acct: ID.
Most of the time, the email ID and acct: will be the same, but the Twitter example is one that shows this is not always the case.
Paul
If someone would have to type in their Twitter URL in a login form to get the benefit of Webfinger, that's not any better a user experience than OpenID; which seems counter to the founding goals of Webfinger.