- From: William Henry <william.henry@iona.com>
- Date: Thu, 03 May 2007 16:52:46 -0600
- To: Christopher B Ferris <chrisfer@us.ibm.com>, David Orchard <dorchard@bea.com>
- CC: <public-ws-policy@w3.org>, <public-ws-policy-request@w3.org>, Sergey Beryozkin <sergey.beryozkin@iona.com>
- Message-ID: <C25FC3DE.5F6A%william.henry@iona.com>
I guess Iım confused/split on this: One could argue that if the consumer specifically specifies a policy then why would the intersection give him ³more². I.e. Consumer looking for TransportSecurity and the intersection yields just the ³yes you can have that² rather than ³yes you can have that but I just thought Iıd let you know what you canıt have². I mean why complicate the ³sale²? Using your (Chrisıs) language below it would go something like this: Consumer (A): I want TransportSecurity Provider (B): (after intersection) I can give you TransportSecurity but if you use RM then you better use MessageSecurity. A: Huh? So I can use TransportSecurity right? B: Yep, but you better not use it if youıre using RM , you can only use MessageSecurity with that? A: Why are you talking about RM? All I asked about was TransportSecurity? Iım confused. :-) I guess my point is why confuse the situation? Consumer wants a particular policy and if the intersection satisfies it then why bother expanding the vocabulary to what wasnıt asked for? If I asked for TransportSecurity then presumably Iım not going to send MessageSecurty messages that can only be used with RM. IF I send TransportSecurity messages and they fail then surely the provider left something out of the policy that Iım missing. On other hand perhaps it is a useful ³sales² tool: After the intersection A knows that the service satisfies the Policy TransportSecurity and, btw, it may may also be interested that the provider provides RM with MessageSecurity. But I think Iıd err on not confusing the situation (intersection). They can always look at the WSDL to see what is ³advertised². Of course Iım not as deep into this stuff and might be completely missing the plot! ;-) Regards, William On 5/3/07 4:28 PM, "Christopher B Ferris" <chrisfer@us.ibm.com> wrote: > > You are right, it WAS early:-) > > My point is, though is that in the case I described, it was important that the > policy be interpreted as > "don't do MessageSecurity" in the case that did not use RM. > > Let us say for a moment that the endpoint supports WS-Security (which has both > message > and transport-level security defined). > > If you interpret the intersected policy in terms of the policy vocabulary > definition we currently > have, then the intersected policy expression explicitly says NOTHING about > whether or not > MessageSecurity might be applied in the context of an interaction with the > provider. > > YET, the provider's intended interpretation of ITS policy was: IFF you do RM, > use MessageSecurity > and NOT TransportSecurity. Otherwise, use TransportSecurity ONLY. > > That is not what the intersected policy says in light of the definition for > policy vocabulary we have > today, and the definiton for AIN we currently have in the specification. > > Removing policy vocabulary alone is insufficient to yield a consistent > interpretation of > a policy alternative pre and post intersection. > > What I have proposed is that we have a consistent interpretation of the > absence of > an assertion from an alternative such that the same semantic understanding is > available > whether the pre-intersection or post-intersection policy is examined. > > In your response, you indicate that the client was being untruthful in its > advertised policy > (because it made no mention of RM). In my example, I was (apparently, not > clearly due to the > early hour and lack of caffine) trying to provide an example in which the > support was there > (as I mentioned, for WS-Security), simply not expressed in the policy. > > I could provide another example of the client policy that maybe addresses your > point. > > <Policy> > <ExactlyOne> > <All> > <TransportSecurity/> > </All> > <All> > <TransportSecurity/> > <MessageSecurity/> > </All> > </ExactlyOne> > </Policy> > > Now do the intersection. Does the result say "don't use MessageSecurity"? > > <Policy> > <ExactlyOne> > <All> > <TransportSecurity/> > </All> > </ExactlyOne> > </Policy> > > Nope. If we leave the interpretation as: the policy implies the behaviors > represented by the > assertions present in the alternative, and says nothing about that which is > not expressed, then > frankly, I don't see why it might not be considered valid to send a message > secured by both > transport and message level security mechanisms. > > Cheers, > > Christopher Ferris > STSM, Software Group Standards Strategy > email: chrisfer@us.ibm.com > blog: http://www.ibm.com/developerworks/blogs/page/chrisferris > phone: +1 508 377 9295 > > "David Orchard" <dorchard@bea.com> wrote on 05/03/2007 01:37:39 PM: > >> > I'm not sure about the snippy start to the response to a call for >> > real-world use case(s) to justify a feature. I do insist on real- >> > world rather than theoritical/ivory tower abstractions. But I see >> > it's 6:48 AM on your mesage so maybe the coffee hasn't kicked in >> > yet, and the coffee definitely hasn't kicked in on my end :-) >> > >> > Focusing on the most excellent real-world scenario you've >> > provided... I was with you right until you didn't finish >> > connecting the dots but instead played the "customers want this" >> > card and then the crosswalk tangent. Let's stick to just the RM facts. >> > >> > If the client knows about RM and does not provide an alternative >> > that says it can do RM, and then it tries to do RM, then it's >> > basically lying about it's alternatives. A more accurate >> > representation of what the client can do is say that it can do RM >> > and TransportSecurity. Perhaps: >> > >> > <Policy> >> > <All> >> > <RMAssertion/> >> > <TransportSecurity/> >> > </All> >> > </Policy> >> > Then I think we still get the same intersected policy. I think >> > it's important to also note that client might have a gajillion other >> > policy assertions that it could apply. >> > >> > So the client sees this intersected policy, knows that it must do >> > transport security. It still knows it can do RM or not. If it >> > decides to do RM, it gets an error. If it doesn't, things work >> > fine. I would suggest that a reasonable client behaviour is to only >> > apply the assertions that are a result of intersection. >> > >> > Let's look at AIN and NOT AIN to evaluate the client's behaviour: >> > AIN: Client knows about RM and knows that RM wasn't in the >> > intersection so it SHOULDN'T do it. It does know transport >> > security was in so it MUST do it. I think almost every client will >> > do TS and not do RM. >> > NOT AIN: Client knows about RM and doesn't know if RM was in the >> > intersection or not. It does know transport security was in so it >> > MUST do it. I think almost every client will do TS and not do RM. >> > >> > I still don't see under AIN or NOT AIN how the client behaviour is >> > any different. I think that a client that only applies the >> > intersection results is the only reasonable client behaviour, >> > especially as the scale of the assertions grows. >> > >> > Now maybe where there is a source of confusion is that I think the >> > client will have a whole bunch of behaviours that it "knows" about, >> > regardless of the intersection result. Therefore, the intersection >> > result does not have to be the complete "state" picture of the >> > clients capabilities, such as it can do RM but it wasn't in the >> > intersection. It will probably match it's behaviours with the >> > intersection result, and then just fire those behaviours that are in >> > the intersection. I don't think it will go through all it's >> > behaviours and apply any or all of the behaviours that "might" be possible. >> > >> > Cheers, >> > Dave >> > >> > From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] >> > Sent: Thursday, May 03, 2007 6:48 AM >> > To: David Orchard >> > Cc: public-ws-policy@w3.org; public-ws-policy-request@w3.org; >> SergeyBeryozkin >> > Subject: RE: policy vocabulary, will not be applied, oh my! > >> > >> > It isn't clear to me why A and B are not good enough for an explanation. >> > >> > However, if you insist. >> > >> > Consider that an endpoint publishes a policy that has two alternatives. >> > >> > <Policy> >> > <ExactlyOne> >> > <All> >> > <RMAssertion/> >> > <MessageSecurity/> <!-- I am making this up because the real >> > secpol expression would take up an entire page and not add anything >> > meaningful to >> > the discussion --> >> > </All> >> > <All> >> > <TransportSecurity/> >> > </All> >> > </ExactlyOne> >> > </Policy> >> > >> > Now consider a client policy >> > >> > <Policy> >> > <ExactlyOne> >> > <All> >> > <TransportSecurity/> >> > </All> >> > </ExactlyOne> >> > </Policy> >> > >> > Intersection would yield: >> > >> > <Policy> >> > <ExactlyOne> >> > <All> >> > <TransportSecurity/> >> > </All> >> > </ExactlyOne> >> > </Policy> >> > >> > Question: given the current definitions for policy vocabulary, etc. >> > what does the intersected policy >> > say? >> > >> > Well, using the definition of policy vocabulary, the vocabulary of >> > the intersected policy is <TransportSecurity> >> > >> > What was the service provider saying? >> > >> > The policy vocabulary of the provier's policy was: >> > <RMAssertion> >> > <MessageSecurity> >> > <TransportSecurity> >> > >> > I read the provider policy to be saying: >> > >> > IFF you use RM, you MUST use MessageSecurity and NOT TransportSecurity >> > IFF you do not use RM, you MUST use TransportSecurity and NOT >> > MessageSecurity (and btw, NOT RM) >> > >> > However, what the intersected policy says to me (using the current >> > definitions) is: >> > >> > Use TransportSecurity. >> > >> > Note that it does not say anything about RM or MessageSecurity. >> > >> > Given the current definitions, since nothing is said about these, >> > they COULD be applied >> > by the client. Of course, they might be surprised by the result. The >> > point is, though, that >> > the resulting policy expression says nothing about RM or MessageSecurity. >> > >> > We have customer requirements that want this to be interpretted as >> > the provider's >> > policy expressed. They don't want it to be left unsaid. >> > >> > Now, some might argue that if the intersected policy says only >> > TransportSecurity >> > that that would be all that would be applied (why would you do >> MessageSecurity >> > if the policy didn't include it?) >> > >> > I maintain that that is not enough. We have laws that say: >> > >> > Don't jaywalk >> > >> > We don't have laws that say: >> > >> > Cross at the crosswalk >> > >> > this is because "cross at the crosswalk" doesn't say anything about >> > running out into traffic. >> > >> > Cheers, >> > >> > Christopher Ferris >> > STSM, Software Group Standards Strategy >> > email: chrisfer@us.ibm.com >> > blog: http://www.ibm.com/developerworks/blogs/page/chrisferris >> > phone: +1 508 377 9295 >> > >> > public-ws-policy-request@w3.org wrote on 05/02/2007 12:12:00 PM: >> > >>> > > Sergey, the use case that you are asking for is exactly the use case >>> > > that I'm asking for. I'm becoming convinced that there isn't such a >>> > > use case because nobody has been able to mention one in the past week or so. >>> > > >>> > > Cheers, >>> > > Dave >>> > > >>> > > From: public-ws-policy-request@w3.org [mailto:public-ws-policy- >>> > > request@w3.org] On Behalf Of Sergey Beryozkin >>> > > Sent: Wednesday, May 02, 2007 2:19 AM >>> > > To: public-ws-policy@w3.org; Christopher B Ferris >>> > > Subject: Re: policy vocabulary, will not be applied, oh my! >> > >>> > > Hi Chris >>> > > >>> > > Would it be possible to post an example which would show a realistic >>> > > scenario where it's obvious the fact that the input policy >>> > > vocabulary is not included in the effective policy's vocabulary may >>> > > cause the problems for a client ? I just find it difficult to >>> > > understand the reasoning when policies A&B are used in examples :-) >>> > > >>> > > Also, I don't understand why the client can not use the effective >>> > > policy's vocabulary as the guidance on what assertions can be >>> > > applied. The fact that many more assertions might've been involved >>> > > in the intersection seems unimportant to me, the client can not >>> > > apply what the effective policy has now, that is whatever assertions >>> > > are in the selected alternative. I think this is what Monica said in >>> > > the other email (sorry if misinterpreted that email reply). >>> > > >>> > > I hope the practical example will help to understand the problem better >>> > > >>> > > Thanks, Sergey >>> > > ----- Original Message ----- >>> > > From: Christopher B Ferris >>> > > To: public-ws-policy@w3.org >>> > > Sent: Tuesday, May 01, 2007 9:22 PM >>> > > Subject: policy vocabulary, will not be applied, oh my! >>> > > >>> > > >>> > > There are some related issues/questions/concerns that have been >>> > > expressed by members >>> > > of the WG with regards the framework specification as it relates to >>> > > the "will not be applied" principle >>> > > and the definions for "policy vocabulary", etc. Below, I have >>> > > enumerated these issues >>> > > and suggest a path forward to address those concerns. >>> > > >>> > > 1. The definition of "policy vocabulary" is incompatible with >>> > > intersected policy as regards to >>> > > the "will not be applied" principle because post intersection, the >>> > > resultant policy expression >>> > > does not carry the policy vocabulary of the input policy >>> > > expressions. Hence, if a provider >>> > > had two alternatives, one with Foo and one without Foo, and the >>> > > result of intersection determined >>> > > that the alternative without Foo was compatible with a client's >>> > > policy, then the resultant >>> > > policy expression would not have in its vocabulary (as computed >>> > > using the algorithim >>> > > currently specified) Foo and hence it would not be clear whether Foo >>> > > carries with it >>> > > the "will not be applied" semantic. >>> > > >>> > > Action-283 - http://lists.w3.org/Archives/Public/public-ws- >>> > > policy/2007Apr/0103.html >>> > > Action-284 - http://lists.w3.org/Archives/Public/public-ws- >>> > > policy/2007Apr/0106.html >>> > > Ashok email - http://lists.w3.org/Archives/Public/public-ws- >>> > > policy/2007Apr/0065.html >>> > > >>> > > 2. There is a degree of confusion regarding the "will not be >>> > > applied" semantic as it applies to nested policy. >>> > > This is related to the interpretation of "policy vocabulary" that >>> > > many held prior to the clarification provided by >>> > > Microsoft >>> > > >>> > > Asir's email on nested policy vocabulary - http://lists.w3. >>> > > org/Archives/Public/public-ws-policy/2007Apr/0017.html >>> > > >>> > > 3. As a result, a number of email threads have sprung up that >>> > > question the merits of the "will not be applied" >>> > > semantic. >>> > > >>> > > Ashok - http://lists.w3.org/Archives/Public/public-ws- >> > policy/2007Apr/0065.html >>> > > Dale - http://lists.w3.org/Archives/Public/public-ws- >> > policy/2007Apr/0075.html >>> > > Ashok - http://lists.w3.org/Archives/Public/public-ws- >> > policy/2007Apr/0101.html >>> > > Dale - http://lists.w3.org/Archives/Public/public-ws- >> > policy/2007Apr/0108.html >>> > > >>> > > It may be that the most prudent course forward would be to drop the >>> > > "will not be applied" semantic as relates >>> > > policy vocabulary. As a result, there is little need of a normative >>> > > definion for policy vocabulary or policy alternative >>> > > vocabulary, as these definitions only served to allow one to >>> > > determine whether the behavior implied by a >>> > > given assertion carried the "will not be applied" semantic. >>> > > >>> > > Instead, we could simply state that the behavior implied by an >>> > > assertion that is absent from a given alternative >>> > > is not to be applied in the context of the attached policy subject >>> > > when that alternative is engaged. >>> > > This would provide clearer semantic (I believe) to borth assertion >>> > > and policy authors. >>> > > >>> > > The attached mark-up of the policy framework specification contains >>> > > the changes that I believe would >>> > > be necessary to affect this change. >>> > > >>> > > Impact analysis: >>> > > >>> > > - The proposed change does not affect the XML syntax >>> > > - Nor does it impact the semantics of the namespace, therefore the >>> > > namesapce URI can remain unchanged >>> > > - It does not affect the processing model (normalization, intersection) >>> > > - It does not impact testing results to date >>> > > - It does not affect any of the assertion languages developed to date >>> > > >>> > > The related questsion that needs to be asked should we choose to >>> > > adopt this proposal is: >>> > > >>> > > Does this change affect any implementations? >>> > > >>> > > From analysis of the set of test cases, the answer is not clear, >>> > > because there were no tests that >>> > > excercised either policy vocabulary or the "will not be applied" >>> > > semantic. Thus, it would be important that >>> > > we check our respective implementations to ascertain whether there >>> > > would be any impact. From an IBM >>> > > perspective, this change does not impact our implementation. >>> > > >>> > > >>> > > >>> > > Cheers, >>> > > >>> > > Christopher Ferris >>> > > STSM, Software Group Standards Strategy >>> > > email: chrisfer@us.ibm.com >>> > > blog: http://www.ibm.com/developerworks/blogs/page/chrisferris >>> > > phone: +1 508 377 9295 -- William G Henry Alliances Technology Director, Enterprise Architect Phone: +1 719 302 2302 Mobile: +1 719 640 6868 WWW: http://www.iona.com Blog: http://www.ipbabble.com
Received on Thursday, 3 May 2007 22:53:02 UTC