Map/Normalize Email Address to IdP/OP URL (Was [PROPOSAL] Handle"http://user at example.com" Style Identifiers)

Pete Rowley prowley at redhat.com
Fri Nov 10 18:22:53 UTC 2006


David Nicol wrote:
> On 11/10/06, David Fuelling <sappenin at gmail.com> wrote:
>   
>> Plus, why do we **not** want OpenId to work with email addresses (assuming
>> we maintain the principals of User Centric Identity if we use them?)
>>     
>
> Loss of focus.  OpenID is a UCI system based on URLs.  Someone who
> wants to install OpenID on their web server shouldn't have to get into the
> e-mail business too just to be compliant.  Something else, a Greater
> UCI Infrastructure,
>   
I have no particular axe to grind on the use of email addresses but it 
does strike me that this isn't an argument against them - it is a straw 
man argument in the sense that it silently assumes that  support for 
email address identifiers implies mandatory support for email accounts 
for all IdP's. Elsewhere the reverse straw man argument has also  been 
used, where the assumption was that people with email accounts but no 
OpenID facility at the email provider would be tapping in their email 
addresses instead of the OpenID URL as provided to them /by/ their 
OpenID provider.

It's really quite simple, the AOLs of the world will tell their users 
they /can/ use their email address for OpenID, the email.com /won't/, 
and the idp.com /may/ (even though they don't do email).  As I 
understand it, a large ISP thinks this would be good for their users, 
who already know they have an email address and which to them is really 
their online identity right now.

> might select OpenID as the method for authenticating people who wish to
> be known by their URL instead of their e-mail address.
>
>   
Huh? Where is this greater UCI infrastructure of which you speak? Why 
would /support/ for email address based resolution stop it using OpenID?

-- 
Pete

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20061110/4fd52c79/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20061110/4fd52c79/attachment-0002.bin>


More information about the specs mailing list