Review of WS-Policy Last Call Documents

["Ashok Malhotra" <ashok.malhotra@oracle.com>]

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