We actually built some code some time ago to explore this. The basic
insight was:
if we can do Yadis discovery on XRIs (which aren't rooted in DNS),
then we can do Yadis discovery on any other kind of identifier,
whether it's an e-mail address or an ISBN number or what have you --
and once we have a Yadis file for a given identifier, we are home
free because it essentially maps that identifier into HTTP. We
considered three or four different ways of doing Yadis resolution
from e-mail addresses and the like, including the http://
[EMAIL PROTECTED]/ idea that David mentions; under the hood they are
different, but what the user sees is the same.
Usability is the key problem here:
- we confuse the user because suddenly it's not URL-based identity
any more
- we confuse the user because users aren't clickable any more
(except for a mailto: tag, which is confusing in its own right it
most identities pop up a blog or home page)
- we confuse the user because if I type the identifier into by
browser's address bar, it pops up a phishing warning (!) instead of
the user's home page.
We decided that for the time being, it was going to be much easier to
educate users on the need to use URLs as identifiers, than to educate
users to not be confused by the above behaviors.
The situation would change if, say, Mozilla and MSFT were performing
Yadis discovery on e-mail-style identifiers, and directed the user to
their (http) home page from a given e-mail address. Not impossible to
imagine, but certainly not something to expect any century from now.
On Oct 20, 2006, at 13:44, Jonathan Daugherty wrote:
# I'm not actually proposing the IdP make an assertion about
# [EMAIL PROTECTED] It would only be used during the discovery phase
# and then an assertion for a URL be returned.
Ok, I misunderstood. But even in the case where the IdP makes an
assertion about a different identifier, that's confusing, too; you
enter something that looks like an email (and maybe your provider
tells you it even is), but you log into the site as something else,
right?
--
Jonathan Daugherty
JanRain, Inc.
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
Johannes Ernst
NetMesh Inc.
http://netmesh.info/jernst
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
