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

Fabian

I think you raised an interesting issue and a generic solution as you  
propose seems to make sense.

I have one question regarding the proposed guidelines text, how is  
the intersection engine to know a default parameter value? Would it  
make sense to remove the following sentence from your proposal?

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

regards, Frederick

Frederick Hirsch
Nokia


On Jan 12, 2007, at 1:22 PM, ext Fabian Ritzmann wrote:

> 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:
>
> Consider assertion parameters in intersection by default. Two  
> policy assertions with different parameters[1] are not compatible.
> 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]
> Alternatively to 1), require domains to specify how to treat their  
> assertion parameters.
> 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

Received on Tuesday, 16 January 2007 00:22:51 UTC