W3C home > Mailing lists > Public > public-ws-policy@w3.org > February 2007

RE: ACTION 192 and BUG 4142

From: Maryann Hondo <mhondo@us.ibm.com>
Date: Mon, 5 Feb 2007 07:56:09 -0700
To: "Yalcinalp, Umit" <umit.yalcinalp@sap.com>
Cc: "Asir Vedamuthu" <asirveda@microsoft.com>, public-ws-policy@w3.org, public-ws-policy-request@w3.org
Message-ID: <OF89A1813C.90491FCC-ON87257279.004E39DC-85257279.0051E1E7@us.ibm.com>
Regarding the Open Action Item I have ( AI 192) and this ongoing Bug  4142 
I would like to propose the following:


1) I propose another option (c)  to Umit's original proposal 
[http://www.w3.org/Bugs/Public/show_bug.cgi?id=4142]
this sentence which is added is already in the spec in section 4.5, but I 
think that we can use this
forward pointer to be more clear on how to determine what "compatible" 
means.


----------------------------------------------------------
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. 
-----------------------------------------------------------------------------------------------------------------------------------------------
                (c)
 {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

<new text> is that 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).
Determining whether two policy alternatives are compatible generally 
involves domain-specific processing
(see Section 4.5 Policy Intersection). </new text>



2) we need to work with the WS-SecurityPolicy authors to come up with 
Guidelines that are consistent -


 Below is what is in the current doc. 
[http://www.oasis-open.org/committees/download.php/15979/oasis-wssx-ws-securitypolicy-1.0.pdf]

 I believe the items that need clarification are the last two bullets:

"Nested policies are intersected in their own processing contexts" I 
believe refers to what we call "domain specific processing"
in our spec.   The issue here seems to be that the presence of an "empty" 
nested assertion, would cause the intersection process
to "invoke" domain specific processing to receive both policy 
alternatives....one with an assertion, and one empty alternative.

The security folks have taken this semantic to mean that the domain (in 
this case, security) COULD interpret this to be
a "wildcard" thus allowing these two to be considered "compatible" 
according to the security semantics.

Thus two assertions having nested policy intersect if the outer assertion 
QName matches and the nested policies intersect.
The authors only specified that an "empty" policy is not compatible with a 
"null" assertion by the security semantic (the last sentence) 
and ths is illustrated by an   example  here.

<ex:MyAssertion>
     <wsp:Policy/>
</ex:MyAssertion>
 
NOT compatible with 
 
<ex:MyAssertion>
</ex:MyAssertion>
 
---------------------------------------http://www.oasis-open.org/committees/download.php/15979/oasis-wssx-ws-securitypolicy-1.0.pdf-----------------------

lines [323- 342]
4.1.3 Nesting Policy Processing Rules
This section provides rules for processing nested policy based on the 
informal description above;
Assertions MUST specify whether or not they contain nested policy.
Assertions SHOULD specify which other assertions can be present in their 
nested policy.
Nested assertions need to be specifically designed for nesting inside one 
or more outer assertions. Assertions SHOULD specify which assertions they 
can be nested within.
Assertions from one domain SHOULD NOT be nested inside assertions from 
another domain. For example, assertions from a transaction domain should 
not be nested inside an assertion from a security domain.
Assertions containing nested policy are normalized recursively such that 
in the normal form each nested policy contains no choices. Thus each outer 
assertion that contains nested policy containing choices is duplicated 
such that there are as many instances of the outer assertion as there are 
choices in the nested policy, one instance for each nested choice, 
recursively. See Section 4.1.4 for a worked example of normalization.
Nested policies are intersected in their own processing contexts with the 
corresponding nested policy in a matching outer assertion. Thus two 
assertions having nested policy intersect if the outer assertion QName 
matches and the nested policies intersect. Intersection always occurs 
using the normalized form. See Section 4.1.5 for a worked example of 
intersection.
An assertion with an empty nested policy does not intersect with the same 
assertion without nested policy.

[lines 460-463]
The two policies above, which are already in normal form, are intersected 
as follows; firstly the QNames of the A and B assertions are intersected 
then the QNames of the nested assertions inside the B assertions are 
intersected. 



Maryann




"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 
 
[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 
 
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 
To: Sergey Beryozkin 
Cc: public-ws-policy@w3.org ; public-ws-policy-request@w3.org ; Yalcinalp, 
Umit 
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> 
Sent by: public-ws-policy-request@w3.org 
01/03/2007 12:28 PM



To

"Yalcinalp, Umit" <umit.yalcinalp@sap.com>, <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 
To: 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/ 
[2] 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 
-------- 
"Nearly all men can stand adversity, but if you want to test a man's 
character, give him power." Abraham Lincoln. 


picture
(image/gif attachment: 01-part)

Received on Monday, 5 February 2007 14:54:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:47 GMT