Microstandards – unravelling WS-Policy

I've been trying to explain my thinking about Microstandards. I see these as being standards objects that can be combined and specialized to define complex distributed systems. I thought I might help others understand what I'm saying by picking an example and discussing it.

So I rolled the dice and came up with WS-Policy. Let's start by getting a feel for the scope of this thing.

I count the authors. Three from VeriSign, two from Sonic Software, five from IBM, six from Microsoft, one from BEA and one from SAP. Yikes – that makes eighteen.

But it is twenty-two pages long, of which six are introduction, table of contents, nomenclature, abstract, references, and all the associated formalities. Another nine pages are essentially examples (can there ever be too many examples?) Which leaves seven pages of discursive specification.

The specification defines the following:

• An XML Infoset called a policy expression that contains domain-specific, Web Service policy information.
• A core set of constructs to indicate how choices and/or combinations of domain-specific policy assertions apply in a Web services environment.

Here's the canonical example of such a policy expression:

01 <wsp:Policy>

02 <wsp:ExactlyOne>

03 <wsse:SecurityToken>

04 <wsse:TokenType>wsse:Kerberosv5TGT</wsse:TokenType>

05 </wsse:SecurityToken>

06 <wsse:SecurityToken>

07 <wsse:TokenType>wsse:X509v3</wsse:TokenType>

08 </wsse:SecurityToken>

09 </wsp:ExactlyOne>

10 </wsp:Policy>

I'll bet you catch the drift already. The Policy element sets off the policy expression, and the ExactlyOne element is used to introduce a set of policy alternatives. The SecurityToken element has nothing to do with WS-Policy itsef! It is just an example of a domain-specific InfoSet contained within the policy (in fact, the contents of SecurityToken would comprise a different microspec – in this example, WS-SecurityPolicy).

Here's how WS-Policy puts it:

Lines 02-09 illustrate the Exactly One policy operator. Policy operators group policy assertions into policy alternatives. A valid interpretation of the policy above would be that an invocation of a Web service contains one of the security token assertions (Lines 03-08) specified. Lines 03-05 and 06-08 represent two specific security policy assertions that indicate that two types of authentication are supported.

WS-Policy goes on to define policies as collections of policy alternatives that are sets of policy assertions that are themselves typed InfoSets. This leads to the normal form of a policy expression (so here is the spec in a nutshell):

<wsp:Policy … >

<wsp:ExactlyOne>

[ <wsp:All> [ <Assertion …> … </Assertion> ]* </wsp:All> ]*

</wsp:ExactlyOne>

</wsp:Policy>

This example demonstrates how an All element combines with an ExactlyOne element to give us everything we need to negotiate technical agreements. Next follows a discussion of how to identify policies with URIs, and securely include one policy in another. Then there is a brief but cool section showing how policy alternatives and assertions are associative, commutative, distributive and idempotent (this is a huge breath of fresh air).

For example:

<wsp:All>

<wsp:ExactlyOne>

<!– assertion 1 –>

<!– assertion 2 –>

</wsp:ExactlyOne>

</wsp:All>

is equivalent to:

<wsp:ExactlyOne>

<wsp:All>

<!– assertion 1 –>

</wsp:All>

<wsp:All>

<!– assertion 2 –>

</wsp:All>

</wsp:ExactlyOne>

Finally, while recognizing that policy intersections must be evaluated in a domain-specific way, WS-Policy suggests a high level algorithm for calculating intersections.

So that's it, folks. Building WS-Policy compliant applications means that when you negotiate your policy with another end-point, you use this way of structuring the XML that describes the policy. You likely don't have to write a line of code to comply. In fact, I look at this spec as eliminating a lot of lines of code by giving us a simple way to express our policy alternatives and to evaluate them.