Bug 3549 issue and questions, to complete action 70

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