[OpenID] Relationship of OpenID URLs and e-mail addresses

David Fuelling sappenin at gmail.com
Wed Apr 4 06:05:06 UTC 2007


Johannes, 

Here's my "stream-of-consciousness/thinking out loud" notes that I wrote
earlier today in an attempt to figure out the best solution to the problem
posed in your post.  I wasn't able to come up with a great solution, but
some of my ideas are below.  I hope they are of some use to you.

david

--
This is a tricky problem.  In a typical email-to-URL mapping, it is
generally not easy to guess profile attributes (like email address) from the
OpenId URL itself (i.e., emails can be mapped to OpenId URL's, but not
vice-versa -- the mapping is only one-way).  For example,
http://sappenin.myopenid.com does not really give up an email address.

However, in the "big email provider" example, the fact that the OP
(example.com) is both an OP and a *large* email provider breaks this
"one-way mapping" principal.  Observers of example.com OpenId URLs can guess
corresponding email addresses simply by the fact that the OP plays in both
realms - OpenId and email.  

Therefore, using a static email-to-OpenId mapping protocol (at least [1] and
[2] have been discussed on this list) would seem to leak email address
information, forcing the email provider to deal with increased levels of
spam.

Some Alternatives: 

##Alternative 1a## 
Force users to pick a new "openid" username that is different from their
email username.  So, if I originally have "sappenin at example.com" (screenname
= 'sappenin'), I might pick 'dfuelling' as my openid username, thus giving
me an openid of "http://openid.example.com/dfuelling".  I can login as
'sappenin at example.com', which will simply map to my 'dfuelling' openid.

Downsides: 
- The user now has a 2nd username to keep track of
- The OpenId URL is not easily correlated to the email address (good for
preventing spam, bad for end-users who might struggle with the difference)
- There could be collisions between OpenId usernames and email usernames
among different physical end-users (e.g., I have "email username=sappenin",
"openid username =Johannes", and you have "email username =Johannes" and
"openid username =sappenin").  Not good.

## Alternative 2##
Referencing [1] below, the email address to OpenId URL mapping could return
a different mapping URI template for each email address entered.  Using this
technique, when a user is assigned an OpenId URL, random text could be added
into the URL to obfuscate the <username> portion.

For example, if my email address is 'sappenin at example.com', then my mapped
OpenId URL might be: http://openid.example.com/epsappenin39.  The "ep" and
the "39" are random, so just by looking at the OpenId URL, I can't
necessarily figure out what the corresponding email address is.
'johannes at example.com' might map to
'http://openid.example.com/rtjohannes3k'.  

To make this effective, the OP would want to vary the number of leading and
trailing characters (My example uses 2 leading characters in front of the
username, and 2 trailing).  A real implementation would want to use an
arbitrary number, so spammers wouldn't be able to simply parse off the first
2 and last 2 characters (for example) and arrive at a username.  Plus, a
check should be done to ensure that the end-result in the OpenId URL doesn't
collide with a valid email username.  

Downsides: 
- The OpenId URL is not easily correlated to the email address (good for
preventing spam, bad for end-users who might struggle with the difference),
although this problem is less than in A1.

[Side Note: To make A2 work, the [1] protocol would need a minor tweak to
tell RP's that each email address will have a different URI mapping template
(as opposed to a single template for all email addresses in a given domain).
I plan to add that into the spec in a few days.]

## Alternative 3##
Assuming the point of your question is really, "how can this big email
provider allow its users to use their email addresses as OpenId's at login",
then example.com may only want to "support" openids, but perhaps not
*provide* them.  For example, 'sappenin at example.com' might map to
'sappenin.myopenid.com', or some other OP provider that the user chooses to
use.  This would preserve the privacy of the email address, since the email
address could map to any OP provider.

Downside: 
- The "Big email provider" example.com is no longer an OP per se, but is
instead simply allowing its users to map their email addresses to an OpenId
URL of their choosing (Maybe this is a downside for example.com, but perhaps
not for the end-user.  I would love it if I could map my AOL email address
to 'sappenin.myopenid.com', and have AOL provide the supporting glue to tell
RP's the correct OpenId URL to use, without forcing me to use an AOL OpenId
URL).

(Not meaning to pick on AOL, just using them as an example).



[1]
http://www.sappenin.com/openid/ext/oet/openid-email-transform-extension-1_0.
html

[2]
http://blog.phpbb.cc/2007/02/04/smtp-service-extension-for-yadis-discovery


> -----Original Message-----
> From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
> Behalf Of Johannes Ernst
> Sent: Tuesday, April 03, 2007 11:01 AM
> To: openid-general
> Subject: [OpenID] Relationship of OpenID URLs and e-mail addresses
> 
> Assume you are hosting millions of e-mail addresses for your
> customers, like
>      <username>@example.com.
> Now you decide to also become an OpenID Provider for your customers.
> 
> It would be straightforward to automatically create an OpenID for
> each of your users, e.g. like
>      http://openid.example.com/<username>
> 
> Every spammer in the world will realize that this is how the scheme
> works, and they will harvest all URLs on the net that start with
> http://openid.example.com and spam the heck out of your users. Right?
> 
> However, having different <username> components for e-mail and OpenID
> is more complex (e.g. how do I explain this to mass-market customers?
> How many users will bother to pick a new handle for their OpenID?)
> 
> Does anybody have any ideas how to best solve this conundrum?
> 
> 
> 
> Johannes Ernst
> NetMesh Inc.
> 





More information about the general mailing list