RE: proposal for ACTION 181

+1, great convergence!

 

Regards,

 

Asir S Vedamuthu

Microsoft Corporation

 

 

From: Maryann Hondo [mailto:mhondo@us.ibm.com] 
Sent: Monday, January 15, 2007 6:41 PM
To: Yalcinalp, Umit
Cc: Asir Vedamuthu; public-ws-policy@w3.org; public-ws-policy-request@w3.org
Subject: proposal for ACTION 181

 


Taking into consideration the various exchanges, 
Umit and I would like to suggest this proposal for consideration..... 

In the spec make the following changes: 

The following describes additional processing constraints on the outline listed above: 
/Assertion/wsp:Policy 
This indicates that the assertion contains a nested policy expression. If there is no wsp:Policy Element Information Item in the [children] property, the assertion has no nested policy expression. 
Note: if the schema outline for an assertion type requires a nested policy expression but the assertion does not further qualify one or more aspects of the behavior indicated by the assertion type (i.e., no assertions are needed in the nested policy expression), the assertion MUST include an empty <wsp:Policy/> Element Information Item in its [children] property; as explained in Section 4.3.3 Policy Operators <http://www.w3.org/TR/2006/WD-ws-policy-20061117/#Policy_Operators> , this is equivalent to a nested policy expression with a single alternative that has zero assertions. The reason for requiring at least an empty <wsp:Policy/> Element above is to ensure that two assertions of the same type will always be compatible and an intersection would not fail (see Section 4.5 Policy Intersection <http://www.w3.org/TR/2006/WD-ws-policy-20061117/#Policy_Intersection> ). 
Note: This specification does not define processing for arbitrary wsp:Policy Element Information Items in the descendants of an assertion parameter, e.g., in the [children] property of one of the [children] as in <Lorem><Ipsum><wsp:Policy> … </wsp:Policy></Ipsum></Lorem>. 

In the Primer & Guidelines add an example (i.e. ws-addressing) with more detail illustrating how/why nesting policy is used  and why its important for the assertion designers ( i.e. security) to have their schema require a nested policy assertion this so that intersection will result in the 
behaviors they expect. 

Maryann & Umit 




"Yalcinalp, Umit" <umit.yalcinalp@sap.com> 
Sent by: public-ws-policy-request@w3.org 

01/15/2007 01:01 AM 

To

"Asir Vedamuthu" <asirveda@microsoft.com> 

cc

<public-ws-policy@w3.org> 

Subject

RE: NEW ISSUE: 4142 Contradictory recommendation for nesting and intersection

 

  




I am waiting to see whether the other working group members all agree on the semantics that you are supposing. 
  
As I said, once we have agreement in the semantics, the fix is easy. 
  
Regards, 
  
--umit 
  

________________________________

From: Asir Vedamuthu [mailto:asirveda@microsoft.com] 
Sent: Saturday, Jan 13, 2007 2:02 AM
To: Yalcinalp, Umit
Cc: public-ws-policy@w3.org
Subject: RE: NEW ISSUE: 4142 Contradictory recommendation for nesting and intersection

Answer is NO – as per the policy intersection algorithm in Section 4.5 [1]. We agree that the quoted sentence [2] in Section 4.3.2 is misleading. There is an easy fix – drop the sentence. 
  
Regarding ACTION-181 [3], when should we expect your amended proposal? 
  
  
[1] http://www.w3.org/TR/2006/WD-ws-policy-20061117/#Policy_Intersection <http://www.w3.org/TR/2006/WD-ws-policy-20061117/#Policy_Intersection>  
  
[2] “The reason for requiring at least an empty <wsp:Policy/> Element above is to ensure that two assertions of the same type will always be compatible and an intersection would not fail (see Section 4.5 Policy Intersection)” 
  
[3] http://www.w3.org/2005/06/tracker/wspolicy/actions/181 <http://www.w3.org/2005/06/tracker/wspolicy/actions/181>  
  
Regards, 
  
Asir S Vedamuthu 
Microsoft Corporation 
  
  
From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Yalcinalp, Umit
Sent: Wednesday, January 10, 2007 12:11 PM
To: Sergey Beryozkin; Anthony Nadalin
Cc: public-ws-policy@w3.org; public-ws-policy-request@w3.org
Subject: RE: NEW ISSUE: Contradictory recommendation for nesting and intersection 
  
The question is about the semantics. In the example, ex:Foo is NOT a policy parameter. It is a nested assertion. Let me paraphrase for more clarity. 
  
Is 
  
<ex:MyAssertion> 
     <wsp:Policy> 
           <ex:NestedAssertion> 
    </wsp:Policy> 
</ex:MyAssertion> 
  
compatible with 
  
<ex:MyAssertion> 
     <wsp:Policy/> 
</ex:MyAssertion> 
  
? 
  
(a) No 
(b) Yes 
  
Depending on your answer, the fix in the document is different. Fix is secondary to what the wg members think the semantics is. 
  
Given that our WGs, such as WS-Addressing have been looking into using nested assertions as well, this needs to be well aligned, agreed. 
  
--umit 
  
  
  

 

________________________________


From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com] 
Sent: Wednesday, Jan 10, 2007 3:34 AM
To: Anthony Nadalin
Cc: public-ws-policy@w3.org; public-ws-policy-request@w3.org; Yalcinalp, Umit
Subject: Re: NEW ISSUE: Contradictory recommendation for nesting and intersection 
Hi 
  
Thanks for the explanation about the parameters. I think I just got it wrong. In the Umit's example I thought ex:Foo was a parameter, but it's actually a policy assertion in that example...so I reckon option1 would still be the right approach to follow.... 
  
Cheers, Sergey 
----- Original Message ----- 
From: Anthony Nadalin <mailto:drsecure@us.ibm.com>  
To: Sergey Beryozkin <mailto:sergey.beryozkin@iona.com>  
Cc: public-ws-policy@w3.org <mailto:public-ws-policy@w3.org>  ; public-ws-policy-request@w3.org <mailto:public-ws-policy-request@w3.org>  ; Yalcinalp, Umit <mailto:umit.yalcinalp@sap.com>  
Sent: Tuesday, January 09, 2007 5:07 PM 
Subject: Re: NEW ISSUE: Contradictory recommendation for nesting and intersection 
  

The ex:Foo parameter is a domain specific processing item, not evaluated at the framework level, thus I would consider the assertions in your example the same. This is the understanding we have with Security Policy assertions. 

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
 "Sergey Beryozkin" <sergey.beryozkin@iona.com> 

"Sergey Beryozkin" <sergey.beryozkin@iona.com <mailto:sergey.beryozkin@iona.com> > 
Sent by: public-ws-policy-request@w3.org <mailto:public-ws-policy-request@w3.org>  

01/03/2007 12:28 PM 

 


To


"Yalcinalp, Umit" <umit.yalcinalp@sap.com <mailto:umit.yalcinalp@sap.com> >, <public-ws-policy@w3.org <mailto:public-ws-policy@w3.org> > 


cc

 

Subject


Re: NEW ISSUE: Contradictory recommendation for nesting and intersection


  

 

  


Hi

" 

(a) The statement in 4.3.2 quoted is in error. Including a nested empty policy expression allows the compatibility testing to occur, but does NOT guarantee the same types to be compatible for intersection (which is implied by the intersection algorithm). Using this logic, expressions 1 and 2 are not compatible as the intersection algorithm suggests. " 

seems like the right solution, as in 

"The alternative in (1) is <wsp:Policy> <ex:Foo/></wsp:Policy>. The alternative in (2) is <wsp:Policy/>." 

(1) is more specialized than (2), has ex:Foo policy parameter, hence they're different 

Cheers, Sergey 

----- Original Message ----- 
From: Yalcinalp, Umit <mailto:umit.yalcinalp@sap.com>  
To: public-ws-policy@w3.org <mailto:public-ws-policy@w3.org>  
Sent: Wednesday, January 03, 2007 1:56 AM
Subject: NEW ISSUE: Contradictory recommendation for nesting and intersection 

Title: Contradictory recommendation for nesting and intersection 

Description: The specification provides some guidance about when to include an empty policy element. Section 4.3.2, Assertion/Policy element states: 

{Note: if the schema outline for an assertion type requires a nested policy expression but the assertion does not further qualify one or more aspects of the behavior indicated by the assertion type (i.e., no assertions are needed in the nested policy expression), the assertion MUST include an empty <wsp:Policy/> Element Information Item in its [children] property; as explained in Section 4.3.3 Policy Operators, this is equivalent to a nested policy expression with a single alternative that has zero assertions. The reason for requiring at least an empty <wsp:Policy/> Element above is to ensure that two assertions of the same type will always be compatible and an intersection would not fail (see Section 4.5 Policy Intersection). 

} 
The paragraph stated imply two different and somewhat contradictory advice. 
(a) A nested assertion by definition (via schema) should always expressed using nesting, even if the nesting yields zero assertions in a single alternative. (This is per the first statement) 

(b) Two assertions that have the same nesting will always be compatible REGARDLESS of whether they have different nested elements inside. (This is inferred from the last statement). 

While the first statement is intuitive, the second recommendation (b) is counter indicative per the intersection algorithm and thus requires either changing or clarification. This is due to the unclarity of the intersection algorithm. Consider the following two policy expressions: 

(1) 
<wsp:Policy> 
<wsp:ExactlyOne> 
<wsp:All> 
<ex:NestedAssertion> 
<wsp:Policy> 
<ex:Foo/> 
</wsp:Policy> 
</ex:NestedAssertion> 
</wsp:All> 
</wsp:ExactlyOne> 
</wsp:Policy> 
(2) 
<wsp:Policy> 
<wsp:ExactlyOne> 
<wsp:All> 
<ex:NestedAssertion> 
<wsp:Policy/> 
</ex:NestedAssertion> 
</wsp:All> 
</wsp:ExactlyOne> 
</wsp:Policy> 
According to the statement above, these assertions are expected to be "compatible" but the intersection algorithm in Section 4.5 does not confirm this expectation: 

{If either assertion contains a nested policy expression, the two assertions are compatible if they both have a nested policy expression and the alternative in the nested policy expression of one is compatible with the alternative in the nested policy expression of the other. } 

According to the previous statement, the nested expressions in (1) and (2) are NOT compatible assertions, either in strict or lax mode because of the definition of the compatibity of the alternatives are governed by the following. (Lets consider strict mode for simplicity) 

{If the mode is strict, two policy alternatives A and B are compatible: 

* if each assertion in A is compatible with an assertion in B, and 
* if each assertion in B is compatible with an assertion in A.} 

The alternative in (1) is <wsp:Policy> <ex:Foo/></wsp:Policy>. The alternative in (2) is <wsp:Policy/>. According to the compatibility definition, these two alternatives are not compatible as there is no nested ex:Foo element within the second alternative for (2). 

Therefore, including a nested policy expression WILL STILL FAIL the intersection algorithm in contradiction to the statement: 

{The reason for requiring at least an empty <wsp:Policy/> Element above is to ensure that two assertions of the same type will always be compatible and an intersection would not fail (see Section 4.5 Policy Intersection). } 

Thus the specification is in conflict with itself and this should be resolved. See proposal section for two alternative ways of fixing this. 

Target: Framework, Primer 

Justification: The specification is contradictory with itself. It does not explain the utility of nesting and empty policy expression well. The clarification should be included in the framework as well as the primer since it was deemed necessary for an explanation in the framework document itself for further clarification in the first place. Readers who are not familiar with the nesting will definitely get this wrong, especially there is contradictory statements in the specification. 

Proposal: 
There are two ways to interpret this conflict as there are two possible ways forward depending on the intent of the specification: 

(a) The statement in 4.3.2 quoted is in error. Including a nested empty policy expression allows the compatibility testing to occur, but does NOT guarantee the same types to be compatible for intersection (which is implied by the intersection algorithm). Using this logic, expressions 1 and 2 are not compatible as the intersection algorithm suggests. 

This requires fixing the last sentence in the quoted paragraph in Section 4.3.2. 
(b) The intersection algorithm makes a special provision for an empty policy assertion to allow compatibity with nesting. This means expressions 1 and 2 are always compatible with each other. This means when we have nested empty policies, it is a cop-out for cheating the intersection algorithm and thus requires the intersection algorithm to account for this specifically. 

The resolution requires including an example, preferably to the framework, alternatively to the primer to illustrate the result of intersection with the examples provided in this report. If (b) is chosen, adding some guidance to Guidelines document will be appropriate as well as the framework fix. 

This report is filed as [Bug 4142]. 

[1] http://www.w3.org/TR/ws-policy/ <http://www.w3.org/TR/ws-policy/>  
[2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4142 <http://www.w3.org/Bugs/Public/show_bug.cgi?id=4142>  
---------------------- 

Dr. Umit Yalcinalp 
Research Scientist 
SAP Labs, LLC 
Email: umit.yalcinalp@sap.com Tel: (650) 320-3095 
SDN: https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/36238 <https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/36238>  
-------- 
"Nearly all men can stand adversity, but if you want to test a man's character, give him power." Abraham Lincoln.