RE: [ws-rx] NEW ISSUE: Policy Assertions Must be Independent

["Patil, Sanjay" <sanjay.patil@sap.com>]

Ashok (or any other volunteers), would it be possible to submit a formal
proposal on this issue in advance of this week's conf-call (1/18)?

-- Sanjay
 

>-----Original Message-----
>From: Ashok Malhotra [mailto:ashok.malhotra@oracle.com] 
>Sent: Friday, Jan 05, 2007 6:18 AM
>To: ws-rx@lists.oasis-open.org
>Subject: [ws-rx] NEW ISSUE: Policy Assertions Must be Independent 
>
>In my original note (below) I pointed out that RM Policy had 
>three 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.
>
>These dependencies lead to a problem with WS-Policy 
>normalization if, say, you have a policy containing only 
>assertions 1 and 2 and both are marked 'optional'.  Such a 
>policy would normalize to 4 policy alternatives { (1,2), (1), 
>(2), () }  One of the policy alternatives would contain 
>assertion 2 and not assertion 1 which is invalid.
>
>PROPOSAL:
>Make assertions 2 and 3 possible nested elements of assertion 1.
>For example:
>
><wsrmp:RMAssertion [wsp:Optional="true"]? ... >
>    <wsp:Policy>
>	 <wsrmp:SequenceSTR [wsp:Optional="true"]? ... />	
>    </wsp:Policy>
></wsrmp:RMAssertion> 
>
>(Only either 2 or 3 must appear in the nested policy?)
>
>This does not solve the problem of assertion 3 depending on 
>sp:TransportBinding but, at least, solves part of the problem.
>
>All the best, Ashok
>
>> -----Original Message-----
>> From: Ashok Malhotra [mailto:ashok.malhotra@oracle.com]
>> Sent: Wednesday, January 03, 2007 12:33 PM
>> To: ws-rx@lists.oasis-open.org
>> Subject: [ws-rx] Review of WS-Policy Last Call Documents
>> 
>> Sanjay asked for volunteers to review the WS-Policy Last 
>Call documents.
>> I interpreted this to mean "does WS-RX Policy work in the 
>context of WS-
>> Policy as embodied in the Last Call documents".
>> If this was not the intention, my apologies, and we can try again.
>> 
>> So, I reread the WS-RX Policy Documents.  Here is what I learned.
>> 
>> The WS-RX Policy document defines 3 assertions.
>> 
>> The first assertion is whether Reliable Messaging is used or not.
>> <wsrmp:RMAssertion [wsp:Optional="true"]? ... >
>> 
>> Somewhat to my surprise, this assertion says nothing about delivery
>> assurances.
>> In my view, applications may want to specify whether they 
>want duplicates
>> removed from a sequence or they
>> want the messages ordered.  So this assertion seems underspecified.
>> 
>> The second and third assertions are about security considerations.
>> 
>> The second assertion is
>> <wsrmp:SequenceSTR [wsp:Optional="true"]? ... />
>> 
>> This says that an RM Sequence MUST be bound to an explicit 
>token that is
>> referenced from a
>> wsse:SecurityTokenReference in the CreateSequence message.
>> 
>> This assertion is, in fact dependent on the RM assertion and 
>cannot be
>> used unless the RM assertion is present.
>> 
>> The third assertion is
>> <wsrmp:SequenceTransportSecurity [wsp:Optional="true"]? ... />
>> This assertion defines the requirement that an RM Sequence 
>MUST be bound
>> to the session(s) of the underlying transport-level security protocol
>> (e.g. SSL/TLS) used to carry the CreateSequence and 
>CreateSequenceResponse
>> messages.
>> Further, this assertion must occur in conjunction with the 
>RMAssertion and
>> a sp:TransportBinding assertion that requires the use of 
>some transport-
>> level security mechanism (e.g. sp:HttpsToken).
>> 
>> Thus, this assertion is dependent on two other assertions.
>> 
>> WS-Policy says in section 3.1 "A policy assertion represents 
>an individual
>> requirement, capability, or other property of a behavior".
>> But, as we have seen, two of the assertions cannot stand 
>independently.
>> 
>> Consider the situation where a policy contains the first and second
>> assertion, both marked 'optional'.
>> When such a policy is normalized, we get four policy 
>alternatives.  One of
>> these alternatives will contain the second assertion and not 
>the first.
>> This is clearly an error.
>> 
>> Thus, I think some change to the WS-Policy wording may be desirable.
>> 
>> We should also think about whether we can fix this problem 
>on our own.
>> Clearly, the second assertion can be limited to appear only 
>as a nested
>> assertion for the first assertion.
>> This would solve the situation wrt the second assertion.
>> 
>> But what about the third assertion?  This requires the first 
>assertion as
>> well as the sp:TransportBinding assertion.  So should we make both
>> the first and third assertions nested assertions of 
>sp:TransportBinding?
>> But that's not something we can do.  We don't own that domain.
>> 
>> All the best, Ashok
>> 
>
>