Addressing OpenID Shortcomings: Recovery, Replacement, User-Friendliness, and Retention

Recovery – a way to gain back lost access
Replacement – use an existing account with a new identity
User-friendliness – technology normal people can use (i.e. non-geeks)
Retention – provide an experience that doesn’t require sending users elsewhere

OpenID is like a new kind of credit card trying to get buyers, but doesn’t have enough stores to accept it yet. Users will come when OpenID opens more (exclusive) doors and gives them extra benefits, but for now, the marketing campaign needs to focus on getting more sites to accept it. Most users today already have single-sign-on – they use the same username and password everywhere.

There are many great benefits for users to want to use OpenID, such as having the ability to change their password or personal information once and have it apply everywhere. There are also barrier to user acceptance such as getting used to using a URL or XRI instead of a username and password. But at the end, just like a credit card, it’s all about where it is accepted.

Implementing OpenID for Nouncer started with the desire to stay away from managing user’s passwords and everything that comes with it. People need a way to securely sign-in, change their password, and recover their account in case they forgot their password. Sites need to enforce a strong password policy (complexity, duration, etc.), protect it from hackers, and help their users against phishing attacks. This by itself is a strong motivation for sites to want to avoid building their own identity system and OpenID is the right solution.

Given that Nouncer is an API service, the first problem was how to use OpenID over API calls. This was solved by developing OAuth as a way to delegate user access. OAuth in this context, exchanges a verified OpenID claim with a token that can be used in API calls. While the user experience is still  a bit clunky, it works and can be made usable today.

With OpenID, a site no longer has to worry about passwords. In fact, it will never see any password at all. But this doesn’t solve implementation costs associated with passwords such as recovery and change, because they still exist, only now they apply to the OpenID identity instead. Now that we put the burden of password management on the OpenID provider, sites don’t need to deal with changing password and help recover lost ones. But what if the user gets locked out of their OpenID, their OpenID provider is blacklisted for being unsafe, OpenID provider goes out of business (temporarily or for good), or anything else that blocks the user’s ability to log into your service.

Of course, sites can offer their own way to recover just like they used to do with passwords (send an email with a special token, ask secret questions, etc.), but that was one of the reasons why OpenID was chosen in the first place. Sites can also support multiple OpenIDs per user, so if one stops working the user can still use another, but that adds complexity. The database has to be able to support that and the user interface for this is messy. The user logs-in with one OpenID, then to add another, has to sign-in again to the second provider, and go back to the site. But more importantly, the user now has to manage multiple OpenID identities for a single resource, which defeats the whole purpose.

Sites want users to sign-up using a single OpenID and know that all this is taken care of. That a user will always have a way to verify their identity without needing any site specific help. Building an OpenID recovery system can be more work than building a password recovery system, mostly because it is not well established, and requires educating both developers and users on how to use it.

This leads to the second shortcoming which is OpenID replacement. A user with an OpenID signs-up for a new site. Later on, the user decided to switch to a different OpenID provider offering a better experience and enhanced security. They now need to sign-into every service they even used the first OpenID with and replace it with the new one. Of course, most sites don’t even offer this option today, but if they end-up building their own OpenID recovery system it will also support replacing OpenIDs.

Most users either use an existing account (that happens to supports OpenID such as LiveJournal and AOL) or sign-up for a new OpenID from a provider focused on identity services (such as MyOpenID, ClaimID, Verisign Labs, etc.). Each one of these providers offers way to recover access and some can be trusted to provide a reliable quality service. The likelihood of AOL being unable to authenticate a user for a long time is very low so a user with an AOL OpenID is probably not going to have many recovery issues. However, AOL is not going to offer many of the identity services other providers are going to offer.

We can safely assume is that if an OpenID provider is up and running, it will provide a way for users to recover their lost access. So in a world where OpenID providers never go down, sites can accept OpenID knowing that their users will always have a way to gain lost access back using their OpenID. That leaves us with the other case of OpenID providers becoming unavailable (or blocked), or simply replaced with a new OpenID provider. In other words, the OpenID the user registered with is no longer a viable/desirable option.

OpenID, using identity delegation (the process in which one OpenID identifier points to another) has the power to solve this situation when the OpenID used is not viable or desirable. But it requires a different approach to how users go about obtaining their OpenID identities. Instead of using the OpenID provided to them by their identity provider, users will use an OpenID identifier that is fully under their control such as their own domain name or website. They will then point that domain name or website to the OpenID provider they want to use. If they ever need to change their OpenID, they simply point their domain or website to a new provider. Since all their sites will know them by their own domain name, not by their provider, this will work.

This brings us to the third shortcoming: user-friendliness. Using a URL to log into a site is awkward and annoying and while XRI has the promise of offering a way to use friendlier identifiers, such as ‘=eran’ they don’t solve the awkwardness problem. While OpenID is generally accepted by the geek community, XRI is still far from geek mainstream.

To expect users to manually edit their website to include the OpenID HTML tags needed for identity delegation is not very practical and definitely not user-friendly. What’s even worse is that in case of a family domain, users will need to go about creating sub domains or multiple web pages for each member of the family. So if I wanted to use my personal domain name ‘’ as my family’s OpenID, I would need to create a sub domain for each family member such as ‘’ and then put up a web page for each sub domain with the HTML tags. Use Yadis? Forgetaboutit.

Some might say that user-friendliness isn’t an OpenID-enabled site problem, but a user education problem. But just take a look at some sites offering you OpenID support such as Blogger and Pibb. To make users with OpenID-enabled accounts know they can actually use them, they explicitly list each one, such as LiveJournal, AOL, etc. This doesn’t scale and costs sites resources to add and maintain mappings between the services and their OpenID interfaces. It’s basically hard-coded discovery, and that, is a site problem.

If we can make OpenID identifiers and identity delegation trivial for users, it will directly resolve all three shortcomings. This can be done with little new standards using emails and DNS. Users should be able to use their email address as their OpenID, as most sites today use emails as usernames anyway. This will solve the first part of making the identifier simple. So instead of choosing ‘AOL’ as the identity provider and entering the screen name, or worse, typing ‘’, the user will type ‘’.

This is where we get (very) technical. Now we need to map between the email to the OpenID identifier and this is where DNS comes in. DNS already has a system for resolving email addresses into an actual server – email resolution using an MX record. Why not add a new record type for OpenID. Basically another way to perform OpenID discovery that is all about making it user-friendly.

All that is needed is a URL the site performing discovery can append the email to and treat it as an OpenID identifier. This can be done using a OpenID TXT record: ‘OpenID [username rule] [priority] [URL]’ where [username rule] is a wildcard expression used to match the username part of the email (everything up to the ‘@’), [priority] is the MX-like priority value, and [URL] is the URL used to generate the OpenID identifier. The URL uses ‘*’ to indicate where the username is inserted, and ‘**’ to indicate where the full, URL-encoded, email address is inserted (both optional). For example:   TXT   ‘OpenID * 10 http://*’   TXT   ‘OpenID joe 10**’

Which reads: for any email address ‘’ other than ‘joe’ use ‘’ as the OpenID identifier. For email address ‘’ use ‘’ as the OpenID identifier. Rules are processed first based on the username rule match (in order of match closeness) and then on priority which is used in the same manner as MX records priority.

The added complexity of this proposal for OpenID-enabled sites is to perform DNS queries, but every platform provides tools for that, and it is not more complex than XRI resolution which is already part of OpenID 2.0. It also doesn’t add an actual new DNS record type which allows this to be used with any existing DNS server.

We are half way through. We turned an email address into an OpenID identifier.

The second part is to make identity delegation trivial. For most users, this is a non-issue. They will simply use their existing email account with a well established email provider such as Hotmail or Gmail (assuming Microsoft and Google will support OpenID and the OpenID DNS extension). Even people with their own domain name are more likely to use a hosted email service which is going to take care of the MX records, and as such, will also take care of the OpenID TXT records.

There are many ways to implement identity delegation, but in the context of email identifiers and simplifying the user experience, the idea is to move the delegation mapping to the OpenID provider. When users sign-up for a new OpenID, they will be given the option, perhaps as a premium paid service, to make the OpenID provider map incoming identity checks for the user email address with their local OpenID identifier. So instead of the users telling the site about their local identity (using delegation), the OpenID provider will perform the mapping.

In the above example, ‘’ has his OpenID managed by ‘’. When signing up for an OpenID at ‘’, Joe asked it to accept identity requests for ‘’ or at least provide delegation discovery. When Joe tries to log into an OpenID-enabled site using ‘’, the site convert the email address to the URL ‘’ and use it like a regular OpenID identifier. ‘’ will reply with the needed discovery information to get Joe authenticated using the OpenID protocol. By using the ‘**’ symbol, the full email address is sent over to the OpenID provider which can perform mapping of identities other than its own local ones.

This can be viewed as hosted delegated identity where the OpenID provider also provides hosting of the OpenID delegation information for the user. It doesn’t require any new standards except for implementation and support by OpenID providers.

All this has one more benefit which solves the last shortcoming: retention. The biggest problem people associate with OpenID adoption is losing user ownership. This might explain why many sites are quick to offer OpenID identity services, but not so quick to accept OpenIDs from other providers. To me, the problem is not about user ownership but about sending your users elsewhere before they can use your site. If a new site asks users for their OpenID, and when they don’t have one sends them over to the OpenID website to go and figure out what it is and how they can get one, they are not likely to see all those users come back.

But with email identifiers and hosted identity delegation, a whole new kind of user experience can emerge. When the user comes to a new site, they are simply asked for their email address. The site perform email discovery and if an OpenID identity is found, uses that. If the email doesn’t translate into an OpenID, the site can create a new OpenID for the user (using a local identity) and create a mapping so that when the user comes back the next time, it can map the email with the local identity. With hosted identity delegation, it can even use another OpenID provider to do the actual identity hosting for the local identity. If at some point in the future the user’s email provider adds support for OpenID, the site will detect it by performing email discovery on the email at signup, and ask the user if they want to switch over to use their email OpenID instead of their local credentials (which are actually OpenID).

And there you have it.

There are many other possible solutions to these 4 shortcomings. When deciding on a standard approach, what we as a community must keep in mind is the user experience. Any solution should build on top of existing practices, such as using email for usernames, and reuse existing technologies and infrastructures such as DNS. More than anything, the objective of this post is to start a dialog about making the decision to support OpenID a no-brainer for sites. Just like a credit card – get it accepted everywhere, and people will use it. It worked for debit cards, and it will work for OpenID.

* * *

Update I: Thanks for feedback from Blain Cook and Phillip Hallam-Baker, I have added an alternative solution for using DNS SRV records instead of the generic TXT records.

DNS offers TXT records as a generic way to provide information not explicitly supported by the DNS standards. DNS also offers SRV records which describe services offered by the domain and are very much in line with the goals of this proposal. However, the SRV record structure is limited in that it cannot contain URLs, only domain names. To implement this proposal using SRV records, each domain will only map to a single URL used for OpenID discovery of email addresses for that domain. If more flexibility is needed, it will have to be provided by the server at the fixed URL. This might not be a bad idea as it moved the parsing work off the DNS service and off the OpenID-enabled site, and on to another server which can create any system needed to turn email addresses into OpenID identifiers.

Using the above example, the ‘’ domain will have the following SRV records: 86400 IN SRV 10 0 80

When a site performs email discovery they will look up the SRV record with service name ‘openid’ for that domain, apply the standard priority and weight rules (in this example priority 10 with weight 0), and use the domain name to construct the discovery URL. Since the domain part only allows domain names, the URL can only follow a single pattern and because a single server may host multiple email domains, the full email address is needed. Such URL can look like ‘’.

The decision to provide OpenID discovery for Joe using ‘’ will be performed by the server at the fixed URL and use HTTP redirects to send the site to that location.

* * *

Update II: None of this is really new ideas or original work. But it has been a while since it was proposed and now that OpenID 2.0 is final, there is more bandwidth to discuss the solve these issues. Some interesting reads on the subject are: What OpenID needs to success, Debating Emails as 1st-Class or 2nd-Class Citizens, and OpenID Email Address Transform Extension.

* * *

Update III: If you are interesting in the general discussion about email identifiers, you might want to read Dear Mailman, Please Read my TOS.

3 thoughts on “Addressing OpenID Shortcomings: Recovery, Replacement, User-Friendliness, and Retention

  1. i wholeheartedly agree that forcing users to remember a URL for their OpenID identity provider is inane and frustrating.
    The nice thing about the model is that it only contains 2 key pieces of information:
    – I’m user foo
    – the site is
    Having to remember is too much work. “en-whaaa?” “user:-whaaaa?”.
    Are we out to build system designed by geeks and built for geeks?
    Or are we looking to make this available to our Moms?
    Whether we make users type in one input box or we simply give them two boxes with a pinch of autocompletion …
    – [username] @ [site name]
    – chrisholland @
    … we could open ourselves to a far smoother process on both the user interface and the back-end discovery.
    SIP clients use a similar mechanism of DNS/SRV record queries to discover SIP proxies for a given domain.
    Right now i can tell users to contact me at, whether it’s by email, or thru their SIP client. It’s easy to remember.
    URLs must go away. Force me to only remember 2 things:
    – my username on a site.
    – the site’s name.

  2. And DSN servers NEED to be secured. It isn’t that hard to fake an DNS server ansver to clients.
    There is standards for this DNSSEC, but not to many uses it yet. Swedish (.se-domain) DNS authorities usese this now. But not everyone in this domain (have a look at

Comments are closed.