[OpenID] The Various Methods For "user at domain.com" Style Identifiers

Recordon, David drecordon at verisign.com
Fri Feb 9 07:35:24 UTC 2007

So this is a debate that I know I've been hearing for at least six
months now.  Dmitry's proposal this last week of actually connecting to
the MTA is different from previous discussions and I do believe has its
own merits.  With that said, I think it makes sense to layout the
various options on the table so that we can weigh pros and cons.  Thus
far, I haven't seen a single solution which really "wows" me to the
point of knowing it is the right one.

1) Static method of transforming to URL (user at example.com ->
http://user.example.com, http://example.com/~user, etc)
2) Treat as just a way to bootstrap discovery (Yadis on
http://example.com and assertion about some URL)
3) Bootstrap discovery and make assertion about original format (Yadis
on http://example.com and assertion about user at example.com)
4) Treat as email address and contact MTA (DNS query for MX record on
example.com and then query MTA for XRDS of user at example.com)
5) Treat as Jabber ID and contact Jabber server (DNS SRV record for
Jabber server then query for XRDS of user)
6) Treat as an HTTP auth url (Yadis on http://user@example.com)

I'm not really sold on any of them.
 - I think the static transformation will run into too many legacy
deployment issues.
 - Just bootstrapping discovery will confuse users since the RP will
recognize them as a URL versus email style identifier
 - I actually like this one. :P
 - Annoying to modify MTAs and how do you know it is email versus
 - Annoying to modify Jabber servers, people will expect it is an email
address, how do you know it is jabber versus email.
 - Possible weird reactions by web servers.

So I guess my preference is the 3rd option, where you bootstrap
discovery on the domain portion, pass "user at example.com" as the LocalID,
and have the OP make an assertion about that actual identifier.  It
removes the issue of email vs. jabber, though requires you run a
webserver at the root domain and have one OP for every user.



More information about the general mailing list