W3C home > Mailing lists > Public > public-ws-policy@w3.org > January 2007

Suggested Feedback to WS-Policy

From: Ashok Malhotra <ashok.malhotra@oracle.com>
Date: Thu, 11 Jan 2007 14:38:38 -0800
To: "public-ws-policy@w3.org" <public-ws-policy@w3.org>
CC: "ws-rx@lists.oasis-open.org" <ws-rx@lists.oasis-open.org>
Message-ID: <20070111143838542.00000003576@amalhotr-pc>

On the 1/4 WS-RX telcon I was given an action item to look at the WS-RX Policy assertions and create some feedback to the WS-Policy WG.

This is a personal comment not a comment from the WS-RX TC.

There are three RM assertions:
1. <wsrmp:RMAssertion [wsp:Optional="true"]? ... > 
2. <wsrmp:SequenceSTR [wsp:Optional="true"]? ... /> 
3. <wsrmp:SequenceTransportSecurity [wsp:Optional="true"]? ... />

Assertion 2 depends on assertion 1 and is invalid unless 1 is present.
Assertion 3 depends on 1 and the presence of a sp:TransportBinding assertion.  Both must be present for assertion 3 to be valid.

1. The WS-Policy Framework document says in section 3.1:
"[Definition: A policy assertion represents an individual requirement, capability, or other property of a behavior.] The word "individual" is not accurate.  If  assertion 2 and assertion 1 are used the capability is defined by their combination.  

In the security domain, several assertions may be needed to define a capability.  For example, a SecurityBinding assertion may be used to set up keys for encryption and signing and then separate assertions to specify what must be signed or encrypted.  In addition, there may be a statement that says "sign before encryption" or "encrypt before signing".  Thus the capability specified by the policy that contains these three assertions is conveyed by a combination of the 3 assertions and each assertion, on its own is not useful. 

Thus, change the above sentence to something like "[Definition: A policy assertion represents a requirement, capability, or other property of a behavior that is defined, possibly, in combination with other assertions in with assertion-specific semantics.]


2. The Guidelines for Policy Assertions document discusses dependencies between assertions in section 6.
It would be useful in this section to warn the assertion authors that dependencies between assertions can create difficulties when policies are normalized.  It may also be desirable to add an example of a policy that contains two assertions whose validity depends on one another.  If both assertions are marked 'optional', then the two of the four policy alternatives which are generated will contain only one of the two assertions and may be invalid.

All the best, Ashok
Received on Thursday, 11 January 2007 22:40:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:45 GMT