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

Hi Bob:
I agree with you!  In fact, our product folks have added an AllInOrder 
operator.
The assertions within this operator are applied in the order that they 
appear.
Adding such an operator would be my first preference.
However, I understand that it's too late to add such an operator since 
it would
require a change in the Policy Framework spec which is now a Rec.

All  the best, Ashok

Natale, Bob wrote:

>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?
>
>Cheers,
>BobN
>
>-----Original Message-----
>From: public-ws-policy-request@w3.org
>[mailto:public-ws-policy-request@w3.org] On Behalf Of ashok malhotra
>Sent: Wednesday, October 10, 2007 12:56 PM
>To: public-ws-policy@w3.org
>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 
><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 18:41:15 UTC