OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

On Thu, 2004-02-05 at 10:33, Polar Humenn wrote:
> > > In the way I explained before about having an <ExpressionType> Complex
> > > type with which all expressions extend, the Def and Ref components could
> > > also be called an <ExpressionDef>, <ExpressionRef>.
> >
> > This sounds pretty good to me.
> There may be pedantic semantic ramifications.
> If you call it an ExpressionRef this kind of means you substitute the
> Expression and then evaluated when the expression containing the
> reference gets evaluated. If you call it a ValueRef, this kind of
> means that you evaluate it first and then substitute the value where the
> reference appears.
> In any case, we must say that Expressions represent Values, and that no
> matter when they are evaluated the must represent the same value.

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]