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

Fabian, 
 
This is a very important issue. Thanks for filing this. It also confirms
that we have more work and explanation to do about the impact of
nesting, parameters and compatibility. 
 
--umit
 


________________________________

	From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Fabian Ritzmann
	Sent: Friday, Jan 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/In
cludeToken/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/In
cludeToken/AlwaysToRecipient"
<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/In
cludeToken/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/In
cludeToken/AlwaysToRecipient"
<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/In
cludeToken/Always"
<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/In
cludeToken/Always"
<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
	Finland