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

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

On Thu, 2004-04-01 at 11:51, Anne Anderson wrote:
> This is my understanding of where we are on WI#10 (combining
> algorithm parameters).  Could people clarify if I have gotten any
> of this wrong or if I have left something out?

Thanks for this summary! I have a couple comments/questions about this
proposal (not about the summary you've written)...

>    APPROVED:
>    a) Schema will be as specified in
>       http://lists.oasis-open.org/archives/xacml/200403/msg00125.html
>       except that <AttributeValue> will be replaced with
>       <Expression> (per WI#7), which could be a <ConditionReference>.

Do we really want expressions instead of simple values being passed as
parameters? Do we have use cases where this extra complexity is needed?
I thought that one of the things we wanted to guarentee is that nothing
outside the policy can effect the parameters to an algorithm. 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?

>   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?

>    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,
technically speaking, I'd like the parameters before I do the rule
evaluation, since my alg may decide which Rule to evaluate based on
parameters, but that is also an implementation detail :)


seth