MHonArc v2.5.2 -->

















xacml message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [Elist Home]








Subject: RE: [xacml] Function Completeness




From: Polar Humenn <polar@syr.edu>
To: Daniel Engovatov <dengovatov@crosslogix.com>
Date: Wed, 18 Sep 2002 15:51:14 -0400 (EDT)







I don't mind restricting the MatchId to these functions:

*-equal,
regexp-string-match,
rfc822Name-match,
x500Name-match

And leave the negation to handle the comparison functions we don't have.
I'd rather stay with positive rules especially for applicability anyway.
So, we can leave Negate= off of the Match.

However, if we restrict to a particular set of explicit functions (i.e.
not by type), then what about allowing the "fancy" extension functions in
the MatchId?

We should probably say that they explicity not allowed either, as there is
no guarrantee for simplistic indexing.

-Polar

On Wed, 18 Sep 2002, Daniel Engovatov wrote:

> On Wed, 18 Sep 2002, Daniel Engovatov wrote:
>
> > >Do you really think it is not a good idea to cover that hole?
> >
> > This "hole", if any, is introduced by this new "higher-order" functions
> > additions.
>
> >The MatchId specifies the boolean binary matching predicate you apply
> >between the explicit value and values returned by the designator. The
> >Match specifies the generic way in which you combine the results of each
> >comparison, which is "at least one must be true".
>
> >This semantics has been around longer than the higher-order function
> >specification.
>
> >Cheers,
> >-Polar
>
> Yes, but the "boolean binary matching predicate" was restrictd to the
> equality operation, which is symmetric.
>
> While the negation of Match was not provided, I suggest that it should not
> be supported on purpose: asking your rule source "find all the rules that
> are not for "Bob"" is less effective then writing a single deny rule for
> "Bob", while ogically the same.
>
> My point is, since all the authorization logic can be supported in
> condition, (and that's important - I would be all for expanding MAtch if it
> provided ANY additional, practical functionality) MatchId should, by design,
> support effective indexing.  Arbitrary binary operations and search by
> negation is NOT the way to achieve that..
> Is not it?
>
> Regards,
> Daniel.
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>









References:

RE: [xacml] Function Completeness
From: Daniel Engovatov <dengovatov@crosslogix.com>






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [Elist Home]


  









Powered by eList eXpress LLC