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

Corrected one reference from policy assertion to policy expression 
('Clear boundaries....). No other changes included.

=======
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 expression 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:39:13 UTC