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

David Fuelling sappenin at gmail.com
Fri Oct 24 19:49:18 UTC 2008


On Tue, Oct 14, 2008 at 10:14 PM, Martin Atkins <mart at 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 'david at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081024/63e1ff1f/attachment-0002.htm>


More information about the general mailing list