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

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

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)

     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?

      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.

   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.

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

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

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


Hope this helps...


seth