[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