The Liberty Alliance Project has released a public review draft of its version 1.1 specifications. This maintenance update incorporates feedback received from members and non-members during the last three months. The version 1.1 document suite is the first to be issued by the Liberty Alliance for public input. The Liberty Alliance Project represents "an alliance of more than 130 technology and consumer organizations formed to develop and deploy open, federated network identification specifications that support all current and emerging network devices in the digital economy. Its specifications focus on enabling interoperability between technology systems to make it easy for businesses to provide opt-in account linking and simplified sign-on functionality to partners, customers and employees." The version 1.1 draft specification suite includes two XML Schema files corresponding to the Protocols and Schema Specification and the Authentication Context Specification. The Liberty Bindings and Profiles Specification defines concrete transport bindings and usage profiles for the abstract Liberty protocols. Supporting documents include an Overview, Glossary, and Implementation Guidelines. In addition to the editorial changes, the v1.1 specification fixes a vulnerability in a Liberty-enabled Client/Proxy Profile and includes minor enhancements to provide additional flexibility in the specifications for identity and service providers. The public review period extends through December 16, 2002.

From the 2002-11-19 announcement:

The majority of the updates in the version 1.1 specifications are focused on reducing barriers for implementers, by improving flexibility and clarifying some ambiguities in the version 1.0 specifications.

"The Liberty Alliance is striving to address the requirements of a wide range of businesses and industries, and as part of this effort we are encouraging non-members as well as members to provide feedback regarding the version 1.1 specifications, which are works-in-progress," said Simon Nicholson, chairman of the Liberty Alliance Technology Expert Group. "Because so many organizations are involved in the work of the Alliance, we have a unique opportunity to understand the business issues companies want to solve and the end-user benefits they want our specifications to provide."

Some examples that illustrate how the Liberty Alliance specifications could benefit end-users:

• Business-to-employee example: Businesses could increase productivity and reduce hassle for their employees by linking the various applications they use to do their jobs, and/or applications on the corporate Intranet, such as 401K, health benefits, and travel services. This would enable employees to move seamlessly from one service or application to another without having to enter multiple user names and passwords.

• Business-to-business example: Businesses could reduce IT costs, increase operational efficiencies and enhance relationships with their suppliers, vendors or other partners by enabling them to access multiple business applications within an extranet in a more seamless way.

• Business-to-consumer example: Businesses could provide more convenience to customers. In the travel industry, for example, various companies that choose to establish partnerships, or "circles of trust," could provide their customers with the ability to book airline tickets, rent cars, reserve hotel rooms using the affinity programs within each of the companies without requiring customers to enter usernames and password information at each site.

The Liberty Alliance is taking a phased approach to the release of its specifications and anticipates that the next major release of specifications, version 2.0, will be issued in 2003. Version 2.0, which will build upon version 1.1, will provide an infrastructure for developing and supporting identity-enabled Web services from companies, organizations or government entities. The infrastructure will include a framework for permissions-based attribute sharing and will allow groups of organizations, often referred to as "circles of trust" or authentication domains, to be linked together, as opposed to operating as separate islands.