OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-users message

[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]