RE: Bug 3549 issue and questions, to complete action 70

These changes look good to me. I request the WG to assign this one to
the editors.

Regards,
 
Asir S Vedamuthu
Microsoft Corporation


-----Original Message-----
From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Frederick Hirsch
Sent: Friday, September 08, 2006 10:05 AM
To: public-ws-policy@w3.org
Cc: Hirsch Frederick
Subject: Re: Bug 3549 issue and questions, to complete action 70


Proposal to resolve issue 3549

Make following changes to latest editors draft of Framework [1]

1. At start of third paragraph in section 3.1, "Policy Assertion":

Insert " (as defined in Section 4)" with "Section 4" as link to  
section 4, after text
"Domain authors MAY define that an assertion contains a policy  
expression"

modified text reads:

"Domain authors MAY define that an assertion contains a policy  
expression (as defined in Section 4) as one of its [children]."

2. Change 2nd sentence in fourth paragraph of section 3.1 from

"Such content MAY be used to parameterize the behavior indicated by  
the assertion"

to

"Such properties are policy assertion parameters and MAY be used to  
parameterize the behavior indicated by the assertion."

3. In section 4.3.3, "Policy Operators", change first equivalence  
statement from

"wsp:Policy is equivalent to wsp:All"

to

"Use of wsp:Policy as an operator within a policy expression is  
equivalent to wsp:All"

[1] <http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy- 
framework.html?content-type=text/html;%20charset=utf-8>

regards, Frederick

Frederick Hirsch
Nokia


On Aug 24, 2006, at 1:55 PM, Frederick Hirsch wrote:

> This email is to complete action 70 [1]  to provide a summary of  
> the issue and related questions for bug 3549 [2]. Please respond to  
> this thread if you have answers or points of discussion.
>
> Issue
>
> The normative WS-Policy Framework document needs to make it clear  
> how to unambiguously and correctly state nested policies, and  
> provide clear normative processing rules around such usage. This is  
> part of the fundamental WS-Policy processing model, belonging in  
> section 3.1 of WS-Policy Framework [3]. It is also necessary to  
> allow such information to be removed from domain specific  
> specifications such as the WS-SecurityPolicy specification.
>
> For clarity this material should appear in a single section, even  
> if some material is repeated elsewhere.
>
> Note that section 4.1.2 in WS-SecurityPolicy [4] has such a section.
>
> In my view this is not primer material (although detail in primer  
> would be helpful), but essential normative material.
>
> Related Questions:
> 1) Shall a nested policy assertion be contained only within a  
> wsp:Policy element, or are other possibilities allowed, such as  
> wsp:ExactlyOne.
>
> "Nested policy assertion" means an assertion that is contained  
> within another assertion to refine it, as described in WS- 
> SecurityPolicy 4.1.2.
>
> Note that WS-SecurityPolicy reads as if written with the assumption  
> that only wsp:Policy element is allowed (underline added)
>
>> "Whereas the wsp:All and wsp:ExactlyOne elements describe  
>> requirements and alternatives of a wsp:Policy element, nested  
>> assertions describe requirements and alternatives for the  
>> enclosing assertion element. To enable these semantics, this  
>> specification defines some assertions such that they have a single  
>> wsp:Policy child element which in turn contains assertions which  
>> qualify the behavior of the enclosing assertion"
>
> Note that WS-SX committee has this material in a draft.
>
> Framework has following in 3.1:
>> Domain authors MAY define that an assertion contains a policy  
>> expression as one of its [children]. Policy expression nesting is  
>> used by domain authors to further qualify one or more specific  
>> aspects of the original assertion. For example, security policy  
>> domain authors may define an assertion describing a set of  
>> security algorithms to qualify the specific behavior of a security  
>> binding assertion.
>
> where policy expression is a definition
>
>> An XML Infoset called a policy expression that contains domain- 
>> specific, Web Service policy information. [Definition: A policy  
>> expression is an XML Infoset representation of a policy, either in  
>> a normal form or in an equivalent compact form. ]
>
> Thus this question appears germane as to how a policy expression is  
> to be specified within an assertion.
>
> Note that within 4.3.2 it is stated (underline added):
>
>> /Assertion/wsp:Policy
>> "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.  If this is not done then two assertions of the  
>> same type will not be compatible and intersection may fail (see  
>> Section 4.4 Policy Intersection)."
>
> The implication here is that wsp:Policy is the single required  
> element to contain a nested assertion.
>
> 2) Although wsp:All and wsp:Policy are logically equivalent, can  
> either be used in all settings, or can an implementation expect  
> only use of the wsp:Policy element to contain nested assertions.
>
> Framework 1.5 states in 4.3.3
>> wsp:Policy is equivalent to wsp:All
>
> yet All is only defined as a child of ExactlyOne or Policy. Only  
> Policy can appear as a direct child of an assertion if All is  
> always defined as a child of ExactlyOne or Policy.
>
> The answer appears to be, nested policy assertion always child of  
> the Policy element in the wsp namespace. This is supported by the  
> definition quoted from 4.3.2.
>
> 3) Must an assertion that can contain nested policy assertion  
> indicate that fact? How? If it is not required to, may it?
>
> Note that in WS-SecurityPolicy use of the assertion attribute  
> "ContainsPolicy" is described for this purpose in section 4.1.2,  
> with the note "Ideally the x:ContainsPolicy attribute will, at some  
> point, be moved in the WS-Policy namespace".  (This note is also in  
> the WS-SX draft).
>
> This is not to be found in the WS-Policy Framework. If this is to  
> be supported it needs to be defined in the WS_Policy framework, and  
> should be removed from WS_SecurityPolicy, since it is generic.
>
> Note that 4.3.2 implies that nested policy is always signaled by a  
> direct wsp:Policy child element:
>
>> /Assertion/wsp:Policy
>> "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; "
>
>
> 4) What are the set of normative processing rules around nested  
> policy, and can they be clearly stated?
>
> Note that WS-SecurityPolicy contains a set of normative rules  
> around nested policy in section 4.1.3. (also in WS_SX version in  
> 3.1.3) This could be carried forward into WS-Policy Framework
>
>
>> Nesting Policy Processing Rules
>>
>> This section provides rules for processing nested policy based on  
>> the informal description above;
>> 1. Assertions MUST specify whether or not they contain nested policy.
>> 2. Assertions SHOULD specify which other assertions can be present  
>> in their nested policy.
>> 3. 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.
>> 4. 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.
>> 5. 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.
>> 6. 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.
>> 7. An assertion with an empty nested policy does not intersect  
>> with the same assertion without nested policy.
>
>
> These will be lost if not stated in WS-Policy, since WS- 
> SecurityPolicy committee may remove from WS-SecurityPolicy (with  
> the understanding this sort of material belongs in WS-Policy  
> Framework)  as it is generic.
>
> 4a) Should a normative rule be added to the list mentioned #4  
> stating that any nested policy assertion MUST be contained within  
> (only) a wsp:Policy element
>
> This may be covered by 4.3.2, but needs to be highlighted.
>> /Assertion/wsp:Policy
>> "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; "
>
> 5) If a nested assertion is optional, must any instance of policy  
> containing the parent assertion indicate that it is defined to  
> (optionally) convey a nested assertion?
>
> In other words, must an assertion that has been defined by the  
> domain authors to optionally convey a nested assertion indicate  
> this fact?
>
> I believe that it MUST have a wsp:Policy child, possibly empty.  
> Another interpretation is that it need not have such an element if  
> the optional nested policy is not present. My interpretation is  
> based on 4.3.2:
>
>> /Assertion/wsp:Policy
>> "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; "
>
> This needs to be clarified, as does the use of ContainsPolicy.
>
> 6) Is use of nested policies allowed by other than the assertion  
> author? (Extensibility)
>
> In other words, say security experts define an assertion in WS- 
> SecurityPolicy, yet it is element extensible. Can another party  
> independently define a nested assertion?
>
> If so, are there any rules around this? Can nested assertions be in  
> different namespaces from each other and from the parent assertion?  
> Where is this defined?
>
> (Thanks Tony for pointing this possibility out [3])
>
> A detailed proposal can follow once answers to these questions are  
> agreed by the working group.
>
> [1] <http://www.w3.org/2005/06/tracker/wspolicy/actions/70>
>
> [2] <http://www.w3.org/Bugs/Public/show_bug.cgi?id=3549>
>
> [3] <http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy- 
> framework.html?content-type=text/html;%20charset=utf-8>
>
> [4] <http://specs.xmlsoap.org/ws/2005/07/securitypolicy/ws- 
> securitypolicy.pdf>
>
> Note I reference the submission to OASIS WS-SecureExchange  
> committee since it is public, but comments also apply to section  
> 3.1 in the current editors draft:
>
> <http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/ 
> 18837/ws-securitypolicy-1.2-spec-ed-01-r07.pdf>
>
> [5] thread start: <http://lists.w3.org/Archives/Public/public-ws- 
> policy/2006Aug/0123.html>
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>

Received on Friday, 8 September 2006 17:33:09 UTC