RE: Ordering of Assertions: Comment on WS-Policy Primer LCWD

Hi Ashok,

I agree that an ordering mechanism is imperative for WS-Policy.

However, your example seems very contrived (why not just write the
three assertions in order and be done with it, rather than inserting
some re-ordering statement among them?).

I would recommend consideration of a construct similar to "sequence" in
XSD -- does that seem feasible?


-----Original Message-----
[] On Behalf Of ashok malhotra
Sent: Wednesday, October 10, 2007 12:56 PM
Subject: Ordering of Assertions: Comment on WS-Policy Primer LCWD

  Ordering of Assertions

The Framework document says: "Assertions within an alternative are not 
ordered, and thus aspects such as the order in which behaviors 
(indicated by assertions) are applied to a subject 
<> are 
beyond the scope of this specification. However, authors can write 
assertions that control the order in which behaviors are applied.".
is a curious head-in-the-sand statement as it admits that the order in 
which assertions within an alternative are applied can be important and

then refuses to address the problem.

In a note to the WG,

Tony Rogers said:

"While I can appreciate the desire to avoid specifying the order of

applying the behaviors, I think the line has been crossed when

suggesting the possibility of an ordering assertion. By suggesting it,

believe the WG is obligated to provide an example of a possible form

That the order in which assertions are applied is important is 
demonstrated by WS-SecurityPolicy which defines the assertions below to

set the Protection Order Property:

<sp:SignBeforeEncrypting />

and <sp:EncryptBeforeSigning />

The WS-SecurityPolicy spec discusses the order in which assertions 
should be applied in several places, leaving no doubt that the order in

which things are done is, indeed, important.

So, within a particular Policy domain, if the order of assertions is 
important, the domain can specify ordering assertions as shown in the 
above examples from the security domain. But, what about policy 
assertions from different domains? For example, how do we say that 
Reliable Messaging headers must be added before encryption is
And, who is to say that? Clearly, some general rules can be
such as encryption is done last and decryption is done first. This
like a sensible rule although WS-SecurityPolicy does not say that.

Into this mix of assertions from different domains add the possibility 
of custom assertions that an installation may want to support, say 
logging or auditing. In many cases the order in which assertions are 
processed may not matter, but where it does matter do we need to
a special assertion for every pair of assertions that need to be 
ordered? Clearly, this is not feasible as the Policy processing engine 
will need to be undated whenever a new ordering assertion is added. So,

what we need is a general-purpose ordering assertion.

Here is one way of accomplishing this. Create an ordering assertion 
which has a single attribute of type IDREFS, no element children or 
other attributes. Say,

<acme:ordering order = "1 3 2" />

Here the "ordering" assertion has a single attribute called "order" of 
type IDREFS. Use the extensibility mechanism to add an attribute of
ID to each assertion within a Policy alternative where ordering is 

Include the ordering assertion within the policy alternative. The order

in which the assertions in the alternative will be applied is the order

in which their IDs appear on the order attribute of the ordering

Consider the following Policy:



<sns:DoThis id='banana'/>

<sns:DoThat id= 'orange'/>

<acme:ordering order = 'orange apple banana'/>

<sns:DoTheOther id='apple'/>



where the three assertions in the namespace identified by the "sns" 
prefix have an attribute named 'id' of type ID. The assertions in this 
Policy would be applied in the order indicated by the ordering

All the best, Ashok

Received on Wednesday, 10 October 2007 18:30:39 UTC