W3C home > Mailing lists > Public > public-ws-policy@w3.org > May 2007

Re: policy vocabulary, will not be applied, oh my!

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:34 UTC