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
	 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
<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/Alway
sToRecipient"
<http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Alway
sToRecipient> />
	</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/Alway
sToRecipient"
<http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Alway
sToRecipient> />
	</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/Alway
s"
<http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Alway
s> />
	</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=PolicySpecIssueMultiple
Alternatives#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=PolicySpecIssueMultiple
Alternatives#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=PolicySpecIssueMultiple
Alternatives#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/Alway
s"
<http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Alway
s> >
	|
	</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