What OpenID needs to succeed

openid.gifI think I remember the conversation I had with Brad Fitzpatrick and Randy Reddig that inspired us to create OpenID (and by "us" I mean Brad). The conversation started with my trying to understand why more people simply don't trust TypeKey, a simple, pseudo-anonymous authentication and identity service. Furthermore, why is it that every other identity service never seems to succeed as well?

The problem lies in the fact that everyone who approaches the identity problem invariably has to solve the "trust problem" as well, because in all of their solutions, identity is stored in a centralized manner. And when you centralize identity information within a single authority you give that authority tremendous power. And we all know the adage, "absolute power, corrupts absolutely."

So naturally people are reticent to hand over their identity. And because the system only works if everyone buys into it and trusts that single authority, when one person opts out, then it is only a matter of time before the whole system falls apart.

Enter OpenID.

When I started this post I didn't intend for it to be an OpenID primer, for that I refer you to Sam Ruby's post. What I wanted to remark on was that despite all of OpenID's [this is good]-ness, it has one major challenge to overcome: the average person simply does not think of a URL, you know, the "h-t-t-p-colon-slash-slash" stuff, as an identity. And you can't make them.

What OpenID needs is a more intuitive identity handle, something we store in our address books and contact lists. Something like, let's see... an email address. Everyone's identity is implicit, if not explicit, in their email address, which is why an email address is perfect for this type of application. But an email address is not compatible with the OpenID protocol. So we need a way to map email addresses to URLs.

This very same problem has been solved before. In the early days of the Internet, one accessed computers directly by typing in their "IP Address." An IP address looks somethig like this:

Obviously, this is hard for humans to remember; it is much easier for us to remember things like "www.yahoo.com" and "www.sixapart.com." That is why Berkeley invented DNS, or Domain Name System. This service provided the ability for people to type in a more human friendly name for a computer and have that name resolved to an IP Address automatically and transparently. It also had the advantage of allowing the computer to physcially moved (and thus be given an new IP address) without requiring everyone wishing to access the computer to update their computer's virtual address book.

And this is exactly was OpenID needs: Open iDNS, or "Open Id Domain Name System." This service would work just like DNS, and would map email addresses to an OpenID provider designated by the owner.

Allowing an email address to be used within an OpenID ecosystem would allow for a much larger base of users to grok OpenID and thus, for OpenID to enter the mainstream. To illustrate look at these two examples of a login form:


And this one:

Please type your email address to login.

Now assume for a second you don't know what OpenID is, but that you also probably already have an OpenID URL without even knowing it (why? because OpenID is being adopted by and more companies and service providers, even as you are reading this), then which login form makes more sense to you?

Recommended Entries


And why doesn't your blog support OpenID Sign in yet :-)?

Another important aspect to get OpenID to succeed is allowing login with OpenID in any kind of place.

A fair point. I recently reverted to MT's default templates and lost the OpenID login capability. I will reinstate it.

I like your idea about using an email address. There is also this "XRI" i-name approach to make OpenID more accessible, but it just smells like foul money having to buy your i-name.

If there were to be a centralised OpenID Email mapping system/ server, wouldn't that somewhat counter the federated idea of OpenID?

One simple possibility would be to map user@host.com to http://host.com/~user -- but that'd then require the support of the Email provider the address is stored with.

The main problem is getting such notation support into the "official" protocol. I imagine it's just a few characters of Perl or PHP to implement this in the Movable Type signon script.

Advantages of mapping user@host.com to http://central.mail2openid.server/user@host.com:

  • can be used with any Email address, regardless whether the Email provider supports OpenID.
  • allows you to freely choose which OpenID provider to delegate your Email address to.


  • centralised, who's going to run it and pay for it?
  • trust question

Think about:

  • if the user has to manually set up her Email address -- OpenID relationship anyway, he can just familiarise himself with using user.myopenid.net instead.
  • would Email providers be willing to inscribe a record in the central server mapping their customers Email addresses to an OpenID server?

Advantages of mapping user@host.com to http://host.com/~user:

  • keeps the decentralized approach.
  • requires direct support from the Email providers.
  • your Email provider might not allow you to delegate your Email address to another OpenID server.

Think about:

  • if OpenID were to be adapted by an Email provider, it would make most sense if they could do it this way, thus also keeping control over the OpenID if they so desire.
Now assume for a second you don't know what OpenID is, but that you also probably already have an OpenID URL without even knowing it

If you already have an OpenID URL, then whom is it from? And what exactly is this URL?

If you have it because, for example, you made yourself a TypeKey account, then there is no existing relationship between your Email, and your account.

If we took the centralized approach, should TypeKey have been so wise and note down the relationship in the centralized lookup server?

Think about:

  • what if you sign up with multiple services providing OpenID, using the same Email address. Should they overwrite each other?
  • now we go beyond identification, who authorizes record changes in the centralized Email to OpenID lookup server?
  • if you need to set up the relationship manually, you may as well learn that your identity URL is user.host.com instead of user@emailprovider.com.

If we took the decentralized approach, only your Email provider could be responsible for setting up your OpenID.

About asking for an email address or "OpenID": If I give someone a url, the worst that can happen is that they don't visit my site. If I hand someone a working email address, I run the risk of receiving more spam.

Perhaps the forms should just ask people for their site. If I understand how this stuff is supposed to work, it's the same thing as their OpenID, but it uses a more familiar term.

I think you're right when you say that the average person thinks of an email address before thinking of a URL.

But a lot of people are also using IM nicknames or forum usernames to refer to someone on the internet.

And I think that the best place to centralize all these informations - email, IM nicknames, web site accounts - is a web page (I mean a blog :-). In this situation the URL is your identity.

Do you think the people won't change and will continue to think of a email first ?

Excellent idea. In usability tests, a URI representing identity was incredibly confusing. Some users asked why they couldn't use their email address...

I'm looking at the idea of coding (Well, getting coded, I don't even try backend stuff) a drop down menu as an alt login.

Really don't like it being in email form, seems to defeat the 'this bit of the web is me' ethos that OpenID promotes. But making the login UI easier for those that don't get it would be nice.

I don't think users can't learn about a new identifier. It may take some time, but it will happen. If email providers supported OpenID themselves, they could simply announce the fact to user@example.com that he can now use user.example.com as a login on every site where OpenID is supported. And if a user stumbles upon a site that uses OpenID but has never heard of OpenID before they can explain, some sites really do a good job and with things like the MyOpenID.com affiliate program it is easy for them. Is the simple replacement of "/" or "." with the familiar "@" really worth that effort?

lukas - I thought it would be easy until I ran some tests. Much to my dismay, even some power-users didn't get the concept of URI as identifier.

A better question might be: is avoiding some code and conventions to translate the '@' to a / or . worth the hassle of trying to educate users?

Yes, TypeKey is an OpenID, because OpenID stemmed from a conversation in which we wanted to fix TypeKey, and we felt the best way to build trust in TypeKey was to empower people to choose between using TypeKey or some other undetermined, but equivalent authentication service.

I think using an e-mail address is the wrong solution. Why? Because I don't think e-mail addresses are a good solution for anything, not even e-mail. Okay, that's not right. It's not RFC-822's fault, but RFC 821. The problem lies with SMTP and its lack of authentication and trust mechanisms, which has lead to the spam problems we have today. I believe the future of e-mail isn't e-mail at all, but feeds. Which is why an URI (or even better; IRI) is the perfect identification scheme for any user.

Soon, everybody will have a blog. Not because they love to blog about stuff, but because it allows them to send and receive messages to their friends without receiving any spam. And it's all powered by feeds (Atom) and it's all done over HTTP. Plus SSL if you want more security. Authentication is done with OpenID and authorization is done with something yet to come. This is the future and I don't think e-mail addresses will prevail when this hits the mainstream. Then, the blog's URL will be what we today use e-mail addresses for, and e-mail addresses will just silently die out.

Typekey is A poor OpenID though as I started having many problems using certain openID services livejournal it works perfectly fine on as well as openidenabled.com

+1 for email address as id

Our users are already using emails to login, so they would hardly even notice the change if we added OpenID support.

Alternatively, I'd have to put something weird in the login form like 'Your blog URL:'


As Lukas mentioned, myVidoop is another OIP that is working with sites to help users understand OpenID and select a provider. I am the affiliate coordinator over at Vidoop and just wanted to mention that we have an affiliate program as well. It is a simple sign up process and is basically the same as myopenid.com’s affiliate sign up. Another point to make is that offering users a few recommendations to a few “good” OIP’s is good practice and let’s them know you are helping them select a reputable OIP. The Vidoop sign up is at affiliates.vidoop.com

As pointed out by the article at The Identity Corner: http://idcorner.org/2007/08/22/the-problems-with-openid/ there are security, privacy, trust, usability and other problems with OpenID.

Your idea regarding "Open Id Domain Name System" is a good one, but, as Kim Cameron says: “How do I know I am looking at his web page or talking to his identity provider? By calling them up on DNS. […] OpenID is as strong, and as weak, as DNS. In other words, it is great for transactions that won’t attract criminal attack, and terrible for those that will.”

I completely am in awe of this site, definitely gonna have to remember to put this on my bookmarks.

Nice blog, just book marked it for later reference

Although the two German television broadcasters used two different satellites and two different digital TV systems, it was an embarassment of riches for German-hungry TV viewers in America.

To speak on this theme it is possible long.

Great site, where did you come up with the info in this blog post? I'm glad I found it though, ill be checking back soon to see what other articles you have.

If you haven't tried them yet, the SubmitterSoftware.com bots ROCK....

Leave a comment

what will you say?

Recent Comments

  • If you haven't tried them yet, the SubmitterSoftware.com bots ROCK.... ...

  • Great site, where did you come up with the info in this blog post? I'm glad I found it though, ill be checking back soon to see what other articles you have. ...

  • To speak on this theme it is possible long. ...

  • Although the two German television broadcasters used two different satellites and two different digital TV systems, it was an embarassment of riches for German-hungry TV viewers in America. ...

  • Nice blog, just book marked it for later reference ...