OpenID Email Discovery

[Trevor Johns]

On Jan 3, 2008, at 1:01 PM, Eran Hammer-Lahav wrote:

> (The full story is posted at http://www.hueniverse.com/hueniverse/2008/01/addressing-open.html 
>  but this contains the technical parts of the post).
>
> This proposal adds Email Discovery allowing users to use their email  
> address as an OpenID.
>
> …
>
> We need to map between the email to the OpenID identifier and this  
> is where DNS comes in. DNS already has a system for resolving email  
> addresses into an actual server – email resolution using an MX  
> record. Why not add a new record type for OpenID. Basically another  
> way to perform OpenID discovery that is all about making it user- 
> friendly.
>
> All that is needed is a URL the site performing discovery can append  
> the email to and treat it as an OpenID identifier. This can be done  
> using a OpenID TXT record: ‘OpenID [username rule] [priority] [URL]’  
> where [username rule] is a wildcard expression used to match the  
> username part of the email (everything up to the ‘@’), [priority] is  
> the MX-like priority value, and [URL] is the URL used to generate  
> the OpenID identifier. The URL uses ‘*’ to indicate where the  
> username is inserted, and ‘**’ to indicate where the full, URL- 
> encoded, email address is inserted (both optional). For example:
>
> example.com   TXT   ‘OpenID * 10 http://*.example.com/’
> example.com   TXT   ‘OpenID joe 10 http://example.org/openid?**’
>
> Which reads: for any email address ‘@example.com’ other than ‘joe’  
> use ‘http://username.example.com/’ as the OpenID identifier. For  
> email address ‘joe at example.com’ use ‘http://example.org/openid?joe%40example.com 
> ’ as the OpenID identifier. Rules are processed first based on the  
> username rule match (in order of match closeness) and then on  
> priority which is used in the same manner as MX records priority.

Erin,
While it sounds nice at first glance, there's are a number of problems  
I see with this:

1. As has already been pointed out, this really is a job for SRV  
records. People got angry enough at SPF for using TXT records.

2. This is dependent on email providers implementing their own OpenID  
providers. While I can see some of the larger email providers doing  
this, I don't think smaller ISPs will be willing to. Just look at the  
number of ISPs who have implemented XMMP servers.

3. What if an email provider doesn't provide an OP at first, but then  
a year or two down the road decides to implement one? This puts the  
burden on SPs to always check their local user table before performing  
discovery, and leads to an inconsistent user experience.

4. This ties a user's identity to their email provider. This might not  
be so bad if they're using a webmail service, but it's a disaster if  
they're using ISP provided mail. If the user does the right thing  
(IMHO) and uses delegation, then they'd no longer be using an email  
address. In other words, there's no way this can be used safely.

5. It's obvious that this can't completely replace traditional OpenID  
URIs. Just to start, there's no concept of directed identity. This  
means that either users will have to either: be taught that email  
addresses are valid OpenIDs, at which point you might as well use URLs  
anyway; or provide both an OpenID and an email address field when  
logging in, which will lead to a confusing user experience.

6. I can't see how this can be used securely. DNS is highly vulnerable  
to attack. This can be mitigated in traditional OpenID URIs through  
the use of HTTPS at the claimed identifier and at the OP. If the  
user's email address is used as the claimed identifier, there's no  
room for HTTPS. If the OP-local identifier is used as the claimed  
identifier, then the user has to be educated to watch and make sure  
that this identifier is displayed by the SP. But if they know their OP- 
local identifier, why don't they just use that in the first place?

-- 
Trevor Johns
http://tjohns.net