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

Frederick Hirsch wrote:
> 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."

You are right, the default algorithm could not deduce compatibility in 
this case without domain-specific knowledge.

Fabian


> 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 13:28:41 UTC