[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml-users] group representation and combine algorithm
On Oct 31, 2005, at 2:16 PM, Daniel Engovatov wrote: > In general, all the applicable rules are equal. And all the > applicable > policies are equal. Even the document order for the first > applicable is > in reality implementation dependent. >Actually, that's not entirely true. First-applicable is defined >specifically as always using the order specified in the policy. We define policy as a set of rules. We have schema representing policy in a form of an XML document - but I do not see anywhere that we link document order with the order of the rule set. As with context - I do not see any requirement that such document must be instantiated. In Section 7.10 no document order is assumed when we talk about evaluation. In section 5.22 we do not talk about instantiating (note line 2220) and any particulars of the document order. We also do not link to any normative definition about the order of the document tree traversal for our XML documents, nor do we talk about what data model we use for the <Policy> element representation. Line 5365 talks about the order of rule in the set - not in the <Policy> elements. So my interpretation is that the order is implementation defined - as with order of attributes in the request. > I would guess XACML answer to making some rules/policies more > important > in some way is a new combining algorithm - that may make use of policy > combining parameters defined in the policy. >I'm not sure I understand your use of "important" and "equal". The >permit and deny overrides algorithms clearly define a precidence, and >the ordered algorithms let you specify which policies/rules get >evaluated before others. I don't think a new algorithm is needed to >solve this problem, though like I said in my last email, I may just >be simplifying things. I talked about rules with the same effect. > Currently there is no standard way to define a new algorithm, we may > look into this in 3.0 or at a later time frame. >I don't understand this either. What do you mean there's no way to >define a new algorithm? We define algorithms in English language and pseudo-code. There is no standard way (now) to express a new algorithm that somebody uses. On the last meeting I suggested that we may define bindings to some declarative language for the purpose of using it to express and exchange combining algorithms. Daniel;
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]