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

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

From: Fabian Ritzmann <Fabian.Ritzmann@Sun.COM>
Date: Fri, 04 May 2007 15:41:44 +0300
To: William Henry <william.henry@iona.com>
Cc: Christopher B Ferris <chrisfer@us.ibm.com>, David Orchard <dorchard@bea.com>, public-ws-policy@w3.org, public-ws-policy-request@w3.org, Sergey Beryozkin <sergey.beryozkin@iona.com>, Monica Martin <Monica.Martin@Sun.COM>
Message-id: <463B2A08.2000202@Sun.COM>

I believe I'm with William on this. The client has this policy:

<Policy>
<ExactlyOne>
<All>
<TransportSecurity/>
</All>
</ExactlyOne>
</Policy>

It runs the first approximation of an intersection algorithm and 
establishes that the <TransportSecurity/> alternative is compatible with 
the server policy. Now it starts applying that policy alternative. I 
don't think it is desirable to force the client to consider the server 
policy at this point when it already knows it has a compatible policy 
alternative.

Fabian


William Henry wrote:
> 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]
>     <mailto:chrisfer@us.ibm.com%5D>
>     > 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
>
Received on Friday, 4 May 2007 12:41:56 UTC

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