Debating Emails as 1st Class or 2nd Class Citizens


This page is intended to document the following debate: Assuming RFC2822 Email Addresses are allowed as OpenId Identifiers, should these types of Identifier be 1st-Class or 2nd-Class OpenId citizens?

Question: Should Email Addresses be used as 1st-Class OpenId Identifiers?

Assuming RFC2822 Email Addresses are allowed as OpenId Identifiers, should they be treated as 1st-Class Identifiers?


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 the topic in question.

Please note that this page's debate should center around whether Email Addresses should be used as 1st-Class or 2nd-Class identifiers. Debate on the question of whether or not Email Addresses should be used at all can be found here (legacy wiki) or here (new wiki).


1st-Class OpenId Citizens Defined

1st-Class OpenId Identifiers are ones that may be entered into any Relying Party (RP) login box, or passed around as an end-user's "OpenId". RP's can advertise these types of Identifiers publicly, without compromising the user's privacy or the security of the OpenId protocol. Currently allowed 1st-Class OpenId Identifiers are URL's and XRI's, as defined in the OpenId Authentication 2.0 Final.

2nd-Class OpenId Citizens Defined

2nd-Class OpenId Identifiers are ones that "map" to a 1st-Class OpenId Identifier via some standardized mapping or lookup procedure. A 2nd-Class OpenId citizen may be entered into an RP at login time, but would then be translated into its mapped 1st-Class equivalent. For example, if an RFC2822 email addresses were allowed as a 2nd-Class OpenId Identifier, then an Email address could be entered into an RP login box. The RP would then be required to lookup the 1st-Class "mapped" equivalent of the entered 2nd-Class identifier, and use that 1st-Class equivalent as the user's actual "OpenId".

Arguments Against (i.e., Email Addresses should be used as 2nd-Class Identifiers)

A) Email Addresses leak Personal Information.

If an Email address is used as a 1st-Class OpenId Identifier, then personal information such as "the way to communicate via email with the indicated user" would be leaked whenever an RP (or the end-user herself) shares the Email Address OpenId with a third party.

Instead, if the Email Address is a 2nd-Class citizen, only the RPs that the end-user logs into using her 2nd-Class OpenId Email Identifer would have her Email address. This is desirable, since logging into an RP with a 2nd-Class Email Address OpenId shows intent that the end-user wants the RP to have her email address, but use her OpenId URL/XRI when interacting with the public or other 3rd parties. For example, if beth logs into a RP with her email address, then tags a photo, or makes a public comment on the RP site, she most likely does not want her email address to be made public. If Email Addresses are 2nd-Class OpenId Identifiers, Beth's wishes will be honoroed -- the net result would be that the RP advertises only valid 1st-Class OpenId Identifier, the same thing that occurs when an end-user logs into an RP with a URL OpenId, and then authorizes personal information such as her email address to be released to the RP via Attribute Exchange.

AR) [No Rebuttal Yet].

A) A Published Email Address is an Invitation for Spammers.

When you use an XRI as an OpenID, you normally publish your personal contact page. Unlike email, it requires senders to authenticate.

If your email is revealed, however, it won't take long until you start receiving spam by hundreds a day. That is, until SMTP is replaced with a better standard. So you'll stop using that address for email and will automatically lose the only benefit in using it as an OpenID.

AR) [No Rebuttal Yet].

Arguments In Favor (i.e., Email Addresses should be used as 1st-Class Identifiers)

A) Current 1st-Class OpenId Identifiers work the same as Email Addresses Would

For the purposes of OpenId, the main benefit of using URL's and XRI's is resolvability. These types of identifiers can be resolved into a valid XRDS/Yadis service document, allowing OpenId to work. Using either Email to URL Transformation (EAUT)SMTP Service Extension for Yadis Discovery, OpenID Email Address Transform Extension 1.0 (deprecated in favor of EAUT), or the soon to be released XRD discovery mechansim (link pending), it is now possible to resolve an email address into a URL thus allowing Email Addresses to be treated as 1st-Class citizens.


AR) Resolvability is not the only Key to OpenId Identifiers.

In addition to resolvability, privacy is another key benefit to using URL's and XRI's as the only type of 1st-Class citizen in OpenId. For example, the OpenIds '' and =beth do not leak very much personal or private information about the hypothetical user 'beth'. Private information such as email address, IM, JabberId, home address, and anything else beth wants to control are still under her control.

Using an Email address as a 2nd-Class citizen would still allow the end-user to maintain control over his/her personal information. For example, an end-user (beth) who enters an Email Address as a 2nd-Class OpenId Identifer into an RP, is showing intent that she wants the RP to have her Email Address, but not to use her email address as her publicly displayable OpenId. If the RP communicates with another RP, or the public, the only valid OpenId Identifier it would be allowed to use (and remain OpenId compliant) would be Beth's mapped 1st-Class equivalent (an OpenId URL or XRI).