W3C home > Mailing lists > Public > public-ws-policy@w3.org > January 2007

NEW ISSUE 4206: Clarify treatment of policy assertion parameters in compatibility determination

From: Fabian Ritzmann <Fabian.Ritzmann@Sun.COM>
Date: Fri, 12 Jan 2007 20:22:01 +0200
To: public-ws-policy@w3.org
Message-id: <45A7D1C9.4050705@Sun.COM>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=4206


        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]
      <http://wikihome.sfbay.sun.com/wts/Wiki.jsp?page=PolicySpecIssueMultipleAlternatives#ref-PolicySpecIssueMultipleAlternatives-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]
      <http://wikihome.sfbay.sun.com/wts/Wiki.jsp?page=PolicySpecIssueMultipleAlternatives#ref-PolicySpecIssueMultipleAlternatives-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]
      <http://wikihome.sfbay.sun.com/wts/Wiki.jsp?page=PolicySpecIssueMultipleAlternatives#ref-PolicySpecIssueMultipleAlternatives-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.



-- 
Fabian Ritzmann
Sun Microsystems, Inc.
Stella Business Park             Phone +358-9-525 562 96
Lars Sonckin kaari 12            Fax   +358-9-525 562 52
02600 Espoo                      Email Fabian.Ritzmann@Sun.COM
Finland
Received on Friday, 12 January 2007 18:22:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:45 GMT