Re: [xacml-comment] Policies vs. Rules

["Rich.Levinson" <rich.levinson@oracle.com>]

Hi Florian and Paul,

I agree w Paul that there is no necessity to "normalize" XACML to the 
point where every possible redundancy is removed.

The importance from my perspective is simply knowing such a 
normalization is possible, in principle, so that one is able to 
conceptualize policy architecture more clearly. i.e. one can regard 
Policy as being a Rule container/combiner, and PolicySet as being an 
overall hierarchical infrastructure component.

There are no current plans or known intents to try to reduce things further.

    Thanks,
    Rich


Tyson, Paul H wrote:
> The big difference between <Policy> and <Rule> is that <Condition> can appear in <Rule> but not in <Policy>.  Functions can be used in conditions but not in targets.
>  
> Logically, you could put your entire rule set into one big <Condition>, so in that sense all other XACML elements are unnecessary.  Then you would have something closer to RIF (http://www.w3.org/2005/rules/wiki/RIF_Working_Group).
>  
> The benefit of <PolicySet>, <Policy>, and <Rule> is that they allow you to arrange your rules in a way that makes business sense.  For example, if you have a contract for sharing intellectual property (IP), you can make a policy that corresponds to the contract, and rules for individual clauses within the contract.  This helps you keep track of where your rules come from.  You can code the expiration date into the policy.  If the contract is amended, you can add or delete rules easily.  If you have several such contracts, you can group them into an IP PolicySet.  This can live along side a "need-to-know" policyset and an "export compliance" policyset in a master policy set for your organization.
>  
> Just because you can reduce all rules to a normalized logical schema doesn't mean you must (or should) do so.  And the specification shouldn't require it.  A primary virtue of XACML is that it can be mapped to different arrangements of business rules.
>  
> --Paul
>
>
> ________________________________
>
> 	From: Florian Huonder [mailto:fhuonder@herasaf.org] 
> 	Sent: Tuesday, March 17, 2009 04:36
> 	To: 'Rich.Levinson'
> 	Cc: xacml-comment@lists.oasis-open.org
> 	Subject: RE: [xacml-comment] Policies vs. Rules
> 	
> 	
>
> 	Hi Rich
>
> 	 
>
> 	Thanks a lot for your answer.
>
> 	 
>
> 	I think I did not caught on so far.
>
> 	 
>
> 	As I understood your  answer, in XACML 2.0 there is a difference between on Policy with multiple Rules and multiple Policies with one Rule each. But I did not understand it (maybe it's my English J).
>
> 	I understood that in XACML 3.0 (when using the extended and recommended new combining algorithms) there is no difference between a Policy with multiple Rules and multiple Policies with on Rule each.
>
> 	If that is true, what exactly would be the reason not to drop Rules?
>
> 	 
>
> 	I am looking forward to hearing from you.
>
> 	 
>
> 	Regards,
>
> 	Florian
>
> 	 
>
> 	From: Rich.Levinson [mailto:rich.levinson@oracle.com] 
> 	Sent: Montag, 16. März 2009 15:50
> 	To: Florian Huonder
> 	Cc: xacml-comment@lists.oasis-open.org
> 	Subject: Re: [xacml-comment] Policies vs. Rules
>
> 	 
>
> 	Hi Florian,
> 	
> 	I agree with your issue, and I believe the TC also, in principle, agrees.
> 	
> 	This was the primary motivation behind the development of the so-called "extended" combining algorithms that are in the current XACML 3.0 draft:
> 	http://www.oasis-open.org/committees/download.php/31494/xacml-3.0-core-wd-09.zip
> 	
> 	These "extended" algorithms have two significant characteristics:
>
> 	*	They fill a functional gap in the original algorithms, which was that the originals did not take into account the fact that if a Policy contained a set of Rules, all of which had the same Effect, then one could apply the same logic as in the original algorithms which was for Rules only, which was to incorporate this "half-boolean" property to the combining algorithm for Rules. The same logic applies, in principle, to a Policy that contains Rules that can only evaluate to one Effect. 
> 	*	This effectively makes the Policy and Rule processing indistinguishable, which allows one to assume the point you mentioned that when using these extended algorithms, there is effectively no difference between a Policy w multiple Rules and multiple Policies w one Rule each 
>
> 	    Thanks,
> 	    Rich
> 	
> 	
> 	Florian Huonder wrote: 
>
> 	Hi all,
> 	 
> 	 
> 	 
> 	I have a question about Policies and Rules.
> 	 
> 	 
> 	 
> 	I really do not see the reason to distinguish between Policy and Rule. In my
> 	opinion, everything that you can solve with a Policy that has multiple
> 	rules, can also be solved with multiple Policies (where each only has one
> 	single Rule).
> 	The only difference that I see between Rules and Policies are that they map
> 	to different target sets. Meaning that a Rule maps to DENY or PERMIT and a
> 	Policy to DENY, PERMIT and NOT_APPLICABLE (I left away INDETERMINATE). But I
> 	really do not see a practical application for this difference.
> 	Maybe you could give me a hint about what the intent is behind Policies and
> 	Rules?
> 	 
> 	 
> 	 
> 	I heard that there is a requirement for Rules.
> 	 
> 	Could anybody tell me what the requirement for Rules is?
> 	 
> 	 
> 	 
> 	Regards,
> 	 
> 	Florian
> 	 
> 	 
> 	  
>
>
>