[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Concrete Proposal of ConditionReference (#7)
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]