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

> I think we should definitely discuss what to suggest as the default behaviour or requirement from specific domains

All existing domains use generic intersection only.  We think this is the right design.  An assertion description should only specify domain specific intersection semantics when policy intersection is insufficient.  If there are any cases in specific domains where generic intersection does not work then that would certainly be a concern.

However, in this particular case (sp:IncludeToken) we think the domain actually did the right thing.  The sp:IncludeToken value is not interesting for compatibility tests.  Why would a client require or prohibit a specific sp:IncludeToken value?

> For new domains and especially for guidelines option (3) would make very good guidance rather than just ignoring that this issue exists although we defer it to the specific domain.

We agree with the statement that policy domains may define domain specific intersection processing, and framework implementations can tell if domain specific processing is need by the QNAME of the assertions (see paragraph #2 in Section 4.5 in the Framework [1]).  However, the sp:IssuedToken assertion is not an example of such a case.

Daniel Roth

[1] http://www.w3.org/TR/2006/WD-ws-policy-20061117/#Policy_Intersection
________________________________
From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com]
Sent: Monday, January 15, 2007 5:18 PM
To: Anthony Nadalin; Daniel Roth
Cc: Fabian Ritzmann; public-ws-policy@w3.org; public-ws-policy-request@w3.org
Subject: RE: NEW ISSUE 4206: Clarify treatment of policy assertion parameters in compatibility determination

If you read Fabian's issue in detail, he is not contradicting that the framework defers it to the specific domains. For example, option (3) is a strong requirement for the specific domains to deal with the issue. Option (1) provides semantics if there is no semantics defined in the domain itself.

I think we should definitely discuss what to suggest as the default behaviour or requirement from specific domains. If this yields into fixing WS-SecurityPolicy or a discussion in that domain, still it has a value.

For new domains and especially for guidelines option (3) would make very good guidance rather than just ignoring that this issue exists although we defer it to the specific domain.

HTH,

--umit


________________________________
From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Anthony Nadalin
Sent: Monday, Jan 15, 2007 3:42 PM
To: Daniel Roth
Cc: Fabian Ritzmann; public-ws-policy@w3.org; public-ws-policy-request@w3.org
Subject: RE: NEW ISSUE 4206: Clarify treatment of policy assertion parameters in compatibility determination

+1

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
[cid:image001.gif@01C73957.A21D36B0]Daniel Roth <Daniel.Roth@microsoft.com>

Daniel Roth <Daniel.Roth@microsoft.com>
Sent by: public-ws-policy-request@w3.org

01/15/2007 05:24 PM


To


Fabian Ritzmann <Fabian.Ritzmann@Sun.COM>, "public-ws-policy@w3.org" <public-ws-policy@w3.org>


cc




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"<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"<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"<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"<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"<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"<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<mailto:Fabian.Ritzmann@Sun.COM>
Finland