This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 4236 - personal comment not a comment from the WS-RX TC
Summary: personal comment not a comment from the WS-RX TC
Status: RESOLVED FIXED
Alias: None
Product: WS-Policy
Classification: Unclassified
Component: Framework (show other bugs)
Version: LC
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Felix Sasaki
QA Contact: Web Services Policy WG QA List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-16 21:45 UTC by Christopher Ferris
Modified: 2007-01-16 21:47 UTC (History)
0 users

See Also:


Attachments

Description Christopher Ferris 2007-01-16 21:45:03 UTC
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
Comment 1 Christopher Ferris 2007-01-16 21:47:34 UTC
See http://www.w3.org/2007/01/16-ws-policy-irc#T21-43-11
http://www.w3.org/Bugs/Public/show_bug.cgi?id=4236
RESOLUTION: 4236 is closed with removal of Individual from definition of policy assertion in 3.1 and addition of Note to section 3.2 "Note: Depending on the semantics of the domain specific policy assertions a combination of these policy assertions can be required to specify a particular behavior.