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

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

From: Anthony Nadalin <drsecure@us.ibm.com>
Date: Mon, 15 Jan 2007 17:42:02 -0600
To: Daniel Roth <Daniel.Roth@microsoft.com>
Cc: Fabian Ritzmann <Fabian.Ritzmann@Sun.COM>, "public-ws-policy@w3.org" <public-ws-policy@w3.org>, public-ws-policy-request@w3.org
Message-ID: <OF4F2DCB68.BD090359-ON86257264.008228EE-86257264.008230FA@us.ibm.com>




+1

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122


                                                                           
             Daniel Roth                                                   
             <Daniel.Roth@micr                                             
             osoft.com>                                                 To 
             Sent by:                  Fabian Ritzmann                     
             public-ws-policy-         <Fabian.Ritzmann@Sun.COM>,          
             request@w3.org            "public-ws-policy@w3.org"           
                                       <public-ws-policy@w3.org>           
                                                                        cc 
             01/15/2007 05:24                                              
             PM                                                    Subject 
                                       RE: NEW ISSUE 4206: Clarify         
                                       treatment of policy assertion       
                                       parameters in  compatibility        
                                       determination                       
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Hi Fabian,

It is not clear to me that the sp:IncludeToken assertion parameter is
relevant to compatibility tests.  Why would a requester require a specific
sp:IncludeToken value?

The proposal suggests defining how to compare assertion parameters, which
are arbitrary XML elements and attributes.  This problem is not solvable in
a generic way.

We think the Framework states clearly that the intersection algorithm is a
domain independent approximation for compatibility that delegates to domain
specific processing when necessary.  We don’t see any issue with the
Framework here.  If there is an issue with Security Policy we think it
should be dealt with in that working group, not here.

Daniel Roth



From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Fabian Ritzmann
Sent: Friday, January 12, 2007 10:22 AM
To: public-ws-policy@w3.org
Subject: NEW ISSUE 4206: Clarify treatment of policy assertion parameters
in compatibility determination

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] 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.



--
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



graycol.gif
(image/gif attachment: graycol.gif)

pic16792.gif
(image/gif attachment: pic16792.gif)

ecblank.gif
(image/gif attachment: ecblank.gif)

Received on Monday, 15 January 2007 23:45:03 GMT

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