The other night at Beer and Blog in Portland, fellow Vidooper Michael T Richardson announced and launched a new service that I’m both excited and a little apprehensive about.
The service is called Emailtoid, and while I prefer to pronounce is “email-toyed”, others might pronounce it “email two eye-dee”. And depending on your pronunciation, you might realize that this service is about using an email address as an ID — specifically an OpenID.
This is not a new idea, and it’s one that been debated and discussed in the OpenID community an awful lot, which culminated in a rough outline of how it might work by Brad Fitzpatrick following the Social Graph FOO Camp this past spring, and that David Fuelling turned into an early draft spec.
Well, we looked at this work and this discussion and felt that sooner or later, in spite of all the benefits of using actual URLs for identity, that someone needed to take a lead and actually build out this concept so we have something real to banter about.
The pragmatic reality is that many people are comfortable using email addresses as their identity online for signing up to new services; furthermore, many, many more people have email addresses who don’t also have URLs or homepages that they call their own (or can readily identify). And forcing people to learn yet another form of identifier for the web to satisfy the design of a protocol for arguably marginal value with a lesser user experience also doesn’t make sense. Put another way: the limitations of the technology should not be forced on end users, especially when it doesn’t need to be. And that’s why Emailtoid is a necessary experiment towards advancing identity on the web.
How it works
Emailtoid is a very simple service, and in fact is designed for obsolescence. It’s meant as a fallback for now, enabling relying parties to accept email addresses as identifiers without requiring the generation of a new local password and without requiring the address owner to give up or reveal their existing email credentials (otherwise known as the “password anti-pattern“).
The flow works like this:
- Users enter either an OpenID or email address into a typical OpenID input field. For the purpose of this flow, we’ll presume an email address is used.
- The relying party splits email addresses at the ‘@’ symbol into the username and the domain, generating a directed identity request to the email domain. If an XRDS, YADIS or XRDS-Simple document is discovered at the domain, the typical OpenID flow is invoked.
- If no discovery document is found, the service falls back to Emailtoid (sending a request like http://emailtoid.net/mapper?email=jane@example.com), where users verify that they own the supplied email addresses by providing their one-time access token that Emailtoid mailed to them.
- At this point, users may optionally associate an existing OpenID with their email address, or use the OpenID auto-generated by Emailtoid. Emailtoid is not intended to serve as a full-featured OpenID provider, and we encourage using an OpenID from a third-party OpenID provider.
- In the case where users supply and verify their own OpenID, Emailtoid will create a 302 HTTP redirect removing Emailtoid from future interactions completely.
Should an email provider supply a discovery document after an Emailtoid mapping has been made, the new mapping will take precedence.
Opportunities and issues
The drive behind Emailtoid, again, is to reduce the friction of OpenID by reusing familiar identifiers (i.e. email addresses). Clearly the challenges of achieving OpenID adoption are not simply technological, and to a great degree rely on how the user experience needs to become more streamlined and deliver on the promise of greater security and convenience.
Therefore, if a service advertises that they support signing in with an email address, they must keep that promise.
Unfortunately, until all email providers do some kind of local resolution and OpenID authentication, we will need a centralized mapper such as Emailtoid to provide the fallback mapping. And therein lies the rub, defeating some of the distributed design of OpenID.
If anything, Emailtoid is intended to drive forward a conversation about the experience of OpenID, and about how we can make the protocol compatible with, or complementary to, existing and well-known means of identifying oneself on the web. Is it a final solution? Probably not — but it’s up, it’s running, it works and it forces us now to look critically at the question of emails as OpenIDs, now that we can actually experience the flow, and the feeling, of entering an email address into an OpenID box without ever having to enter, or create, another unnecessary password.
Factory Joe 
Do any OpenID providers allow for an “Embedded Sign Up” functionality to Relying Parties? That is, if I’m a site that wants to accept OpenID, I give my new users the opportunity to go through the normal site registration process, but in reality give them an OpenID at the end of the process.
I quickly blogged what the process would look like here:
Social Graph Theory
Have you checked out Clickpass.com?
Biggest issue I have with this is that currently:
user@example.com
get’s mapped to
http://user@example.com/
Which is a valid URL and may in fact be their OpenID. This re-mapping idea changes this a lot.
@Stephen: AFAIK, the OpenID spec forbids using http://user@example.com as a valid OpenID, so this doesn’t change anything.
If this idea catches on, existing openid providers will compete for relying parties to choose them (i.e. the openid providers) as fallback service… probably by including it in an affiliate program (such as the one that myopenid already has in place).
@Pascal: Well, that’s a huge problem actually — that’s like having competing DNS providers! Again, ideally the email providers will adopt the discovery solution — or will themselves delegate/redirect to a third-party OpenID provider. Having multiple email-to-OpenID mappers would actually be pretty bad and one of the reasons why Emailtoid is potentially problematic as a privately-run project…
However, it pushes the idea out there and forces us to confront any potential technical issues with using email addresses as OpenIDs. AFAIC in that case, it’s a useful exercise and service until email providers get hip to providing identity on their own.
Sounds like an interesting service.
It does sound like an interesting idea, provided that, instead of redirecting the user to emailtoid, you send an email out to the user yourself and provide him with an OpenID based on a code in that email.