Third spec emerges for identity federation

Last week, as you were (I hope) reading in this newsletter about the Shibboleth specification for identity federation recently released by the Internet2 group, a “competitor” spec was launched at the Burton Group Catalyst Conference by a consortium of IBM, Microsoft, BEA, RSA and VeriSign.

The spec is called WS-Federation (WS-Fed). “WS” in this case stands for Web Services, and WS-Federation is one in a series of WS specs revolving around IBM and Microsoft’s vision of what Web services will encompass.

While the Liberty Alliance and Shibboleth specs rely on Security Assertion Markup Language (SAML) as the mechanism for exchanging authentication and authorization data, WS-Fed does not specify a particular security token mechanism and will support SAML, Kerberos, x.509 certificates and Extensible Rights Markup Language – and it can be easily extended to other methods.

Another major differentiator among the three systems is the makeup of the groups designing the spec. WS-Fed was created entirely by technology vendors, Shibboleth by the higher education community (with input from some technology vendors), and the Liberty spec was driven mostly by consumer-oriented non-tech companies (United Airlines, American Express, Hertz, and so on).

Since Shibboleth was created by the organization that is also creating the private Internet2, it will undoubtedly be used in that environment, thus assuring it some viability. Also, fairly certainly, it will not be used on the public Internet, at least by commercial interests, simply because they have no input into its design and use. But it may be that both Liberty and WS-Fed survive and get used on the public Internet.

Because there will need to be identity data exchanged between the public Internet and Internet2, there will need to be gateways built between Shibboleth and either Liberty or WS-Fed, but more likely both. It should then be a small step to build an abstraction layer that supports both WS-Fed and Liberty, which means end users wouldn’t have to choose, and vendors could implement one, the other or both.

More than likely some non-technological issue will ultimately force the choice between WS-Fed and Liberty, such as privacy concerns, or ease of implementation for a particular business case. There are some basic differences regarding where to store data, what data to exchange and how identifiable a user is, which should insure a long and vigorous debate over privacy. There quite probably are implementation differences based on business case, but we don’t know those yet because only the Liberty Alliance group has released any documentation of business requirements for federation (such as liability frameworks). IBM and Microsoft better get to work on that aspect, and soon, if they expect WS-Fed to be adopted at all.

Next issue we’ll look at the Liberty business case and why that’s important.