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