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: [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
> 



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