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

David Orchard wrote:
> 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.

AIN allows to formulate an IFF statement like Chris did. NOT AIN does 
not allow you to do that, since the MUST NOT part could contain anything.

> 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.

it seems to me the important difference is between "reasonable" and 
"predictable". you can't translate "reasonable client behavior" to the 
"IFF" statement.

>  
> 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.

it seems to me that you can clearly decide what is possible, and Chris 
did demonstrate that by the IFF statements.

Regards, Felix.

>  
> 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 21:46:57 UTC