[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Bug 3549 issue and questions, to complete action 70
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]