Identity Commons helping get better grip on digital identity

When I was in college in the early 1980s studying mathematics and computer science, I had the opportunity to correspond with Len Adleman of RSA (Rivest-Shamir-Adleman) cryptosystem fame, who sent me a thick envelope by parcel post with some of his results in extending the Diffie-Hellman encryption algorithm (this was in the days before email and URLs dramatically simplified such correspondence).

Along with Ron Rivest and Adi Shamir, Adleman had just founded Redwood City, Calif.-based RSA Data Security, Inc. to license the RSA algorithm and sell security toolkits that would enable software developers to build encryption into their applications. I clearly remember the sense of excitement I felt opening the manila envelope with the 200-odd page mathematical proof, excitement that was soon followed by puzzlement and perplexity at the complexity of the proof.

With the help of a cooperative math professor, I was able to grasp in broad outline the nature of Adleman’s proof — although I have to admit I had no real appreciation of the implications or usefulness of an algorithm based on such a proof.

Flash forward 20 years: The RSA algorithm has become the de facto standard for industrial-strength encryption, especially for secure communications over the Internet. With the expiration of the 17-year RSA patent in September 2000, public-key encryption technology is ubiquitous in cyberspace: in Web browsers, email programs, mobile phones, virtual private networks, and myriad of other e-commerce areas including Web services.

Too many digital IDs

As more and more information has gotten pushed to the Web — much of it sensitive and confidential — it’s becoming increasingly important for enterprises to get a handle on who has access to it. The establishment of electronic identities, with some form of encrypted authentication method, such as a password, attached to them is usually the first step in an enterprise strategy known as identity management (ID management).

Identity management governs the definition, storage, use and management of a person’s digital identity within an organization. The proliferation of digital identities in various online contexts creates significant challenges for ID management systems. Above and beyond the basic problem of users having trouble remembering multiple usernames and passwords, IT organizations are finding it increasingly difficult to manage the profusion of identity databases, both inside and outside corporate firewalls. Thus employees will often have one identity inside their company’s intranet, one with external service providers such as a 401k provider or HMO, and another one with supply chain and channel partners. Managing all of these employee identities is an inconvenience as well as a security risk.

In response to the demand by companies for single sign-on (SSO) usernames to and from their partner organizations, enterprise identity management companies such as RSA, Netegrity, and VeriSign a few years ago began promoting federated identity standards — primarily through the Organization for the Advancement of Structured Information Standards (OASIS), a not-for-profit consortium that seeks to drive the adoption of e-business standards.

Federated identity simply means that an enterprise will agree to use standardized methods to share the identity and security information in its local domain while retaining its own internal directory, account provisioning, and public-key infrastructure services. Federated identity is roughly analogous to a driver’s license, where one state provides individuals with a credential that is trusted and accepted as proof of identity by other states. In the online world, this trust is established through a combination of authentication and access management technologies, as well as through business and legal agreements that institutions and individuals enter into to establish mutual responsibility and commitment concerning the sharing of trusted identities.

There are currently two major federated identity management initiatives, WS-Federation and Liberty Alliance, which are promising to deliver ostensibly end-to-end federated identity standards sometime next year. Although much less visible than WS-Federation or Liberty Alliance, a group of companies and individuals known as the Identity Commons federation is also rapidly capturing the attention of non-profit communities and open source developers.

Unlike WS-Fed and Liberty, which take a more institutional approach to federated identity, ID Commons is adding mechanisms that will make it easier for third-party and open source developers to create tools that will give individuals much greater control over how their data is shared. To better understand the notion of identity behind ID Commons, we need to take a closer look at the evolution of federated identity standards.

Following the roadmap

In April 2002, Microsoft and IBM published a joint white paper outlining a roadmap for developing a set of Web service security specifications. Their first jointly developed specification, WS-Security, offered a mechanism for attaching security tokens to messages, including tokens related to identity. Besides WS-Security, other specifications called for in what has become known as the WS-* (or WS-Federation) roadmap include:

• WS-Policy: describes the capabilities and constraints of the security (and other business) policies on intermediaries and endpoints (for example, required security tokens, supported encryption algorithms, privacy rules).
• WS-Trust: describes a framework for trust models that enables Web services to securely interoperate.
• WS-Privacy: describes a model for how Web services and requesters state subject privacy preferences and organizational privacy practice statements.
• WS-SecureConversation: describes how to manage and authenticate message exchanges between parties including security context exchange and establishing and deriving session keys.
• WS-Authorization: describes how to manage authorization data and authorization policies.
• WS-Federation: describes how to manage and broker the trust relationships in a heterogeneous federated environment including support for federated identities.

Converging standards

At nearly the same time, Liberty Alliance, a consortium of more than 170 technology vendors and end-user companies, was formed to build upon the OASIS work in defining a new XML standard, Secure Assertion Markup Language (SAML — pronounced “Sam-el”), to exchange authentication information between service providers. The forthcoming Liberty 2.0 specifications will allow organizations to participate in networked “circles of trust” and “account federation.”

A circle of trust is an affiliated group of two or more organizations that share credentials. Once a circle of trust has been established among commercial or non-commercial organizations, it then becomes possible to federate or connect a user’s multiple Internet accounts within the circle of trust. In the Liberty model, a consumer or business only has to enter his or her ID/password once and is able to move to different trusted sites without re-keying identity information. For example, you could book an entire trip, flight, hotel, and rental car on sites of your choosing without having to log on to more than one site.

With the recent release by the Liberty Alliance of a “Best Practices” document outlining business requirements and guidelines necessary for the wide-scale deployment of federated network identity, there is some indication that the Liberty Alliance work is beginning to line up with work done by IBM and Microsoft. Supporting this argument is the fact that the Liberty Alliance has incorporated WS-Security into its second-generation Identity Web Services Framework (ID-WSF) specification.

At present, identity management vendors are hedging their bets and pledging to support all of the different federated identity frameworks. Thus, IBM is delivering Liberty-compliant software, even as it continues to advance the WS-* roadmap. Netegrity is offering SAML- and Liberty-compliant products, but is investigating WS-Federation. And RSA Security, a Liberty Alliance sponsor, is also working with IBM and Microsoft on WS-Federation.

Privacy concerns

As I noted above, both Liberty Alliance and WS-Federation are primarily designed to facilitate e-commerce and satisfy the needs of large enterprises, thus they have raised concerns among open source developers and others about individuals’ privacy.

Several wide-ranging issues of privacy and digital identity were addressed by presenters at the PlaNetwork 2004 conference in San Francisco last June. In a presentation called “The Social Web,” Drummond Reed, CTO of Seattle-based Cordance Corp. and a trustee of the Identity Commons (IC) group, made a persuasive argument for a public, open source infrastructure for identity and trust based on evolving OASIS XRI (Extensible Resource Identifier) and XDI (XRI Data Interchange) specifications.

A generalized form of the ubiquitous URI (aka URL or Web Address) standard, an XRI is a smart identifier that would provide not only information about the location of data and the protocol to access it, but also what are called “link contracts.” These spell out permissions, authorization for access, information about who owns the data, and how to synchronize it.

Reed acknowledged that the XRI/XDI social networking infrastructure is in many ways similar to the Internet2 group’s Shibboleth ID management specification, a middleware initiative that was designed mainly for academic institutions.

“The key piece of the framework that XRI provides,” Reed explained, “is abstract identification — identifiers that can be owned and controlled by the identities they represent and that are interoperable across domains.”

Known as XRI i-numbers and i-names, these identifiers add a new layer of universal private addressing to the existing IP numbering and DNS naming layers used on the Internet today.

“Although both approaches are standards-based (built off of OASIS’s SAML [oasis-open.org] spec) and focused on user-managed privacy, we believe our approach will extend what is possible with Shibboleth today and solve more problems for more audiences,” Reed said. “For example, i-names and i-name single sign-on will extend Shibboleth-style single sign-on capabilities out into the consumer population, where soon there will be an entirely new class of service providers (trusted identity brokers, such as Identity Commons) offering i-name accounts and services such as i-name single sign-on, personal contact gateways and personal data sharing.”

How to get involved

Identity Commons is currently preparing an EGS (Early Global Services) project for launch this month that will enable registration of the first global i-names. Reed recommends that IT managers who want to collaborate with Identity Commons join the mailing list IC will be posting when EGS launches about how to add support for i-name single sign-on to their Web site(s).

“Open source developers are welcome with open arms!” exclaims Reed, advocating that those who want more hands-on involvement join the IC-Dev mailing list and look for opportunities to contribute in the ID Commons projects on XRI and XDI at SourceForge.

Reed concluded his recent PlaNetwork presentation with the observation that applications built with the new trusted data interchange specifications will “change our experience of the Internet from one of a vast untamed frontier to one of a rich and vibrant social neighborhood.” Only time will tell if the user-controlled federated identity path that Reed and the lively and audacious ID-Commons community are promoting will be successful.

A couple of facts seem to be obvious, however: Given all the back and forth in the identity management space, it’s much too early to count out the grassroots open-source ID-Commons identity project. Moreover, the widespread adoption of a safe and secure method of implementing end-to-end privacy and confidentiality in Internet applications will likely have ramifications at least as profound as the adoption of public-key encryption technology 20 years ago, implications we may not be able to fully appreciate at the present time.

Roger Smith is a free-lance IT writer based in San Francisco. He is former technical editor of Software Development magazine.