Liberty Alliance examines business requirements

One difference between WS-Federation and the Liberty Alliance specification for federated identity is that WS-Fed is the product solely of technology vendors while the Liberty Alliance, which has tech vendors as members, is primarily composed of consumer products vendors, government and nonprofit organizations. Reflecting that makeup, Liberty is quick to point out that technology is only part of the federation problem, and in many ways it’s the easiest part to solve.

At last week’s Burton Group Catalyst Conference, the Liberty Alliance published a preliminary document outlining business requirements for wide-scale deployment of federated network identity. This is planned as the first in a series of documents outlining good practices for identity federation. WS-Fed so far has not even begun to address the business requirements of federation.

As many of us have found out through our experiences with identity provisioning, the technology is the easy part. Cultural differences between organizations – even between different parts of a single organization – coupled with turf battles over data and political fights over control are the battlefields that the provisioning revolution was (and still is) fought on. Identity federation won’t be very different.

The Liberty group’s business document is available at:

https://www.projectliberty.org/resources/business_guidelines.html

It looks at four areas:

* Mutual confidence – the processes and tasks business partners must undertake to set minimum quality requirements, certify the other party has met those requirements, and manage the risk of exposure.

* Risk management – the best practices and procedures business partners must identify to guard themselves from losses due to identity fraud or the exposure of identity information as well as the loss of business integrity due to insecure processes or data.

* Liability assessment – the process for determining what parties will bear which losses under what circumstances, and how to resolve disputes.

* Compliance – the alignment with agreed-upon standards, policies and procedures and how that compliance is governed, including compliance with local privacy requirements.

These guidelines owe much to the experiences companies have had with the Electronic Data Interchange (EDI) framework over the past 25 years, another place where technology was 10% of the solution and business process negotiation was 90%.

It does sound a bit like the lawyers demanding their pound of flesh, and it’s easy for the technologists to say they can build in safeguards so that bad things never happen. But time and time again bad things have happened. When large amounts of money and prestige are at stake, the business managers aren’t going to let the technology managers have the final say. The business case has to be made, the business requirements have to be met. Only after that’s been done will the technology be able to make the connections. It was like that with EDI, it was (and is) like that with provisioning and it will also be like that with identity federation. Companies who overlook this necessary step do so at their own peril.