[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Summary of issues: WI#10. Parameters for Combining Algorithms
Polar
Regarding the issue summarized by Anne, I would prefer c). I can understand
the Seth's opinion but am not clear on the reason you wrote.
>Actually, having a CombiningParameters element reference a rule leads to
>ordering inconsitencies and restrictions in the combining algorithms.
What do you mean by ordering inconsistencies and restrictions in the
combining algorithms?
In my opinion, combiner parameter does not affect the already standardized
algorithms because they don't need those parameters. It only affects some
custom algorithms that needs combiner parameters. Such custom algorithms
must be aware how to assign a parameter to a rule/policy. I think that the
implicit sequence-based assignment scheme (you are proposing) has no
difference from the explicit reference-based assignment scheme in terms of
implementation aspect.
Or what you are concerned is the formal semantics of the combining
algorithm?
Best,
Michiharu
Polar Humenn
<polar@syr.edu>
To
2004/04/02 07:39 Seth Proctor <Seth.Proctor@Sun.COM>
cc
Anne Anderson
<Anne.Anderson@Sun.COM>, XACML TC
<xacml@lists.oasis-open.org>
Subject
Re: [xacml] Summary of issues:
WI#10. Parameters for Combining
Algorithms
On Thu, 1 Apr 2004, Seth Proctor wrote:
> 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?
Yes.
> Do we have use cases where this extra complexity is needed?
It's really no extra complexity.
> 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.
> 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.
> > 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).
> > 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.
> 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 :)
So be it.
Cheers,
-Polar
>
> seth
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php
.
>
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php
.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]