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

[Frederick Hirsch <frederick.hirsch@nokia.com>]

I sent this to the wrong list, sorry

regards, Frederick

Frederick Hirsch
Nokia


On Aug 24, 2006, at 1:42 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
>
>