- From: David Orchard <dorchard@bea.com>
- Date: Thu, 3 May 2007 10:37:39 -0700
- To: "Christopher B Ferris" <chrisfer@us.ibm.com>
- Cc: <public-ws-policy@w3.org>, <public-ws-policy-request@w3.org>, "Sergey Beryozkin" <sergey.beryozkin@iona.com>
- Message-ID: <E16EB59B8AEDF445B644617E3C1B3C9C03A8B9AF@repbex01.amer.bea.com>
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;
Sergey Beryozkin
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 17:38:18 UTC