The Missing Link in OpenID
OpenID is an idea that is so obviously powerful that it has captured the attention of many that see its utility and elegance as a solution. But in the evolutionary currents that sweep many ideas into the could-have-beens bins, OpenID is missing a key feature that will keep it from being a solution for identity: email. There are other missing pieces that could give OpenID a competitive advantage over most other identity systems, but without email being made integral to it OpenID may have an insurmountable flaw. Knowing the advantages of OpenID along with the current state of identity for consumers will help to better understand the greatness of the danger of the missing link.
At the core of OpenID is the idea of a URL can serve as a unique identifier and that showing control of the URL can be correlated with identity.
The core of the Web is URL and an HTML document. The use of the URL to "get" any document on the web is a powerful idea that so far only the OpenID system seems to have taken full advantage of. Any system can assume that collisions of non-unique identifiers is inherent in the system. However, using identities that are based URLs within one domain is problematic. First, it may end up that the domain is stripped off the string to provide efficiency which will get back to potential collisions. Second, if there are competing and simultaneous cooperative identity systems, the inefficiencies of maintaining the system will push toward chaos or centralization.
This conflict mirrors the initial competition and collision of networks in which the Internet was the neutral and standard. Into this, the URI for email addresses became a quick standard for communication which is still the most powerful identifier for most people on the Internet. OpenID is a web standard that can fill the gap for the World Wide Web.
Key to the power of OpenID is the decentralized distribution of identifiers. Also, like email identifiers, there is uniqueness and elegant method of distribution of control over the distribution of identifiers. An individual can even create and control their own personal OpenID independent of any particular entity. And, it is possible for a person to change their identifier in most cases. Being able to de-link from a specific organization is a powerful method of self-identity. For most people using their ISP or a company's web site account, the lack of control of their identity occurs infrequently leading to major problems (some people have felt stuck using AOL identifiers for communication and identity for over fifteen years due to the discomfort and problems arising from implications of changing identifiers/addresses). OpenID offers individuals the possibility to de-link their identifier from another entity forever.
Also, by de-linking identifiers of individuals from entities, the opportunity to centralize identity around the individual being identified has great advantages for decentralized network. If we look at the comparative history of email with instant messaging, we can see the importance of standardizing communication around an individual. All SMTP email systems can communicate and avoid identity/addressing collisions. In a sense, the identifier had to be centered on individual and their control. Instant messaging allowed for many different identifiers, including for some systems, any email address. Then when the instant messaging systems started to inter-operate, the identifiers were centralized around the specific individual network. Into this chaos, SMS addresses based on the more centralized telephone system flourished as did Twitter. However, if either of those closed networks is eclipsed, chaos of competing network and their identifiers will come back.
As the method of controlling the OpenID URL is independent of indicating to another party that the identity correlation can be made. This separation means that there can be heterogeneous authentication methods for controlling the OpenID URL: what you know (PINs/passwords and personal knowledge), what you have (tokens/cards...) and/or what you are (biometrics). Many systems use email addresses as the core of their ongoing authentication due to the binding of control of a URI and the ability to communicate that control. How the individual authenticates to their email system to receive a confirming email is unknown to that particular system. That de-linking is not been broken in the many systems that use email confirmation to check identity, even though many new identity systems seek to bind the method of authentication with the identifier.
In the previous example of using email transactions to show control of a URI, it was not insignificant that the communication can be made "out-of-band" of the transaction. In other words, the email address is bound a user account, because the system can always confirm control with an external system that communicates in real-time with the individual. Also, there may be reasons to alert a user of a system of something, which the email is crucial.
Using OpenID already cedes the need to control authentication methods, like password management which has its benefits as well as limitations. There can be paired authentication method to OpenID to overcome that limitation. However, email as a back-up for that other system might be considered necessary. OpenID is hamstrung by having no standard for communication with the individual. And since email is now practically the only universal standard for communication online, it is often a core for any authentication system for individual for either notice or showing control. Unfortunately, currently there is no standard for using an OpenID for communication to the individual whose OpenID is being used.
Conveniently, both the URIs for emails and OpenIDs are built on the base of the domain system (not all are). It would be easy to have a convention for making an OpenID URI into a mailto URI and vice versa. In addition, there could be a standard for embedding a specific email address URI into an OpenID profile page. Email systems could even standardize sending automatic responses which include an associated OpenID URI (don't hold your breath on this). By binding the two URIs, there can be both backwards compatibility with the previous method of showing control as well as the simplifying of methods of notice. Systems could then use the linked URIs to allow for an simpler method for authentication, notification, and control while giving the consumer more ease of use and finally separating identity from user accounts.
For example: the OpenID http://domain.com/username could become mailto:firstname.lastname@example.org and the OpenID http://username.domain.com/ or http://domain.com/ would become email@example.com or firstname.lastname@example.org . In the other direction it is tricker, because the convention of using a separate subdomain for mail has lost out to the convenience of leaving off the subdomain of the mail server. Probably the addition of "openid" as a subdomain would be the easiest to remember as in http://openid.domain.com/mail-username
Adding a bound email is a simple short term solution to solving the missing link crippling OpenID. What can really help individuals better own and control their own identity is to standardize a communications API.