• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.


Debating Emails as OpenIDs

Page history last edited by Terrell Russell 11 years, 7 months ago


This page is intended to document the debate over whether RFC2822 Email Addresses should be allowed in places where OpenId's are allowed. This page is structured into numbered "Arguements Against" (AA), along with numbered Rebuttals for each AA. After that, there is a section entitled "Arguement In Favor" (AIF), along with rebuttals for each AIF. This page is meant to be "non-partisan", in the sense that it seeks to simply list (valid or otherwise) points in favor or against using Emails as Open Ids.

In addition, this page seeks to recognize that there is a difference between advocating that an Email Address become a "first-class OpenId citizen" versus simply mapping an Email Address to a URL (OpenId URL or otherwise).

Question: Should an Email Address be allowed as an OpenId?

Should the OpenId Authentication 2.0 specification allow email addresses as OpenIds? 

Arguments Against (with Rebuttals)

A) People don't typically control their email address domain.

Most people utilize an email address that sits in a domain outside of their control. For example, hundreds of millions of people have yahoo.com, msn.com, gmail.com, aol.com, or comcast.net email addresses, but have no control over these domains. Thus, using an email address in one of these domains would not allow the end-user to control his/her openid services.

AR) This is a valid argument, although insufficient to disqualify the use of Email Addresses as OpenIds.

First, this is (unintentionlly?) applicable to most URL's as well, yet URL's are allowed as OpenIds. Most people don't control their OpenId URL, yet they are still allowed in the protocol. Second, as OpenId gains widespread adoption, it is intended that large email ISPs will provide support for OpenId, thus mitigating the lack of end-user control over thier email-based OpenId identity services. In a perfect world, every ISP who offers Email services would couple their email offerings to OpenId OP services.

A) Email Addresses aren't URL's, and therefore are not dereferencable/locatable like a URL. URL dereference-abilty is a cornerstone of URL-centric identity.

An Email Address by itself is neither a URI nor a URL. There is a standard way to normalize an email address into a URI via the mailto: scheme (e.g., mailto:beth@example.com), however there is no standard way to map an Email Address to a URL, which is a requirement of URL-centric identity, one of the cornerstones of OpenId.

AR) This argument is inaccurate.

An email address does not have to be either a URI or a URL. It can serve as a key in Yadis discovery, as proposed in SMTP Service Extension for Yadis Discovery, or it can be mapped to a URL, as proposed in Email Address to URL Transformation (EAUT).

A) Email addresses aren't "sticky".

One might have a given email address in 2006, but might use a different email address in 2007. The transient nature of email addresses makes them unsuitable for use in OpenId.

AR) This is insufficient to disqualify the use of Email Addresses as OpenIds.

This argument is applicable to URL's, which are already allowed as OpenId Identifiers. However, it is acknowledged that end-users may be able to find a URL that is more "sticky" than thier email address. However, using a mechanism that "maps" an email to an OpenId URL (such as the extensions proposed above), if a user changes his email address, he can point the new email address to his/her OpenId URL, which arguably should be less transient than an email address.

A) Allowing Email Addresses as OpenId's would confuse the end user while logging into an RP.

When a user logs into an RP, OpenId already allows OP Identifiers, OpenId URL's, and XRI's as valid inputs. Allowing a fourth type of identifier (namely, an Email address) would confuse the user.

AR) This is a valid point, although...

A4 is a valid objection, although it begs the question of why XRI's are considered to be valid OpenId Identifier, whereas emails are not (Perhaps this is because, in the past, there was no defined/proposed way to map an email address to a URL). Given that XRI's are already allowed in the current draft of OpenId Authentication 2.0, this confusion issue may be a good reason to allow email addresses as OpenId's via an extension, rather than in the main protocol.

A) Entering an email address into an RP poses a privacy risk.

A user who enters his/her email address into an RP login box will automatically provide his/her email address to the RP. In certain cases, the end-user may not wish to do this. Using an XRI or URL will mitigate this problem.

AR) This is a valid point, but privacy should be determined by the end-user

A5 is a VERY valid concern, although this decision should be left to the end-user, who should be deciding questions of privacy vs. convenience for him/herself. For example, the SPAM issue has caused many end-users to deal with this already. Many end-users have secondary e-mail addresses that are used in places where the end-user may not wish to reveal their "real" address.

A) Allowing Email Addresses as OpenId will provide a bad User Experience.

Most email address domains today don't support OpenId. Thus, if "typical" users try to use an email at an RP, the OpenId transaction will fail. This translates into a bad UX, and may hurt adoption.

AR) This is a concern, but is not unique to email addresses.

A6 is a VERY important concern, as adoption is important at this stage of OpenId's development. However, this UX is a problem anyway, since the typical user is not familiar with OpenId anyway. There is a good chance that the typical user (not having an OpenId at this point) will fail on their first attempt to login to an RP using OpenId.

In addition, Microsoft's recent announcement to embrace and support OpenId will arguably go a long way towards helping OpenId evangelism. Thus, now is the time to add email address support into OpenId, if ever.

A) Entering an email address into an RP increases the phishing risk of OpenId.

A user who enters his/her email address into an RP login box could be more susceptible to phishing attacks than a user who enters a URL or XRI. An Evil RP might detect that an email address was entered in lieu of an OpenId, and could simply respond by saying "Please enter your password."

AR) This is a concern, but is not unique to email addresses.

A7 is a VERY important concern, although existing OpenId machinations are already susceptible to this type of "trick the end-user" chicanery. Instead of prohibiting email addresses in OpenId, anti-phishing counter-measures and methodologies should be developed and implemented. 

A) A valid email addresses will not always be a valid OpenId.

A user who enters his/her email address into an RP login box may not understand that OpenId authentication is going on. So if his/her email address is not a valid OpenId, he/she may be confused. This means he/she is still required to understand what an OP is, and find an OP to use the RP login box. Users' comfort with using an email address would not allow them to ignore the technical details of OpenId any more than comfort with a browser does.



Arguments In Favor (with Rebuttals)

A) Email addresses are something that users already carry around with them stored in their brain.

Email addresses are pervasive. Everyone has one, and everyone knows what their email address is. Thus, allowing emails to be used in place of an OpenId URL would significantly help spur adoption across the internet.

AR) Once OpenId URLs become widespread, they will be easily remembered, too.

Once users utilize their OpenId URL enough, they will remember that just as easily as other key internet information like their email address. Thus, over the long term, this "problem of memory" will go away. However, in the short term, the argument above does have some merit.

A) Several users already manage their identities via their email addresses

There are users who have multiple identities and use their email address as the main identity descriptor.

Comments (0)

You don't have permission to comment on this page.