[OpenID] FW: PROPOSAL: An Extension to transform an EMail Addressto an OpenId URL

Eric Norman ejnorman at doit.wisc.edu
Sun Feb 11 00:05:09 UTC 2007


On Feb 10, 2007, at 4:07 PM, Drummond Reed wrote:

>
>>> -----Original Message-----
>>> From: Robert Yates [mailto:robyates70 at gmail.com]
>>>
>>> 2) Why map the e-mail address to an openid url, which then has to be
>>> further resolved to a Yadis document?  Why not, instead, map straight
>>> to a yadis doc and make e-mails full fledged openids.  An openid is
>>> nothing more than a URI that can be resolved to a Yadis doc.
>>> mailto:robyates70 at gmail.com is a perfectly valid URI and you have
>>> demonstrated a pretty simple way to map it to a yadis doc.
>>
>> This is definitely worth considering.  As you know, the extension I 
>> have
>> proposed is highly controversial.  Past objections (i.e., arguments in
> favor
>> of *not* using an email in lieu of an OpenId) are numerous -- see my 
>> wiki
>> compilation for more details there [1].
>>
>> [1] http://openid.net/wiki/index.php?title=Debating_Emails_as_OpenIds
>>
>> David Fuelling wrote:
>>
>> To be fair, some of these objections are quite valid, which is why I
> decided
>> to propose a "mapping" from Email Address to URL, as opposed to making
> Email
>> Addresses a first class citizen of OpenId.
>>
>> Chief among these is that it would be nice if this extension could be 
>> used
>> in systems outside of OpenId.  Mainly, Yadis is required to map an 
>> email
>> address to a URL per my extension.
>>
>> In addition, URL-centric identity is something that I consider to be 
>> very
>> cool and very important -- it's a key piece of Identity 2.0, and not
>> something I want to abandon.  Thus, I decided to create a "mapping"
>> proposal, rather than simply something that says, "Openid should 
>> embrace
>> email addresses."
>>
>> THIS is because (If I understand things correctly) email-addresses 
>> can be
>> normalized to URI's (mailto:beth at example.com) in a standard fashion, 
>> but
>> that's not the same thing as a URL (URL's are URI's, but not 
>> vice-versa).
>>
>> Thus, without some kind of mapping to URL, it would probably be 
>> unwise to
>> utilize email addresses as OpenIds.
>>
>> All that said, you are correct that my mapping proposal does present 
>> a way
>> to get a URL from an email address, so maybe I am just adding an
>> (unnecessary) extra Yadis call into the mix.  However, I still think 
>> that
> an
>> extension which makes Email Addresses into OpenId Identifiers would 
>> *feel*
>> different from the extension I proposed, which simply maps an email 
>> to a
>> valid OpenId URL.
>>
>> It's a subtle difference, and one that I think has often been 
>> misunderstood
>> on the mailing lists.  One is a mapping, which says "you can use an 
>> email
>> address at an RP".  The other, which just doesn't feel right to me, 
>> says
>> that an email *IS* your Identity Identifier, which is tough to 
>> swallow.
>>
>> In reality, I'm not sure if this is just something I *feel*, or if 
>> there is
>> a legitimate technical difference between the two.  I think that they 
>> are
>> technically the same, but the latter notion implies something
>> philosophically about Identity 2.0 that perhaps should not be implied.
>>
>> I'd appreciate more feedback from the community on this point before I
> could
>> endorse making Emails first-class OpenId citizens (although my 
>> proposal
>> essentially does this via "mapping" sleight of hand).
>>
>> What do you think?
>
> David, I think your analysis is right on the mark. It is a very subtle
> difference, but in my view extremely important.
>
> Why? IMHO, the foundation of OpenID is "resolvable identity endpoints" 
> --
> endpoints on the Internet that represent what the Identity Gang lexicon
> calls "digital subjects" 
> (http://cis-berkman.editme.com/DigitalSubject).
> Note that while digital subjects includes users, they can also include 
> other
> resources like organizations, applications, etc.
>
> While it's true that all URIs can be used to identify digital 
> subjects, the
> OpenID framework works with that subset of URIs that are *resolvable* 
> (see a
> long blog post I did on that subject last year -
> http://www.equalsdrummond.name/?p=70). Resolvability is a vital
> characteristic of OpenID identifiers (URLs or XRIs) because that's how 
> you
> can get to the metadata needed to provide identity services 
> (authentication,
> authorization, attribute exchange, messaging, etc.) within the OpenID
> framework.
>
> Although an RFC 2822 email address can be cast as a URI using the 
> mailto:
> scheme, it's not a resolvable identifier by itself -- only the domain 
> name
> portion is resolvable. Your (excellent) ETT spec provides a mapping 
> from an
> RFC 2822 email address (or mailto: URI? -- I didn't see if that was 
> included
> in the spec, but it's a trivial addition) to a URL which is resolvable.
>
> Therefore I would frame it this way: an email address should be 
> considered
> an attribute of a resolvable OpenID identifier (i.e., a URL or XRI), 
> and
> your ETT spec should be considered a mechanism for mapping backwards 
> from
> the attribute to the resolvable OpenID identifier.
>
> I guess that makes email addresses "second class citizens" vs. URLs or 
> XRIs
> as "first class citizens" in the OpenID framework, but for good reason.

The other vital property of URL based schemes in addition to 
resolvability
is that "ownership" can be confirmed.  Email addresses are indeed
resolvable in the sense detailed here.  Furthermore, ownership can also 
be
confirmed at some level of assurance by the often used technique of 
sending
something to the alleged email address and seeing if it can be read.

However, I think a significant factor is whether this can be done 
quickly
enough and with few enough tasks for the user such that it's acceptable 
as
a login process.  Isn't that the real reason for the first/second class
citizen distinction?

Can it be automated?  Maybe you could leverage something off of those
"out of office" messages.  (This paragraph is meant to be humorous).

Eric Norman




More information about the general mailing list