Web users are schizophrenic, and not by choice: They possess multiple identities to access sometimes dozens of online resources, but juggling those user name/password combos is burdensome, time consuming ... and often a slippery slope to insecure practices. Who hasn't seen monitors adorned with Post-it Notes full of identity info?

The OpenID Foundation wants to change that. On the user side, its community-developed system aims to let users create a single identity for signing on to an unlimited number of Web sites, relieving them of the need to maintain a variety of IDs and passwords. The OpenID framework also lets users control which identity attributes, such as e-mail and date of birth, can be shared with a given site. OpenID may also appeal to Web site owners looking to build large user communities, so the foundation has designed its spec to be simple and inexpensive to deploy.

So what is an OpenID? It's a URL that a user enters into the logon field when accessing a Web site. The framework provides the cryptographic underpinnings to prove that a user owns the URL she's logging in with. The OpenID specification, now available in a 2.0 draft version, has attracted an impressive list of supporters, including AOL, Microsoft, and VeriSign.

Still, OpenID isn't quite ready to change the world. Only a tiny fraction of Web sites--mostly blogs--now accept OpenID credentials. Also, self-assigned IDs, which OpenID employs, are unsuitable for high-value e-commerce transactions. To that end, OpenID developers are working with other authentication frameworks, such as Microsoft's Windows CardSpace and the Liberty Alliance specifications, to create an identity infrastructure that allows users to move among identity systems and ratchet up authentication and assertion measures as necessary.

Still, IT should pay attention: Support for OpenID requires few resource commitments, and those that get in on the ground floor can benefit from organic growth.

KEEP IT SIMPLE

Two major principles of OpenID, which was created by Brad Fitzpatrick, developer of LiveJournal blogging software, are simplicity and decentralization. When a user logs on to a site that supports OpenID, that site checks with a third-party server to confirm that the user owns the URL. Anyone who owns a server connected to the Internet can create an identity and provide identity services for others. Such decentralization is intended to foster adoption because anyone can create or accept identities, no monolithic controlling entity involved.

Users who don't want to set up their own servers can obtain an OpenID from some Internet companies. AOL now issues OpenID credentials to all its subscribers, and VeriSign's Personal Identity Provider, a free service that supplies users with online identities, supports OpenID. In addition, Microsoft has promised to support OpenID in its future identity services, and the Liberty Alliance is working on interoperability issues.

Sounds great, right? Problem is, as of press time, the Web site OpenIDDirectory.com lists just 295 sites that support the spec. While several, such as Technorati and LiveJournal, are high profile, the majority are small fry.

Why so much attention on such a small framework? As mentioned, a major draw is its decentralized nature. Because no organizational body "owns" OpenID, major players can implement its specifications any way they like and add their own authentication mechanisms. OpenID also has low integration costs because the software is free, and there's a growing community of open source developers ready to add functionality.

In addition, Web 2.0 sites thrive on user participation--owners hoping to stimulate active communities know they need to make it as easy as possible for users to access and consume resources. A common identity system also relieves Web sites of the burden of managing user identities.

HOW IT WORKS

OpenID 2.0 has three basic elements: a user with a Web browser (User Agent); a Relying Party (the Web site the user wants to log on to); and an OpenID Provider, which asserts that the user owns a particular URL. The OpenID Provider may also possess a variety of identity elements, such as a user's name, date of birth, and e-mail address (see diagram, below). When a User Agent signs on to a Web site with an Identifier (a URL), the Relying Party contacts the Provider for an assertion that the user owns the Identifier. Messages are exchanged using HTTP Post and Get. OpenID uses Diffie-Hellman key exchange to negotiate a shared secret to sign communications.

When a Relying Party contacts the OpenID Provider, the OpenID Provider asks the user to authenticate, then confirms which identity information it should send to the Relying Party. If the user consents to provide the identity elements requested by the Relying Party, the OpenID Provider sends them. The Relying Party processes the elements, and the user is logged in.

If the user is already authenticated to the OpenID Provider, the OpenID Provider will skip its own authentication request to the user.

The biggest change from the OpenID 1.1 spec to version 2.0 is the ability to accept an Extensible Resource Identifier. XRI is an Oasis standard that's similar to a URL but better suited for Web services and XML environments.

EARLY DAYS

Identity issues have plagued computing since its inception, and as the Web expands into more facets of life and commerce, those problems will only grow. Projects such as OpenID recognize that users will have multiple identities and that Web sites will require a variety of credentials. Rather than force Web users and Web sites to conform to a single ID system, the OpenID Foundation wants to help better manage identities while giving users a measure of control over which ID elements they provide to Web sites.