[ws-policy] 4/25/2007: Context of Policy Expressions and Assertions Including Nested

To start the discussion relevant to:

  Action 285: http://www.w3.org/2005/06/tracker/wspolicy/actions/285 
Context
  Action 286: http://www.w3.org/2005/06/tracker/wspolicy/actions/286 
Nested policy assertions (Guidelines)

In specifying and scoping policy vocabulary, several issues and our 
discussion indicated key context concepts should be explained in more 
detail. We would like to start the discussion with a few basic 
assumptions. Here, we refer to 'context' is relevant to policy 
expressions and assertions [1]:

   1. The meaning of absence of a policy assertion in general is
      currently underspecified.
   2. The meaning of an empty policy element (whether nested or not) in
      intersection
   3. The semantics of wsp:Optional, and the impact on normalization and
      intersection where a policy assertion is absent
   4. The domain semantics associated with an empty policy element -
      where and how this is specified needs to be more explicit (whether
      nested or not)

Context provides:

    * Additional information regarding the relationship between a nested
      policy assertion and its parent.
    * Semantics of dependence - meaning the nested policy assertion in
      the context of its parent. For example, a nested policy assertion
      may be uniquely specified, but its meaning is always evaluated in
      the context of its parent.  This is evident in the two proposals
      Alternative F and G for WS-Addressing, the former with some
      revisions was adopted 23 April 2007.[2]
    * Scope of what empty means in the context of a policy assertion or
      a nested policy assertion associated to its parent.  See example
      that follows in addition to those in WS-Addressing.
    * Allows a domain to further restrict those policy assertions. Note,
      this allows absence to be further restrict by the domain. More
      Framework specification may be addressed in the future.

In the future, additional Framework specification may be developed to 
handle roles, domain identification[3], etc. For example, purpose of a 
policy assertion and its use is scoped by and related to the entity that 
prepares the policy assertion.

What should be specified or described to support context in the 
Framework (initial list only) [4]:

    * Clear boundaries of each policy vocabulary. For example, that a
      nested policy assertion creates a new instance of a new policy
      vocabulary.
    * Specified relationship between a nested policy assertion and its
      parent with some direction on compatibility checking. Specify
      depth-first for compatibility checking based on QNames to match
      policy alternatives in intersection.
    * Capability to identify a policy vocabulary (separate but related
      to [4]).
    * Nested policy assertions are unique, i.e. we have said that they
      are developed as all policy assertions independent of their
      attachment mechanism. Yet, nested policy assertions have meaning
      in and are evaluated in the context of their parent. Guidance on
      policy subject verses policy assertion dependencies should be
      described.

In this discussion, context could be scoped to the relationship that a 
nested policy expression or assertion [see 1] has to its parent 
(although the implications as stated are more broad).  This discussion 
already affects domains such as WS-Addressing and others [5]. The 
WS-Addressing Alternatives F and G are relevant as examples as is Asir's 
(below). [6]

<Policy>         <!-- V1 -->
  <ExactlyOne>
    <Addressing>
      <Policy/>  <!-- V2 -->
    </Addressing>
    <Addressing>
      <Policy>   <!-- V3 -->
        <AnonymousResponses />
      </Policy>
    </Addressing>
    <Addressing>
      <Policy>   <!-- V4 -->
        <NonAnonymousResponses />
      </Policy>
    </Addressing>
  </ExactlyOne>
</Policy>

These ideas are consistent with the concept proposal for Action 270.[7]

Thanks.

[1] Given what we specify, this could be related to the policy 
expression or assertion authors.
[2] Alternative F: 
http://lists.w3.org/Archives/Public/public-ws-addressing/2007Mar/0038.html 
and 
http://lists.w3.org/Archives/Public/public-ws-addressing/2007Mar/0039.html
Alternative G: 
http://lists.w3.org/Archives/Public/public-ws-addressing/2007Apr/0030.html
[3] Issue 4178: http://www.w3.org/Bugs/Public/show_bug.cgi?id=4178
[4] Consistent with recent discussions and Vedamuthu post
[5] WS-SecurityPolicy v1.2 has made assumptions around empty and nested 
policy expressions, i.e. empty as a wildcard.
[6] Action 271: Vedamuthu / 
http://lists.w3.org/Archives/Public/public-ws-policy/2007Apr/0017.html
[7] http://lists.w3.org/Archives/Public/public-ws-policy/2007Apr/0022.html

Received on Wednesday, 25 April 2007 15:24:29 UTC