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

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

Polar Humenn wrote:
 >> [...]
>>     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.

Good.

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

Right, that's part of what I was thinking.

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

Oh, well yes, there's that :)

Seriously, this actually does worry me a little. Right now a Condition 
is strictly non-recursive (though, of course, a custom function can 
still cause problems). Recursive/cyclic Definitions change what a 
Condition can represent, so we're no longer just talking about 
"syntactic sugar." I agree there might be utility in using recursion, 
but it won't always be possible to tell if we'll bottom out. I dunno. Do 
you think the benifets outweigh the danger here?

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

I guess my point is that I'll do type-checking when I first process the 
definitions, but if I don't know about a reference yet, then I have to 
go back through a second time. This leads to cases where I can parse 
many definitions and only on the second pass discover something that was 
invalid (so I shouldn't have spent time processing the rest of it). Like 
I said, it's a small point, but it's still something to consider.

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

That sounds reasonable. I guess I was just checking on the boolean 
requirement. I don't see any reason why a Reference shouldn't contain 
anything that evaluates to true or false.

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

Chomp.

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

What I think is special about it is that when we talk about XACML, the 
term Condition has special meaning. If it was just another Apply tag or 
something, then it's less clear. Given that we're discussing allowing 
something other than a function at the root or a Rule's logic (per the 
above discussion of point #2), however, I can understand why we would 
get rid of this.

By the way, this seems more reasonable to me now. I was concerned in 
part because I didn't see any real change motivating the removal of 
Condition. Allowing more than a function at the root is a real (in my 
opinion) reason to make this change. Thanks for the detail.

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

Then we agree :)

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

Sure. I just thought I'd throw it out there since it seemed a little 
"clearer" to me.

>>   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. :^)

No. Really. I am! I just started seeing Ref and Def blending together 
the more I stared at the examples...

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

Twice in one discussion? Strange...And yes, the Def/Ref pairing should 
be kept.

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

I'm not sure I like this more.

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


seth