AustLII Home | Databases | WorldLII | Search | Feedback

Privacy Law and Policy Reporter

Privacy Law and Policy Reporter (PLPR)
You are here:  AustLII >> Databases >> Privacy Law and Policy Reporter >> 2004 >> [2004] PrivLawPRpr 32

Database Search | Name Search | Recent Articles | Noteup | LawCite | Help

Vierboom, Francis --- "Distributed identity Part 3 - WS-Federation as a case study" [2004] PrivLawPRpr 32; (2004) 11(2) Privacy Law and Policy Reporter 52

Distributed identity Part 3 -
WS-Federation as a case study

Francis Vierboom

This is the third in a series of case studies on privacy implications of distributed identity systems. The first two parts, published in 2004 10(9) PLPR 161 and (2004) 11(1) PLPR 21, provided a general introduction to some of the issues raised by distributed identity systems, the Irish Government’s Reach system, and at one emerging standards that rely on a ‘federated identity’ mode (Liberty Allianc). This part examines two other models, the WS-Federation and WS-Privacy specifications. (General Editor)

In April 2002, IBM and Microsoft jointly published the whitepaper Security in a Web Services World[1] , dubbed the ‘roadmap’ of a secure web services framework, together with its founding WS-Security specification. The roadmap set out a body of protocols that would use XML[2] messages as a standard way for computers to communicate service requests to each other, regardless of the software or hardware they used - the web services model.

The Initial Framework Plan[3]


For now, the WS framework provides an advanced security infrastructure for integrating enterprise IT systems, and only for a small number of ambitious companies. Eventually it aims to provide security for a new generation of distributed applications for both consumers and businesses.

WS-Federation is, at best, a skeleton distributed identity system. The nature and content of the information exchanged is not dealt with by the WS specifications. Indeed, only WS-Federation and WS-Privacy really contemplate the identity federation applications of the WS system. But WS provides a highly advanced ‘infrastructure’ necessary for such information exchange.


Technical overview

The web services security roadmap sets out the seven standards that were planned to form the WS security architecture, as well as noting the SOAP standard on which it is based.

SOAP[4] (Simple Object Access Protocol) is a recognised standard for passing messages between web applications. It enables different programs running on different operating systems in different countries to pass each other data and request operations.

WS-Security[5] defines extensions to the SOAP standard to include encryption information such as PKI certificates and Kerberos tickets in a ‘security token’ attached to the SOAP message. This standard has, in fact, been adopted by the Liberty Alliance project.[6]

WS-Policy[7] , WS-Trust[8] , WS-SecureConversation[9] and the upcoming WS-Authorization build on WS-Security and add more advanced network functions.

WS-Federation[10] brings together the four WS standards already published to describe a ‘federated’ web services model, and details the use of identifiers and pseudonyms across service providers and requestors. It also considers the types of transactions that could occur and some of the privacy and security precautions applied to a federated system.

WS-Privacy is not yet published but it is described in the roadmap document. It may use WS-Security (for basic security), WS-Policy (as a structured way to ask privacy questions) and WS-Trust (as a way to manage privacy across several transactions) to provide for privacy controls in web services networks. Systems can use WS-Privacy to make assertions about their privacy practices Ð for example, they can promise not to pass the data on to any third parties.

Web Services applications

By keeping their specifications at such a broad and low level, only a very small group of very large companies can afford to adopt an MS/IBM web services system in the near future. This is bound to change, as the next version of Microsoft Windows (codenamed ‘Longhorn’) due out in 2005 includes the WS framework as a major feature[11] . But for now the WS project is more abstract than other sector initiatives like Liberty Alliance. In most cases there is no instant gratification from integrating IT systems with WS like there is from integrating identities and customer profiles using Liberty or MS Passport. Rather, the web services concept is a new way of using distributed systems. WS is only a means, not an end.

However it is conceivably a means to many powerful ends. Implementations of WS can simplify and automate many varied business transactions.

Of course, most practical applications that WS could manage have already been automated to a degree. It is no great feat in 2004 to have an inventory database communicate with a supplier to order parts. But many features of such systems have to be set up within each individual relationship for the purposes of security, privacy and basic compatibility. In fact, usually they need to be running the same software on the same operating system to communicate in any significant way.

A part of the WS goal is to create a new standard layer of automated information flows and business transactions that allows entities like suppliers and inventory databases to communicate easier. However, in doing so, it will need to address privacy - a highly significant area of legislative compliance and the customer relationship that has, until now, been managed by humans and implemented in IT systems on an ad hoc basis.WS-Privacy

The WS framework has been developed with such issues in mind. Thus the WS security architecture (in marked contrast to the Liberty Alliance project) actually includes specific functionality for managing information privacy. The WS-Privacy module will provide a way for WS systems to inform each other of their privacy practices.

As mentioned above, the WS-Privacy specification release is expected late this year. However, we gain some hints about the possible shape of WS-Privacy from a diploma thesis[12] written at the IBM Zürich Research Laboratory. Judging from the thesis, it is possible that WS-Privacy will add a new set of headers for use in a SOAP message to communicating privacy policies that look something like this:

<soap-pr:Privacy xmlns:soap-pr=”http://privacyschema”


<soap-pr:Promise> </soap-pr:Promise>

<soap-pr:Promise-Ack> </soap-pr:Promise-Ack>

<soap-pr:Requirement> </soap-pr:Requirement>

<soap-pr:Requirement-Ack> </soap-pr:Requirement-Ack>

<soap-pr:Binding> </soap-pr:Binding>

<ds:Signature> hSK7...</ds:Signature>


The soap-pr:Promise element can be used by a data requester to communicate a privacy assertion Ð for example, “Information will only be disclosed for purposes related to accounting.” Such an assertion is acknowledged by the data provider with the soap-pr:Promise-Ack element.

The data provider can also impose privacy requirements on the data recipient using the soap-pr:Requirement element Ð for example, “Information must only be used for purposes related to subject’s cheque account.” The recipient can then choose to acknowledge that request with soap-pr:Requirement-Ack or abandon the transaction.

The soap-pr:Binding element is used to translate the vocabulary used in the actual data request (contained in the SOAP body element which is not shown) and vocabulary used in the privacy policy that is included or referred to in a Promise or Requirement.

The ds:Signature is a digital signature the provides message integrity (proof the message has not been tampered with) and non-repudiation (proof that the sender actually sent the message).

The contractual nature of such a transaction gives rise to a degree of legal uncertainty. The complexities of contract law developing around electronic transactions is not in the scope of this paper, but it will be important to consider the legal status and precedence of WS-Privacy exchanges in the future. For example, where a WS-Privacy-managed transaction has malfunctioned, will it supplant the intended privacy policy?

At any rate, before any such legal uncertainty arises, WS systems need to be able to communicate their privacy practices in a standard and machine-readable way.

For consumers, the Platform for Privacy Preferences (P3P)[13] is already an established way for web sites to communicate privacy policies to users in general fashion. For some applications this may be good enough to provide consumers with notice and choice about how their information will be used. P3P is being developed and reformatted into XML[14] for specific use in WS applications. However, P3P cannot realistically be used by enterprise IT systems for high-volume, complex data transactions.

For these more demanding situations the Enterprise Privacy Authorisation Language (EPAL) is another proposed standard that IBM has recently published[15] . EPAL is a language for expressing privacy rules in terms of the data user, data type, the action to be performed on the data, the purpose of the action, and other context variables (eg data subject’s consent, current time, local security environment) stored in ‘containers’. By regulating privacy transactions using an EPAL policy layered over a WS-Privacy system, the privacy policy is easy to modify, even by non-technical staff, and a company’s privacy policy compliance is simple to audit.

IBM anticipates the use of EPAL in conjunction with WS-Privacy as can be seen in one of its presentations, Enterprise Privacy and Federated Identity Management[16] (a presentation which explains the EPAL model well and is recommended to all those interested in this article).

Privacy and the WS framework

At the time of publishing, prior to the release of WS-Privacy, the WS framework provides only minor privacy features in addition to its security basis. WS-Federation allows for the optional use of ‘opaque identifiers’ so that no identifying information need be shared for basic identity federation functions.

The plan for WS-Privacy is an encouraging step towards making privacy a functional part of IT systems. But implementations of the specification will not do any better at protecting privacy than they are designed to. As noted in this article’s companion paper[17] , distributed identity systems have a serious impact on privacy. WS-Privacy may provide a useful tool for enforcing the rules but good privacy, just like good business, is based on treating customers fairly and with respect, not just complying with the legislation, as may be the temptation with a WS-Privacy system.

Of course, before criticising WS for privacy shortcomings, it should also be remembered that the WS security framework is essentially a technically focused initiative. At the moment, the WS framework is not used for federated identity and it is only one of several applications for which the framework will eventually be useful. Microsoft and IBM may well deserve the congratulations and support of privacy advocates for treating the issue with such respect at this early stage.

But they must continue to take the responsibility for building privacy solutions into WS. The other notable feature of the WS framework is that while its actual applications are still fairly abstract, it does not generally assume that the two parties are already in some kind of relationship. WS systems will interoperate with other WS systems almost fresh out of the box[18] . The obvious consequence is that at some time in the future, if the use of the WS framework becomes widespread Ð as it seems bound to with the eventual release of the WS-enabled Longhorn Windows operating system Ð web services will be able to conduct transactions with ‘foreign’, unknown systems. The security and privacy risks of such a structure are, naturally, the focus of much of IBM and Microsoft’s efforts but they will always be risks, especially considering the fondness hackers have for targeting Microsoft security vulnerabilities.

WS and Liberty Alliance - the future of distributed identity

There is growing tension between the WS initiative and the Liberty Alliance federated identity project. The most recent WS specification, jointly published by Microsoft, IBM, Verisign, BEA and RSA Security, WS-Federation, steps sorely on the toes of a large part of the work done by the Liberty consortium (made up of over 160 various companies and organisations). Despite the earlier co-operation shown by Liberty’s adoption of the WS-Security standard into their own specifications, the simmering rivalry between Microsoft and Sun Microsystems (one of Liberty’s founders and a leading proponent) may yet poison efforts to have the two work together.

Liberty Alliance is a commercially funded and oriented project. Much of its research has been aimed at specific commercial goals related to identity management and federation, in contrast to the more technical motivation of much of the WS work. Thus, Liberty has made far more progress in defining how to manage and exchange personal information across Liberty networks Ð although this is an area where it will be in competition with MS Passport (which is being reconceived to work on top of WS systems) rather than a WS standard. At this ‘application level’, Liberty’s open approach may well be favoured over the widespread but much maligned Passport.

The deployment of the WS standards within the so-called ‘Indigo’ software in the next release of Microsoft Windows, however, will likely supplant the more basic infrastructure aspects of the Liberty Alliance specifications. Admittedly, Microsoft is simply providing the WS functionality and developers are free to use other web services software[19] , perhaps as much out of fear of antitrust lawsuits as for developer convenience. But without judging the technical merits of either system, it would seem the WS framework, through the muscle of Windows, will render Liberty’s low-level technical specifications still-born, especially considering Liberty’s focus on consumer-facing applications pitted against Windows’ stranglehold on that market.

Liberty’s likeliest eventual path appears to be to retreat to higher-level applications above the WS framework. However, depending on the scope of the WS-Privacy specification, there may still be room for more standards in privacy management at this higher level. It remains to be seen if EPAL[20] will gain traction as a privacy language, and if it (or something similar) will be widely implemented in Liberty-style federated identity systems.

Liberty’s perspective on WS-Federation is expressed in a recent whitepaper, Liberty Alliance & WS-Federation: A Comparative Overview[21] . It is unsurprisingly unkind to the WS-Federation specification and the overall WS framework. It points to weaknesses in the WS framework’s information-sharing capabilities and champions Liberty’s privacy efforts.


It appears to be likely Microsoft and IBM’s WS framework will gain a foothold in providing basic interoperable web services. But there may yet be a battle over how privacy and personal information will be managed in a web services enabled world. Liberty Alliance has a significant privacy options, and WS-Privacy and EPAL are also promising initiatives that could provide the answer.

They are not simple or cheap solutions. But finding a solution is important. Companies need to be able to comply with regulatory frameworks. And a future hard-wired for thoughtless exchanges of personal information is good news for nobody.

Francis Vierboom is a consultant with Galexia Consulting

[1] IBM Corporation and Microsoft Corporation, Security in a Web Services World, April 2002, <>.

[2] Extensible Markup Language (XML): <>

[3] Image from <>.

[4] More information: SOAP Version 1.2 Part 0: Primer, W3C, June 2003 <>.

[5] WS-Security: <>.

[6] Liberty Alliance, Liberty Alliance Releases New Specifications, Privacy and Security Guidelines to Drive Development of Identity-Based Web Services, 15 April 2003, <>.

[7] WS-PolicyFramework: <>.

[8] WS-Trust: <>.

[9] WS-SecureConversation: <>.

[10] WS-Federation: <>.

[11] Mike Ricciuti, Gates gambles on Longhorn, CNET, 28 October 2003, <>.

[12] Walid Bagga, Privacy-enabled Application Scenarios for Web Services, Network Security & Cryptography Group, IBM Zurich Research Laboratory, September 2003, <>.

[13] The Platform for Privacy Preferences (P3P) Project <>.

[14] An editor’s draft schema is publicly available at <> .

[15] The Enterprise Privacy Authorization Language (EPAL 1.1) <>.

[16] Ashley et al, Enterprise Privacy and Identity Management, IBM Zurich Research Lab and IBM Privacy Research Institute. Presented by Michael Waidner at Almaden Institute 10 April 2003, <> at p12.

[17] Galexia Consulting, Distributed Identity Case Studies - Part 1, September 2003, <>.

[18] Lee, Yvonne, Web Services Federation Now Defined, SD Times, 1 August 2003, <>.

[19] Elizabeth Montalbano, Advanced Web Services To Find Home In Microsoft’s Indigo, CRN, 28 October 2003 <>.

[20] The Enterprise Privacy Authorization Language (EPAL 1.1) <>.

[21] Liberty Alliance Project: Liberty Alliance & WS-Federation: A Comparative Overview, 14 October 2003, < >.

AustLII: Copyright Policy | Disclaimers | Privacy Policy | Feedback