RE: [xacml] Concrete Proposal of ConditionReference (#7)

[Polar Humenn <polar@syr.edu>]

On Thu, 5 Feb 2004, Daniel Engovatov wrote:

>
> We do state that function (and by extension condition) evaluation should
> have no side effects, so given the same context it will always evaluate
> to the same value, but we indeed never stated that the context shall
> remain the same during evaluation.

We didn't state it in the specification? But I guess we are still on the
page on this one, anyway.

>
> It is, naturally, the same, if it is provided by request document, but
> XACML is not limited to only using context data from the request
> document.
>
> If I remember correctly, that was one of the reasons we adopted
> unordered bags as data model, and did not introduce any functions that
> rely on order of elements within a bag to remain the same even within
> the same rule.

I thought the reasons we adopted unordered bag functions was because of
the shouldn't rely on getting the answers back in a specific order for a
query evaluation.  That is, one PDP may get them back in a different order
than another PDP.

I think the situation you mention, within the same PDP during the same
evaluation is merely an implementation that doesn't violate the
constraints and is acceptable.

> On the other hand - references to an expression is a good opportunity to
> get around negative aspects of such flexibility: when you DO want to
> ensure that a particular expression is evaluated to the same value in
> different parts of the policy. That would be independent of what happens
> to the virtual context, which is not under control of the policy.
>
> So, this proposal indeed changes how the policy will be evaluated,
> compared to our current model, but that may be not a bad thing.

Agreed.

-Polar

> Daniel;
>
>
>
> >From Seth Proctor:
>
> Ah. This is a key point that has not come up in the conversation before.
> Is this really the right way to go? If I have a designator that
> references something that changes over the course of the evaluation, I
> now have to keep its value constant? What about if I cache a policy over
> many evaluations? Hrm.
>
> Originally, this work item was proposed as nothing more than syntactic
> sugar. It was supposed to help clean up policies. In our discussion of
> recursive references, I pointed out that the proposal is actually
> changing the meaning of the "condition" logic, so it's more than just a
> superficial change. This latest idea, that a Definition remains constant
> throughout an evaluation, further changes what the logic in a Rule
> means. Now, as a policy writer, I have to think about whether some
> designator or function may produce different values, and therefore
> whether it's safe to use them in a Def/Ref. This makes me really
> nervous. I would not support this approach without some very careful
> language and thought about what this feature actually does to the PDP.
>
> As an aside, I've seen a number of proposals lately that specify schema
> changes but don't have language to explain the semantics of the
> proposal. When I say that I haven't seen a full proposal for item #7,
> it's partially because I haven't seen any language discussing how the
> feature is used. Let's get this nailed down before we proceed.
>
>
> 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_workgro
> up.php.
>