Amid growing concern that its authentication specifications are being confused with Microsoft's .Net Passport technology, The Liberty Alliance Project released a white paper Thursday to explain how the organization's federated identity model is different from .Net Passport and how it might one day be able to interoperate with Passport and other identity management systems.
The technical white paper, entitled "Identity Systems and Liberty Specification version 1.1 Interoperability," compares and contrasts the consortium's federated identity model against .Net Passport, Verified by Visa, and other third-party authentication systems.
The paper was produced to address questions and misconceptions about the Liberty Alliance model, said Paul Madsen, the paper's author and a consultant in the Advanced Security Technologies group at Entrust Inc.
"The paper was motivated less to define a framework for Liberty working together with other systems than to address confusion in the marketplace about what Liberty was and how it would work with other systems, and sometimes compete with those other systems," Madsen said.
In particular, the paper was written to address the misconception that Liberty was a service akin to Microsoft's .Net Passport. Unlike .Net Passport, Liberty is a set of specifications for protocols that can be implemented by different organizations which become Passport-like user authentication services.
While it may be fair to compare Passport to a particular implementation of the Liberty specifications, comparing the consortium's specifications to Microsoft's service is not particularly useful, Madsen said.
The white paper also points out fundamental technical differences between .Net Passport and the Liberty specifications.
For example, The Liberty Alliance specifications back the use of Security Assertion Markup Language (SAML) for exchanging authentication tokens as compared with Passport's proprietary schema, and the two authentication systems differ in the way they communicate tokens from one site to the next.
"There were a lot of misconceptions about how Liberty compares to Passport. We wanted to set out the differences and, recognizing those, set out some scenarios where Liberty and Passport can exist," Madsen said.
On that score, the new white paper proposes a number of scenarios in which .Net Passport and Liberty might work together.
In one scenario, a third-party Web site might act as an identity provider in a Liberty "circle of trust" (COT), creating SAML assertions for other service providers while also existing as a Passport member site, processing tokens issued by Passport.com.
In this scenario, Identity.com would then act as a "mediator" between the Liberty-governed domain and the Passport domain, converting Passport tickets into SAML assertions and vice versa.
In a second scenario, a service provider could exist in a Liberty COT and as a Passport member. Either authentication system could be used, depending on the nature of the service being requested, with Passport used for lower-security consumer transactions and Liberty for transactions that require stronger authentication.
Madsen acknowledged, however, that such scenarios put the onus on third parties to do the difficult work of integrating the two authentication systems.
"A lot of the scenarios don't have implications for the protocols. They depend on some Web site choosing to bridge between two communities," Madsen said.
In the future, the development of Web Services Security standards that are supported by both Liberty and Passport may make the differences between the systems less relevant by stipulating how information and security tokens can be requested and exchanged as part of Web services implementations.
In addition, third-party software vendors such as Entrust, which makes network security products, might come up with products that bridge the gap between Liberty, Passport and other authentication systems, Madsen said.
"It will behoove us to simplify for our customers how to exist and both worlds if they choose to," he said.