[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] NEW ISSUE: Policy Assertions Must be Independent
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 >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]