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.