The Liberty Alliance Project has released its version 1.0 open federated network identity specifications, and several vendors at the Burton Group Catalyst Conference in San Francisco have announced plans today to deliver Liberty-enabled products and services. The Liberty Alliance Project is a an alliance (60+ members) formed to deliver and support a federated network identity solution for the Internet that enables single sign-on for consumers as well as business users in an open, federated way. The version 1.0 specifications focus on interoperability between systems to enable opt-in account linking and simplified sign-on functionality. This allows users to decide whether to link accounts with various identity providers and makes it easier for both consumers and businesses to take advantage of the growing Web services space." Specific functionality outlined in version 1.0 includes: (1) Opt-in account linking; (2) Simplified sign-on for linked accounts; (3) Authentication context; (4) Global log-out; (5) Liberty Alliance client feature. The six-part specification includes: Architecture Overview, Architecture Implementation Guidelines, Authentication Context Specification, Bindings and Profiles Specification, Protocols and Schemas Specification, and a Technical Glossary. "The Liberty Alliance specifications leverage industry-standard security and data transfer protocols, including the Security Assertion Markup Language (SAML), developed OASIS; SAML is quickly becoming the de-facto means for exchanging user credentials between trusted environments."

Liberty Alliance V1.0 Overview:

This specification defines a set of protocols that collectively provide a solution for identity federation management, cross-domain authentication, and session management. This specification also defines provider metadata schemas that may be used for making a priori arrangements between providers.

The Liberty architecture contains three actors: Principal, identity provider, and service provider. A Principal is an entity (for example, an end user) that has an identity provided by an identity provider. A service provider provides services to the Principal.

Once the Principal is authenticated to the identity provider, the identity provider can provide an authentication assertion to the Principal, who can present the assertion to the service provider. The Principal is then also authenticated to the service provider if the service provider trusts the assertion. An identity federation is said to exist between an identity provider and a service provider when the service provider accepts authentication assertions regarding a particular Principal from the identity provider. This specification defines a protocol where the identity of the Principal can be federated between the identity provider and the service provider.

This specification relies on the SAML specification [defined in SAML Core]. In SAML terminology, an identity provider acts as an Asserting Party and an Authentication Authority, while a service provider acts as a Relying Party.

Liberty Alliance specification version 1.0 documents:

• Liberty Bindings and Profiles Specification. Edited by Jason Rouault (Hewlett-Packard Company). Version 1.0. Reference: liberty-architecture-bindings-and-profiles-v1.0. 11-July-2002. 57 pages. "This specification defines the bindings and profiles of the Liberty protocols and messages to HTTP- based communication frameworks. This specification relies on the SAML core framework in [SAMLCore] and makes use of adaptations of the SAML profiles in [SAMLBind]. A separate specification, ['Liberty Protocols and Schemas Specification'], is used to define the Liberty protocols and messages used within the profiles."

• Liberty Architecture Overview. Edited by Jeff Hodges (Sun Microsystems, Inc.). Version 1.0. Reference: liberty-architecture-overview-v1.0. 11-July-2002. 41 pages. "The path to realizing a rich, fertile federated identity infrastructure can be taken in phases. The natural first phase is the establishment of a standardized, multivendor, Web-based single sign-on with simple federated identities based on today's commonly deployed technologies. This document presents an overview of the Liberty Version 1.0 architecture, which offers a viable approach for implementing such a single sign-on with federated identities. This overview first summarizes federated network identity, describes two key Liberty Version 1.0 user experience scenarios, summarizes the Liberty engineering requirements and security framework, and then provides a discussion of the Liberty Version 1.0 architecture."

• Liberty Protocols and Schemas Specification. Edited by John D. Beatty (Sun Microsystems, Inc.). Version 1.0. Reference: liberty-architecture-protocols-schemas-v1.0. 11-July-2002. 27 pages. "This specification defines the abstract Liberty protocols for identity federation, single sign-on, name registration, federation termination, and single logout. Several concrete bindings and profiles of these protocols are defined in the 'Liberty Bindings and Profiles Specification'. This specification uses schema documents conforming to W3C XML Schema and normative text to describe the syntax and semantics of XML-encoded SAML assertions and protocol messages."

• Liberty Architecture Glossary. Edited by Hank Mauldin (Cisco Systems, Inc.). Version 1.0. Reference: liberty-tech-glossary-v1.0. 11-July-2002. 13 pages. "This document is intended to provide a reference of terms, which ensures that when discussing identity solutions for the Internet and, in particular, the solution defined by the Liberty Alliance, a common understanding of their meaning exists. This document is not intended to be a complete and authoritative compendium of all terms used when discussing network identity, but rather a comprehensive list of definitions for concepts used in the whole Liberty scope."

• Liberty Authentication Context Specification. Edited by Paul Madsen (Entrust, Inc.). Version 1.0. Reference: liberty-architecture-authentication-context-v1.0. 11-July-2002. 35 pages. "This specification defines a syntax for the definition of authentication context statements and an initial list of Liberty authentication context classes... Authentication context is defined as the information additional to the authentication assertion itself that the service provider may require before it makes an entitlements decision... Liberty will not prescribe a single technology, protocol, or policy for the processes by which identity providers issue identities to Principals and by which those Principals subsequently authenticate themselves to the identity provider... If the service provider is to place sufficient confidence in the authentication assertions it receives from an identity provider, it will be necessary for the service provider to know which technologies, protocols, and processes were used or followed for the original authentication mechanism on which the authentication assertion is based. Armed with this information and trusting the origin of the actual assertion, the service provider will be better able to make an informed entitlements decision regarding what services the subject of the authentication assertion should be allowed to access."

• Liberty Architecture Implementation Guidelines. Edited by Lena Kannappan (France Telecom) and Matthieu Lachance (Openwave Systems Inc.). Version 1.0. Reference: liberty-architecture-impl-guidelines-v1.0. 11-July-2002. 12 pages. "This document defines the recommended implementation guidelines and checklists for the Liberty architecture focused on deployments for the service-providing entities: service providers, identity providers, and Liberty-enabled clients or proxies (LECPs). It is intended to provide recommended implementation guidelines to Liberty component developers to help them decide what they need to implement to meet their business needs... The document also provides a checklist of requirements based on the following Liberty architecture specification categories that implementers can use to advertise their supported feature set: (a) Functionality in the Liberty protocols and schemas described (b) Bindings and profiles defined for each Liberty protocol type (specific interactions between identity providers, service providers, and LECPs) (c) The authentication request and reply context-specific information."

From the FAQ document:

On July 15, 2002 the Liberty Alliance announced public availability of its version 1.0 specifications, the consortium's open, platform-agnostic specifications for federated network identity. The version 1.0 specifications focus on interoperability between systems to enable opt-in account linking and simplified sign-on functionality. This allows users to decide whether to link accounts with various identity providers and makes it easier for both consumers and businesses to take advantage of the growing Web services space. The Liberty Alliance also released guidance on how its next set of specifications will build on the version 1.0 specifications.

The Liberty version 1.0 specifications are the first step in building an open federated identity platform that will enable users to link their accounts with various disparate identity providers. Specifically, the first specifications enable the following features:

• Opt-in account linking: Users can choose to link accounts they have with different service providers that are within "circles of trust" (existing business agreements or affinity programs)
• Simplified sign-on for linked accounts: Once a user's accounts are federated, he/she can log in and authenticate at one linked account and navigate to another linked account without having to log in again.
• Authentication context: Institutions or companies linking accounts can communicate the type and level of authentication that should be used when the user logs into different accounts.
• Global log-out: Once a user logs-out of the site where they initially logged in, the user can be automatically logged-out of all of the other sites the user linked to and still maintains a live session.
• Liberty Alliance client feature: This can be implemented on particular client solutions in fixed and wireless devices to facilitate use of the Liberty version 1.0 specifications.

The Liberty version 1.0 specifications do not involve the exchange of personal information, but rather a format for exchanging authentication information between companies so as to not reveal the identity of the user. The user may maintain separate identities in different locations.

Network identity refers to the global set of attributes that are contained in an individual's various accounts with different service providers. These attributes include such information as name, phone numbers, social security numbers, addresses, credit records and payment information. For individuals, network identity is the sum of their financial, medical and personal data-which must be carefully protected. For businesses, network identity represents their ability to know their customers and constituents and reach them in ways that bring value to both parties.

Federated network identity means consumers and businesses can allow separate entities to manage different sets of identity information. Account federation enables associating, connecting or binding a user's multiple Internet accounts within an affiliated group established between or among commercial and non-commercial organizations and governed by some legal agreement. Federated single sign-on enables users to sign on with one member of an affiliate group and subsequently use other sites within the group without having to sign-on again.

[The version 2.0 specifications] will extend the simplified sign-on capabilities in version 1.0 and enable organizations to share certain personal information of users according to the permissions and preferences granted by the user. The Alliance also anticipates that the next set of specifications will enable organizations to link and extend their service offerings between various "circles of trust" or industries.