- From: Christopher B Ferris <chrisfer@us.ibm.com>
- Date: Thu, 3 May 2007 18:28:55 -0400
- To: "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: <OF6901A01A.4BA892AE-ON852572D0.00799539-852572D0.007B669D@us.ibm.com>
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
Received on Thursday, 3 May 2007 22:29:07 UTC