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

[Polar Humenn <polar@syr.edu>]

Hi Seth,

Comments inline:

On Wed, 4 Feb 2004, Seth Proctor wrote:

> In our last TC phone call, I promised to look at the latest Condition
> Reference proposal to comment on performance and implementation issues.
> Per the January 29 focus group I've been holding off...turns out that
> the new proposal went out on Monday under a new subject line and I
> missed it until now...sorry :)
>
> On the whole, I think this looks ok. It seems fairly straightforward to
> build, and most of previous concerns about performance have now been
> mitigated. There are still, however, a few details that need to be
> filled in (at least in my mind):
>
>    1. Is the list of VariableDef elements interpreted in order? This is
>       significant for at least two reasons (that I can think of)
>
>      a. what happens if two definitions have the same identifier? Is the
>         policy invalid, or do we only consider the first reference? (my
>         preference is for the former)

The policy is invalid.

>      b. do we require a reference in a definition to have already been
>         defined in the order of the policy? In other words, if I come to
>         a definition that uses a reference that I haven't parsed yet, is
>         that valid as long as I'll discover the reference later?

That may be a suitable requirement that will avoid recursive definitions.
However, it is not clear that we should avoid recursive definitions. They
may be useful, although lead to non-terminating answers. :)

>       Issue a seems pretty clear to me. Issue b is a little more fuzzy,
>       and actually does have some performance issues. If I have to do two
>       passes through the definitions (once to parse them, and a second
>       time to reseolve references), then that's more time to parse a
>       policy (though not by much) and I'm potentially spending time
>       parsing something that isn't actually valid. These are small hits,
>       but given a large number of policies with a large number of
>       definitions, this could add up.

Well, you still have to typecheck everything, (or at least you should).
So, the time spent on it is whether you really want to or not. If you do
dynamic checking, you can also do dyanmic reference binding, and do what
ever you do dyanmically for a type mismatch as for an unreferenced
binding.

>    2. Assuming the model where there's no separate reference for a
>       Condition (see my comments on this below). when a VariableRef
>       is used in place of a Condition, do we still have the
>       requirement that it must contain exactly one Apply top-level
>       element that is a boolean function? I assume the answer is yes,
>       since otherwise we're changing the meaning of a Condition, but I
>       don't see any language about this so I want to be clear.

I would rather XACML go to a more base like type structure so that the
place where a <Condition> sits may be any element of an <ExpressionType>
type, so that you may put an <Apply>, <AttirbuteValue
DataType="...boolean">, or <VariableRef> there, as long as it typechecked
to a single boolean value.

>    3. Will we consider a loop to be a syntax error in a policy? For
>       instance, if Def1 references Def2, and Def2 references Def1,
>       should an implementation recognize this and reject the policy?

This is the question about recursive definitions, of which see my comment
above.

>       This is another performance-related issue, since a policy with
>       many definitions could be very expensive to do loop-detection
>       on. Of course the alternative, simply assuming that all policies
>       are loop-free, doesn't really appeal to me either.
>
> In terms of the new schema, it seems to be coming along well, but I have
> real issues with the addition of a CondRef mechanism. I think this is
> just confusing things. Also, I think there are plenty of cases where the
> same Definition could be used as a Condition and as an Apply. My vote
> would definately be to stay with the original idea of having Ref/Def be
> a single, simple mechanism, and let someone use a Ref instead of a
> Condition. On a related note, I see no reason to remove the element
> "Condition" and start just using Apply. The Condition has been in XACML
> for a long time, and while removing it doesn't help anything (in my
> opinion) it does move 2.0 further away from 1.x, which doesn't seem like
> a good idea. It also confuses the idea of a Condition being a special
> kind of Apply statement, which is a key idea. Again, my vote would be to
> leave Condition as is.

I knew that decision to have a special <Condition> element would come back
to bite hard. :(

I personally don't think there is anything special about it, and the fact
that it was made "special" seems to be causing needless problems.

> I don't know what happened to the idea of using Refs in Targets (it
> didn't show up in the new proposal, I don't think), but I _really_ don't
> like it. If it does show up again, I'll provide some specific comments.

I think they are a bad idea, as I have stated in a previous email, I
think, if it got through my email hassle, I should check.

> I also have a few small, specific comments on the schema:
>
>    1. The xs:choice in RuleType should have a minOccurs="0" since the
>       Condition was always optional.
>
>    2. It might be nice to group all the VariableDef elements under a
>       single VariableDefinitions element, just to make things a little
>       clearer.

I think "clearer" in this case, is simply a matter of opinion. The
approach you mention is in older languages like FORTRAN, C, PASCAL, PL/1,
and that was based more on the capabilities and limitations of the
compiler writers and compiler internal capabilities more than on the
language elements themselves. Now, the tendancy in newer languages is to
define things when and where you need them, all in the name of "clarity".

>    2a. It might be nice to expand VariableDef to VariableDefinition and
>        VariableRef to VariableReference...Def and Ref are just too
>        similar looking :)

And just when I thought you were worried about verbosity. :^)

>    3. Can anyone think of a better word for "Variable"? Somehow it's
>       still just not sitting quite right with me.

Well, I tend to agree with you, because Variable with the word Reference,
does seem a bit redundant. However, I can see why we would want to keep
the Ref/Def pairing.

I would prefer <ValueDef> and <ValueRef> as you are defining a value and
referencing a value respecifively.

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

Cheers,
-Polar

 > Hope this helps...
>
>
> 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.
>