OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Suggested Feedback to WS-Policy


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]