[OpenID] Combining Google & Yahoo user experience research

[Johannes Ernst]

First things first. I agree it's not clear which e-mail address to  
XRDS resolution approach is the best. But viable approaches can be  
found and that makes this secondary to the issue I wanted to raise:

What about -- instead of "merely" figuring out how to use e-mail  
addresses for OpenID and friends -- we treated an e-mail address as a  
form of HTTP address all across the web?

This means: all e-mail addresses become REST-ful. E.g. you can type  
them into your browser and, at the minimum, they support a redirect to  
the "real" page.

OpenID aside ... would that be useful for the web?

Assuming that it would be useful, and some mapping could be found  
that, say, browsers understand, we'd have a non-problem in an OpenID  
context because the web would already make sure they are the same.  
(using the term "web" loosely here ...)

Now I might be dreaming here, but from my point of view,  
architecturally this approach would have many nice properties.

Even if that might just be boiling an ocean too many, it might make  
sense to design the solution to the here-and-now problem re OpenID in  
a fashion that was consistent with that vision.


On Oct 14, 2008, at 15:14 , Martin Atkins wrote:

> Johannes Ernst wrote:
>> It could be a as simple as resolving an e-mail address to an XRDS  
>> file, which contains a "home page" service entry.
>
> I think the "resolve an email address to an XRDS document" step is  
> the hard part.
>
> There have been various proposals for this, with varying degrees of  
> purity, flexibility and pragmatism. Some of them are mechanisms for  
> mapping an email address to a URL at which you can do XRDS  
> discovery, and some are mechanisms that map an email address  
> directly to an XRDS document. Ones I recall off the top of my head  
> are:
>
> * Do XRDS discovery at a URL formed by taking the email address  
> domain and adding "http://" to the start and "/" to the end. This  
> requires that whatever's declared in the XRDS file be able to map  
> the username part onto a URL which has not yet been handled. It also  
> requires all email domains to have HTTP servers associated with them  
> and hard-codes the root path. It also does not allow for the use of  
> HTTPS. This is the approach that the EAUT specification went[1] for.
>
> * Do similarly to the previous bullet, but send the username part in  
> the request somehow. One suggestion was to fake up HTTP Basic  
> authentication with an empty password. Requires the root of the site  
> to handle the username mapping, though. Most of the same drawbacks  
> from above apply.
>
> * Define a hard-coded mapping like thingy at example.com becoming http://example.com/~thingy 
>  . Again, requires all email domains to have associated HTTP  
> servers. Also requires a particular URL scheme that may conflict  
> with stuff that already exists at a given domain.
>
> * Define how to map email addresses onto XRI and use XRI resolution  
> to get an XRDS document. (Mostly I just suggested this as a joke,  
> but for the sake of completeness...)
>
> * Extend SMTP with a command that allows clients to request an XRDS  
> document for a given email address. Callers would then do an MX  
> lookup on the domain as normal and issue this command to one of the  
> declared servers. This is probably the most "correct" of the bunch  
> since it asks the correct authority (the mail exchanger) for the  
> information. However, successfully extending SMTP is unlikely both  
> from a specifications and implementation perspective.
>
> * Have domains publish DNS NAPTR records[1] that can map an email  
> address onto a URL that represents that email address for XRDS  
> discovery. Most people aren't familiar with the NAPTR DNS record  
> type, though, and feedback was that email providers don't want to  
> screw with DNS.
>
> * Have domains publish DNS TXT records of a particular format that  
> serve the same purpose as NAPTR in the previous item. Slightly less  
> pure, but more accessible on cheap DNS hosting services.
>
> Most of these came from this one discussion thread on Brad  
> Fitzpatrick's weblog:
>    <http://brad.livejournal.com/2357444.html>
>
> In short, this is not an easy problem. All of the above proposals  
> have drawbacks of one sort or another, whether it be difficulty of  
> implementation, layering violations, dubious assumptions or security  
> holes.
>
> [1] <http://eaut.org/specs/1.0/>
> [2] <http://www.faqs.org/rfcs/rfc2915.html>