[Bug 4206] Clarify treatment of policy assertion parameters in compatibility determination

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

           Summary: Clarify treatment of policy assertion parameters in
                    compatibility determination
           Product: WS-Policy
           Version: LC
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Framework
        AssignedTo: fabian.ritzmann@sun.com
        ReportedBy: fabian.ritzmann@sun.com
         QAContact: public-ws-policy-qa@w3.org
                CC: monica.martin@sun.com


Title

Clarify treatment of policy assertion parameters in compatibility determination


Description

The treatment of assertion parameters in intersection is ill understood by
policy implementers and policy domains alike. The framework has this text in
section 4.5:

"If a domain-specific intersection processing algorithm is required this will
be known from the QNames of the specific assertion types involved in the policy
alternatives... Assertion parameters are not part of the compatibility
determination defined herein but may be part of other, domain-specific
compatibility processing."

Our understanding is that this means that the default algorithm will ignore all
assertion parameters when computing compatibility unless otherwise specified by
a domain. For example an assertion
<Assertion1 parameter1="value1"/> would be compatible with <Assertion1
parameter1="value2"/>. The framework leaves it open if the resulting
intersection set contains <Assertion1 parameter1="value1"/> or <Assertion1
parameter1="value2"/> or <Assertion1/>.

Looking at the existing public policy domains, WS-SecurityPolicy 1.2 says in
the introduction to chapter 2 that it is avoiding the usage of assertion
parameters to allow the default framework intersection algorithm be used.
WS-SecurityPolicy fails to specify how to compute compatibility in those cases
where it could not avoid the usage of assertion parameters. Here are simple
(incomplete) examples of a parameterized security policy assertion:

<Policy id="p1">
  <sp:IssuedToken
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Once"/>
</Policy>

<Policy id="p2">
  <sp:IssuedToken
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient"/>
</Policy>

Both policies yield different behavior on the wire. But since WS-SecurityPolicy
does not define any exceptions they would be considered compatible. It is also
left open whether the intersection result would be:

<Policy id="i1">
  <sp:IssuedToken
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Once"/>
</Policy>

or

<Policy id="i2">
  <sp:IssuedToken
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient"/>
</Policy>

or

<Policy id="i3">
  <sp:IssuedToken/>
</Policy>

Note that policy i3 is equivalent to:

<Policy id="p3">
  <sp:IssuedToken
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Always"/>
</Policy>

That means policies i1, i2, i3 would all manifest differently on the wire.

At this point this is an issue with WS-SecurityPolicy, although it is probable
that the language in the framework currently is sufficiently unclear to cause
similar issues with other domains or those that use complex policies now or in
the future. In order to achieve interoperable results, we could take the
following actions:

   1. Consider assertion parameters in intersection by default. Two policy
assertions with different parameters[1] are not compatible.
   2. Alternatively to 1), two assertions whose QNames match shall not match if
either of the assertions contains parameters. Domains may define more specific
match algorithms that can take parameters into account, and in this case, then
the policy engine may use results from such a processor to determine whether
two assertions that have the same QName, but that also have parameters,
actually match. Policy engines that are not aware of, or are not able to
process domain-specific parameter-matching semantics shall use the default.[2]
   3. Alternatively to 1), require domains to specify how to treat their
assertion parameters.
   4. Provide additional guidance in the guidelines and primer.

Ultimately, the choice between the above action depends on whether it is worse
to choose a policy alternative where some assertions actually don't match, or
to reject a policy alternative that may actually match.

This is an inherent challenge with not having a domain-independent policy
assertion language.


Justification

See description


Target

Framework section 4.5, Guidelines and Primer


Proposal

This proposal addresses the first option, considering parameters in
intersection by default. The other actions would have likely yielded more
changes or introduced incompatibilities for existing domains.

In the framework, change from:

    * Two policy assertions are compatible if they have the same type and
    * If either assertion contains a nested policy expression, the two
assertions are compatible if they both have a nested policy expression and the
alternative in the nested policy expression of one is compatible with the
alternative in the nested policy expression of the other.

Assertion parameters are not part of the compatibility determination defined
herein but may be part of other, domain-specific compatibility processing.

change to:

    * Two policy assertions are compatible if they have the same type and
    * If either assertion contains parameters and the domain has not specified
how to compute their compatibility, the two assertions are compatible if they
both have the same parameters[1] and
    * If either assertion contains a nested policy expression, the two
assertions are compatible if they both have a nested policy expression and the
alternative in the nested policy expression of one is compatible with the
alternative in the nested policy expression of the other.

In the primer, insert this text before the last paragraph in section 3.4:

Policy domains may require that assertion parameters be considered in order to
establish compatibility. The assertion (a1) has a parameter (p1). This
assertion is only compatible with another assertion if the QNames of the
assertions match as well as the QNames and values of the parameters of both
assertions. The assertion (a1) would also be compatible with another assertion
sp:IssuedToken that has no parameter (p1) because parameter (p1) is the default
for this assertion. If another assertion sp:IssuedToken had a different
parameter than (p1) it would not be compatible with (a1).

Example 3-8. A Policy Expression in Normal Form With a Parameterized Policy
Assertion

<Policy>
  <ExactlyOne>
    <All> <!-- - - - - - - - - - - - - -  A Policy Alternative -->
      <!-- - - - - - - - - - - - - - - - - - Policy Assertion (a1) -->
      <sp:IssuedToken
       <!-- - - - - - - - - - - Parameter (p1) to Policy Assertion (p1) -->
      
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Always">
       ¦
      </sp:IssuedToken>
    </All>
  </ExactlyOne>
</Policy>

[#1] The term "same parameters" must still be defined precisely in a
domain-independent way or definition must be deferred to domains. Where
sequences of choices are permitted, for example, parameters may appear in
different orders. The encoding of parameters may differ slightly. Some
parameters may be neglectable.

[#2] We believe this is the current state and has lead to inconsistencies in
WS-SecurityPolicy and potentially other domains. If this option is chosen, it
should be documented whether the intersection set contains the assertions with
all parameters omitted.

Received on Friday, 12 January 2007 18:17:32 UTC