Re: Suggested Feedback to WS-Policy

should these be filed as two issues?

regards, Frederick

Frederick Hirsch
Nokia


On Jan 11, 2007, at 5:38 PM, ext Ashok Malhotra wrote:

>
> 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 00:23:44 UTC