RE: Bug 4558: Scalability and performance problems with expressing allowable nested policy assertions

Could you provide an example or 2?
 
thanks,
Dave


________________________________

	From: Anthony Nadalin [mailto:drsecure@us.ibm.com] 
	Sent: Thursday, May 17, 2007 9:45 PM
	To: Asir Vedamuthu
	Cc: David Orchard; public-ws-policy@w3.org; public-ws-policy-request@w3.org
	Subject: RE: Bug 4558: Scalability and performance problems with expressing allowable nested policy assertions
	
	

	We have this today, look at a Security Token Service (STS) as implemented by WS-Trust, and all the security options that are available, I can create some real nasty assertions that take a lot of processing.
	
	Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
	 Asir Vedamuthu <asirveda@microsoft.com>
	
	
	

				Asir Vedamuthu <asirveda@microsoft.com> 
				Sent by: public-ws-policy-request@w3.org 

				05/16/2007 08:35 PM

 

To

David Orchard <dorchard@bea.com>, "public-ws-policy@w3.org" <public-ws-policy@w3.org>	


cc

	


Subject

RE: Bug 4558: Scalability and performance problems with expressing allowable nested policy assertions	
	 	

	
	>The scalability problem is that it may be difficult to list and
	>exchange all the possible nested assertions.
	>The performance problem is that such a scale may result in slow policy
	>processers performing intersection.
	
	We are not sure that a provider or requester will support the myriad of options that will result in a large number of possible combinations that one should be worried about. We cannot imagine a practical scenario where a provider or requestor would expose a myriad of options using the X509 assertion. We think a provider or requester allows little variability (that reflects what is wired under the hood) and publishes one or some small number of policy alternatives.
	
	Having said that, we do not actually see a large number of possible combinations as a problem. While a naïve implementation would, we suppose, do the full expansion to normal form of all policy alternatives and then perform n-squared matching. Please note that there are many opportunities exist for optimization.
	
	OTOH, if you are concerned about malicious providers ... Malicious providers may provide a policy expression with a large number of alternatives, a large number of assertions in alternatives or deeply nested policy expressions. Just like any quality web service implementation has throttling knobs to limit the size of the message and other message related parameters, policy implementers need to anticipate these rogue providers and use a configurable bound with defaults on number of policy alternatives, number of assertions in an alternative, depth of nested policy expressions, etc.
	
	Regards,
	
	Asir S Vedamuthu
	Microsoft Corporation
	
	
	-----Original Message-----
	From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of David Orchard
	Sent: Tuesday, May 15, 2007 5:26 PM
	To: public-ws-policy@w3.org
	Subject: Bug 4558: Scalability and performance problems with expressing allowable nested policy assertions
	
	
	The policy intersection algorithm results in policy assertions with
	nesting to
	be verbosely expressed with all of the possible nested assertions marked
	as
	optional="true".  One example of this is SecurityPolicy with X509,
	detailed in
	http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0160.html.
	
	
	The scalability problem is that it may be difficult to list and exchange
	all
	the possible nested assertions.  The performance problem is that such a
	scale
	may result in slow policy processers performing intersection.
	
	One counter-arguments are that the number of nested assertions is not
	large
	enough to warrant this optimization, and that the optimization of adding
	optional="true" is sufficient.  The general argument of premature
	optimization
	applies.  This would be a close with no action or defer to v.Next.
	
	Proposal 1:
	Update the policy intersection algorithm so that an empty policy
	assertion
	matches a policy assertion with a nested assertion resulting an the same
	policy
	assertion with a nested assertion.
	
	Proposal 2:
	Provide an explicit wildcard to match any nested assertions.