[Bug 4179] Preferences for policy expressions

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4179

           Summary: Preferences for policy expressions
           Product: WS-Policy
           Version: LC
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Framework
        AssignedTo: fsasaki@w3.org
        ReportedBy: fabian.ritzmann@sun.com
         QAContact: public-ws-policy-qa@w3.org


Title

Preferences for policy expressions

Description

For V.Next, WS-Policy should consider how to handle preferences. Earlier
attempts to apply preferences to WS-Policy was using an absolute scale where
there was no guarantee that two policy providers were using the same scale.
Therefore preferences must be relative to one policy document. For V.Next,
WS-Policy should either supply 1) a mechanism to indicate relative preferences
or 2) a standard preference XML attribute for policy assertions. Priority is a
synonym for preference in the context of this document.

Justification

Preferences can be used by policy providers to indicate to policy consumers
which policy assertions are preferred. This is particularly relevant in
scenarios where a policy consumer chooses policies automatically without human
interaction. For example, three encryption algorithms may be supported, but one
is extremely slow but uses minimal memory and is available for use by
memory-constrained clients. This example also shows that policy consumers may
have their own set of preferences that can override the preferences of the
policy provider.
Target

WS-Policy Framework V.Next

Proposal

Several approaches may be considered:

   1. Stating document order in a Policy indicates preferences would be
sufficient. Determine if the WG would need to resolve any contradiction to the
current rule that no policy elements are ordered.
   2. Policy alternatives could be associated with identifiers. A policy
metadata syntax could list identifiers in preference order.
   3. An XML attribute that contains relative preference numbers to include in
assertion elements. The preference or priority would apply only to the
immediate level [1]. XPath may be used to examine or select portions of a
WS-Policy instance for analysis, transformation or other uses. To contain this,
options at the same level without explicit preference indications could be
assumed to be equivalent [2]. This would enable non-normalized policies where
preferences may not be attached consistently [3].
   4. Domains could provide a proprietary means of expressing preferences. This
has already been detected in the security arena, e.g.
<AlgorithmSpeed>slow</AlgorithmSpeed> could be included under the same <All>
operator as the slow encryption algorithm. However, as this should be a
mechanism that cuts across domains, this is not an optimal or interoperable
approach.

In order to effectively handle intersections and merge, this proposal could be
extended to include concrete algorithms. Nested policies must be considered. A
standard algorithm for a policy consumer is required to compute the most
preferred policy alternative.

[#1]

<All Preference="6">
 <ExactlyOne>
     <All Preference="3">
        <Assertion1 />
      </All>
     <All Preference="2">
        <Assertion2 />
     </All>
</ExactlyOne>
</All>
<All Preference="1">
 <Assertion3 />
</All>

Which would be normalized into three alternatives (sorted according to
preference):

<All>
 <Assertion3 />
</All>
<All>
 <Assertion2 />
</All>
<All>
 <Assertion1 />
</All>

would have the following preference order:

    * Assertion3
    * Assertion2
    * Assertion1

[#2] The WG may specify a default, possibly with a Policy attribute to
override, to indicate whether options without explicit preference indications
are considered and at what preference. Note, this is similar to any
recommendation that may be made to WS-Addressing. See draft:
http://lists.w3.org/Archives/Member/member-ws-policy/2006Oct/0002.html.

[#3] More than one attribute may be needed or the capability to acquire the
value of this attribute. We recognize this may need more discussion.

Received on Wednesday, 10 January 2007 11:07:00 UTC