Re: [xacml] Summary of issues: WI#10. Parameters for CombiningAlgorithms

[seth proctor <Seth.Proctor@Sun.COM>]

Polar Humenn wrote:
> On Thu, 1 Apr 2004, Seth Proctor wrote:
>>Do we have use cases where this extra complexity is needed?
> 
> It's really no extra complexity.

As I think I explained in my last email, it is extra complexity, though 
not because we're adding more elements. Right now, combinbing algorithms 
are fairly straight forward: take a list of Rules and act on their 
results. If we add concrete paramter values, then we have to add that 
into the equation, but at least we always know what the parameters are. 
If we also add expressions, then we can no longer just look at the 
algorithm and understand how it has to act. We need to evaluate the 
expressions to the values they current resolve, and then we can do the 
combining. This is added complexity.

As I see it, we're taking a relatively clear idea and making it more 
complex, both to evaluate and to manage/understand. So, I'm hoping that 
someone can provide some real use cases that show why this is important. 
In that case, I'm all for this.

>>I thought that one of the things we wanted to guarentee is that nothing
>>outside the policy can effect the parameters to an algorithm.
> 
> Nothing will. The parameters are inside the policy, and effectively used
> within the policy's combining algorithm, just as the result of the rules
> are.

If the parameters use expressions, and the expressions resolve any value 
(which they will), then by definition the parameters are being driven by 
values outside the policy. Is it, or is it not a requirement to avoid 
this? I'm really asking, because I'm seeing two sides of the argument 
being supported, and I'm confused where the original requirement came from.

>>Using an expression defeats this (ie, if I use a designator, I'll never
>>know just by looking at the policy what parameters are being supplied).
>>Could someone provide a clear example that shows why we _need_
>>expressions instead of concrete values?
>
> Aside from you get it for free, so why not use it. You may want to
> reference a value you've defined else where.

For the reasons above, and those in my last email. Using expressions is 
extra complexity, and it lets the paramter values be defined by outside 
values. Is this something we want? If so, do we have real use cases to 
drive this change?

>>>  b) <CombinerParameter> <AttributeValue>/<Expression> elements
>>>      will have a DataType so the PDP can completely evaluate the
>>>      value before passing it to the CombiningAlgorithm.
>>>   b) <CombinerParameters> are children of the <Policy>, not of
>>>      the <Rule>; i.e. they are specified outside the <Rule>
>>>      elements to which they apply.
>>
>>What about policy combining algorithms? Do we need the same kind of
>>CombinerParameters element in PolicySet to define parameters for
>>policies?
> 
> Yes. Whether its a policy or rule combining it's basically the same
> mechanism (except policy combining algorthims have these pesky obligations
> to deal with (more on that later).

So where is this defined? I haven't seen a schema that supports 
parameters at the PolicySet level...

>>>   ISSUE:
>>>
>>>   How are <CombinerParameters> elements and the
>>>   <CombinerParameter> elements within them associated with
>>>   particular <Rule> elements?  Options:
>>>
>>>   a) Left completely up to the CombiningAlgorithm.
>>>
>>>      Polar's preference.
>>>
>>>   b) Specified order: all <CombinerParameter> elements in the
>>>      1st <CombinerParameters> element are associated with the
>>>      1st <Rule>, the 2nd <CombinerParameters> are associated
>>>      with the 2nd <Rule>, etc.
>>>
>>>   c) Specified in <CombinerParameters> metadata.  E.g.
>>>      <CombinerParameters ParameterRef="Rule5">
>>>         <CombinerParameter ParameterName="p1".../>
>>>         <CombinerParameter ParameterName="p2".../>
>>>      </CombinerParameters>
>>>      <CombinerParameters ParameterRef="Rule2">
>>>         <CombinerParameter ParameterName="p1".../>
>>>         <CombinerParameter ParameterName="p2".../>
>>>      </CombinerParameters>
>>
>>For what it's worth, I think that item c is the best choice, for a few
>>reasons. For one, we want to be explicit with the parameters how they're
>>used, so we can't just leave it up to the algorithm to pick an ordering.
>>For another, specifying all in order in one place (the
>>CombinerParameters) and then hoping that the rules stay in the same
>>order is a recipe for disaster (since you might change the rule ordering
>>and forget about the parameters)...trust me, this will lead to a lot of
>>problems :) Finally, this will require the same number of parameters as
>>rules, which is a problem if one of the rules doesn't need parameters.
>>All of these problems are solved by the simple mapping from
>>CombinerParameters to Rules via RuleId.
>>
>>In today's TC meeting, Polar raised the issue of having to know RuleIds
>>in the combining algorithm. I agree this is something important to
>>consider, and it shouldn't be a requirement, but this is an
>>implementation detail. At the end of the day, all I want is the result
>>of evaluating a rule being provided along with the parameters for that
>>result, and mapping using RuleId doesn't prevent this at all.
> 
> 
> Actually, having a CombiningParameters element reference a rule leads to
> ordering inconsitencies and restrictions in the combining algorithms.

Sorry, I don't understand this. How can being clear about which set of 
paramters goes with a given rule add inconsistency? This is exactly what 
this is trying to avoid! Also, could you explain what restrictions you 
see happening here? I think I'm missing something...


seth