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 
<http://www.w3.org/TR/2007/REC-ws-policy-20070904/#policy_subject> are 
beyond the scope of this specification. However, authors can write 
assertions that control the order in which behaviors are applied.”. This 
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 
http://lists.w3.org/Archives/Public/public-ws-policy/2007Aug/0008.html, 
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, I

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 performed? 
And, who is to say that? Clearly, some general rules can be established, 
such as encryption is done last and decryption is done first. This seems 
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 specify 
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 type 
ID to each assertion within a Policy alternative where ordering is 
important.

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 assertion.

Consider the following Policy:

<wsp:Policy>

<wsp:All>

<sns:DoThis id=’banana’/>

<sns:DoThat id= ‘orange’/>

<acme:ordering order = ‘orange apple banana’/>

<sns:DoTheOther id=’apple’/>

</wsp:all>

</wsp:Policy>

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 assertion.

-- 
All the best, Ashok

Received on Wednesday, 10 October 2007 16:57:19 UTC