[Bug 4236] personal comment not a comment from the WS-RX TC

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4236

           Summary: personal comment not a comment from the WS-RX TC
           Product: WS-Policy
           Version: LC
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Framework
        AssignedTo: fsasaki@w3.org
        ReportedBy: chrisfer@us.ibm.com
         QAContact: public-ws-policy-qa@w3.org


http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0077.html

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 Tuesday, 16 January 2007 21:45:13 UTC