[OpenID] Combining Google & Yahoo user experience research

Martin Atkins mart at degeneration.co.uk
Tue Oct 14 22:14:31 UTC 2008


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>



More information about the general mailing list