Resolve an Email Address to an XRDS file (WAS: Combining Google & Yahoo user experience research)

[David Fuelling]

On Tue, Oct 14, 2008 at 10:14 PM, Martin Atkins <ma...@degeneration.co.uk> 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. [Mechanisms] 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.

I could be off here, but it seems like we should make a distinction between the "discovery" that you talk about above (i.e., Personal XRDS Discovery), and "EAUT Discovery", because they both result in an XRDS document, but are two different things. 

EAUT Discovery is specific to the EAUT protocol, and results in an URL that (when resolved via HTTP) results in an XRDS document that the EAUT protocol can use to determine how to map an email address to a URL (i.e., use a Template, or use a mapping service).

Personal XRDS Discovery (which is what I think you're referring to above, and what Johannes is looking for) is a second "discovery", which would occur by http-resolving the final EAUT URL (i.e., the end-result of the EAUT protocol).

After reading your last sentence (and taking into account the two different types of Discovery), I'm not sure I see a problem.  Am I wrong there?

It also requires all email domains to have HTTP servers associated with them and hard-codes the root path.

Not necessarily.  For email domains that don't have an HTTP services associated with them, EAUT falls back on a mapping service provider of the RP's choosing (not the domain owner).  So, EAUT can be used by the person who controls the email address, even if the domain owner doesn't yet support EAUT (though EAUT allows the domain owner to re-assert control of their domain by supporting EAUT). 

Additionally, EAUT always allows for, and follows, all 302 redirects, meaning the root path is not necessarily "hard-coded".
 

It also does not allow for the use of HTTPS. This is the approach that the EAUT specification went[1] for.

This is semi-inaccurate.  The email 'da...@sappenin.com' can resolve to http://openid.sappenin.com, which can simply redirect to 'https://openid.sappenin.com'.  I agree this isn't perfect, however, so it may be advisable to adjust the EAUT spec to optionally try the https:// scheme first, and failing that, look for a EAUT XRDS in the 'https://' scheme. 

The EAUT spec is by no means finalized, so I'd encourage you to work on the EAUT lists to alleviate any of these issues -- I believe EAUT can be used today to resolve a Personal XRDS document from an email address in a very flexible way.