Open ID is an attempt at the concept of an ID Vault for browser based access to web sites. As a vault, it gets fairly close. Unfortunately, it's storing credentials that are themselves inadequate. If the open ID method of sharing credentials could be applied to the storage of real credentials, it would be much more powerful.

I've looked into Open ID a bit more since I started talking about it in a previous blog entry. I've come to a few initial conclusions about it that are fairly disappointing.

It isn't what you want it to be

Open ID isn't security in any real sense of the word. Security is the applied combination of "Authentication" and "Access Control". While Open ID attempts to be about the "Authentication" part of the equation it doesn't really do that effectively. It isn't single sign-on either, although in some respects it is very similar.

Authentication is simply the method you use to be sure you know with whom you are interacting. To do that on most web sites, you have to pick a Login ID and a Password - your credentials. That's fine for making sure that the same person comes back to use the same ID next time. By itself, it doesn't tell you anything about the person who picked it. For that, each web site seeks to tie those credentials to you as an individual. The site management has to decide how important it is that they know who they're dealing with. For many, simply sending an authorization email with a confirmation link is good enough. For other sites, a minimal charge to a credit card is required. A few are more complex. Authentication isn't valid until you tie some credentials to some level of individual identification that is strong enough for your site.

Open ID doesn't do that. Like Single Sign-on, Open ID is a trade off. By providing the users of a site the convenience of having the same credentials work at many sites, it reduces the strength of the link between those credentials and any real person to that of the weakest validation method of any participating web site. Your AIM login name can be a valid Open ID. Does knowing your AIM ID provide me enough information to consider you a validated user?

There are already solutions to this problem

While so far they haven't been well supported in browsers, client side certificates were designed to deal with this issue. A certificate authority schema and authority tree exists already and works quite well. We use it for authenticating web sites from our browser every time we connect to a web server using SSL. Our browser accepts the certificate offered by the site, and if it has an authority chain that we recognize we consider the site a known entity. When I connect to my bank's web site, my browser automatically verifies that a certificate authority I trust has certified this particular web site as being who they say they are. It isn't perfect, but it works pretty well -- especially if you pay some attention to it.

To make this work at the browser side, a couple of things have to happen. First, certificates need to be easier to get. The Thawte Web of Trust (WOT) has been a good attempt at this, but realistically these are going to have to become more mainstream. Sites which do go to great lengths to authenticate real people -- like banks -- should be able to issue these certificates. To use a certificate, you have to enter a password. Maybe this is by logging into your PC, or maybe you have an additional password each time you present that certificate. Does this sound familiar? Yes, it is just like the Notes ID file. That's because it is exactly what the Notes ID file does in its own proprietary way.

In addition to making certificates more widely and accurately available, browser software (frankly, all network software) next has to make them easier to manage. Windows, Linux, and Mac OS X all have their own concept of a keyring to hold these kinds of certificates. None of them are easily portable. Would you know how (without looking into it) to take your certificates with you on a USB key and easily use them on another machine without changing the configuration of that machine? Of course not.

A truly transportable key management process, easy enough for any end user to understand how to carry their keys around is the missing piece. Browser revision cycles are shorter than that of Operating Systems, so its going to happen on browsers first -- but eventually it will have to be cleanly supported at the operating system level.

Users don't want to carry a keyring

The fly in the ointment on a portable key ring is having to carry the key ring around. Nobody knows this better than a Domino administrator. That's where the concept of an ID Vault comes into play. On the Notes and Domino side of things, that work is being done for the next major release of the product.

An ID Vault schema for internet standard credentials would be an excellent idea and likely well accepted. The question becomes, who runs the vault? That's the hidden strength of Open ID. The really good work they've done is in creating a fairly workable method for distributed, trusted id vaults.

Here's how a decent Authentication methodology could work

A. Make verified certificates easier to get. Certificates are out there now, but fairly well hidden and hard to get. Let banks, supermarkets, and anyone else issue them. Their level of trust can easily be validated based on their root and intermediate certificates. I could then have a certificate that is issued by Key Bank and says I'm Andrew Pollack, and that certificate authority (Key Bank) bears a stamp from Verisign that attests to Key's rigorous authentication standards.

B. Make the key rings where these certificates are stored much more easily transportable. Key rings are there now, but fairly well hidden and hard to use. They're also not very easily moved from machine to machine. That means the interface to pick your key ring needs to be front and center on browsers -- and eventually operating systems.

C. Implement a schema where you can store your key ring - encrypted - on any web service which provides an authentication service based on a common ID Vault schema.

The ID Vault schema needs to work like this:

1. At any participating web site, when asked for credentials, you enter the URL to access your ID via the ID Vault of your choice. (e.g. myvault.com/AndrewjayPollack )

2. The web site makes a request to your vault for your credentials using a specific key of its own, while opening an iframe, popup window, or browser add-in which makes a secure SSL connection to that ID Vault passing the same key.

3. The ID Vault site now has two distinct connections to it. One from you and one from the server you're wanting to log into. Both share the same identifier. The ID Vault server presents you (In your secure popup) with whatever authentication method makes sense -- If you're on your home PC, a client side certificate can make it transparent, if not a password or secure id card or whatever is secure enough for you.

4. Once the ID Vault has authenticated you, it asks for permission to pass your credentials to the web site (which it names) that you're trying to log into.

5. Given permission, the ID Vault passes your credentials back to the other server and you're verified.

6. Once your credentials have identified you to the new site, it can issue its own cookie if it wants to skip this step in the future.


In the end, Open ID makes a reasonable attempt at an ID Vault schema but then falls down by providing credentials which are themselves not good enough for any but the most open of systems.

You can find out more about Open ID and make your own decisions here:
http://openid.net
http://janrain.com/openid/