- From: David Orchard <dorchard@bea.com>
- Date: Thu, 3 May 2007 16:33:00 -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: <E16EB59B8AEDF445B644617E3C1B3C9C03AEBD22@repbex01.amer.bea.com>
drat, I still don't get it. Maybe getting too late? :-)
So the client CAN do transport and message security and RM in any
combination. I'm not sure if you are suggesting the client won't do
*just* messageSecurity, that it always requires transport security.
Let's assume it will and we can iterate if my assumption is wrong. I
think that ought to be a policy like:
<Policy>
<ExactlyOne>
<All>
<TransportSecurity/>
</All>
<All>
<TransportSecurity/>
<MessageSecurity/>
</All>
<All>
<MessageSecurity/>
</All>
<All>
<RMAssertion/>
<TransportSecurity/>
</All>
<All>
<RMAssertion/>
<TransportSecurity/>
<MessageSecurity/>
</All>
<All>
<RMAssertion/>
<MessageSecurity/>
</All>
</ExactlyOne>
</Policy>
And wouldn't the intersection result then exactly the service's policy,
that is:
<Policy>
<ExactlyOne>
<All>
<RMAssertion/>
<MessageSecurity/>
</All>
<All>
<TransportSecurity/>
</All>
</ExactlyOne>
</Policy>
And voila, it knows exactly what it needs to do because it will pick
one. It will NOT do MessageSecurity and TransportSecurity because it
doesn't have an alternative that lists that. Again, this has the
assumption that the client doesn't apply behaviours it knows about when
they are not in the intersection result, but you could live without AIN
by saying such behaviour is undefined and "don't hit yourself with a
pointy stick".
Maybe it's good we're going to have a f2f soon...
Cheers,
Dave
________________________________
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Thursday, May 03, 2007 3:29 PM
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!
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 23:33:46 UTC