[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ISSUE 37: Policy Assertions Must be Independent
Issue 37 -----Original Message----- From: Ashok Malhotra [mailto:ashok.malhotra@oracle.com] Sent: Friday, January 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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]