Re: [xacml] Agenda for November 15 Telecon...

[bill parducci <bill@parducci.net>]

> First of all, I have already conceded that we probably need negative
> rules, so lets not argue about that.

yes, but the issue of using positive rules only was raised again in a
recent meeting (by pierangela i believe). since she was previously a
proponent of allowing negative rules--and appears to have reconsidered
that position--i posed the question below. my aim is not to argue about
it, but to determine if there is a way to address this type of
situation.

> One thing that concerns me about your example is that it is a
> completely different problem space from any of our use cases. 

is it? filtering a message is in essence a single request to grant
access to a principal (a note) for a resource (e.g. mx, mbox, etc.). the
principal has a set of attributes (header, subject, sender, content,
etc.) true, the attributes space is open ended in *content*, but the
attributes themselves are finite and may be evaluated. 

> Now I am not trying to disqualify it on a technicality, but I do have a concern
> that it may represent a problem that is outside of the scope of XACML.
> Someone (not me of course) might argue that filtering emails is more
> like doing a text search or a database query than creating a policy
> model. 

last i checked the internal processing of a PEP was opaque to the xacml
universe. regardless of the process that generates the request, the pdp
is presented with a subject with one or more attributes (~6 typically)
and one or more targets/resources (or whatever the term we are using
now). is this not consistent with the approach we are taking? 

true, the value for the 'body' attribute can be quite large, but size,
as they say, shouldn't matter. previous discussions seemed to indicate
that regex was an acceptable method for deriving information from a
request, therefore a set of rules should be able to be written that can
generate a deterministic outcome regardless of the size of the
attribute.

> Can you recast the example in one of the use case problem
> domains, such as medical records or XML documents? Alternatively,
> would you like to submit a usecase around filtering SPAM?

i don't think this is necessary. i believe that the fundamental
requirements are the same.

> For example, your "score" based filtering is outside of anything I had
> imagined for a policy model.

...which is why we should try to be as generalized as is practical with
our model. this is nothing than a [sometimes complex] boolean for most
cases (and likely for ALL cases here).

> Your matching fields don't align very well with the current
> resource/action proposal.

if 'content' is an attribute, evaluation becomes:

rule - allow = [process: 'regex: !value']

contrast this with "User possesses a specified numeric attribute that
matches a numeric test against a constant (transaction limit > 1000)"
['Online Access Control' use case]

rule - allow = [process: 'transaction limit < 1000']

i don't see any differences (i am assuming that the PEP is passing the
transaction amount in the second case).


> I think (not sure) that you example assumes an order of evaluation. I
> would prefer to make this explicit, by means of boolean operators and
> nesting, as Tim as proposed. This makes what is going on clearer to
> human beings and allows the expresion to be transformed to an
> equivalent one to optimize the evaluation.

no, it is just an artifact of cutting & pasting procmail recipes. while
i personally like order-of-evaluation resolvers (firewalls, routers,
etc.), i conceded the use of such long ago in this group.

> As far as what Pierangela is proposing, my understanding is this.
> 
> A necessary condition is and'ed with all other conditions to calculate
> the result. A sufficient condition is or'ed with all other conditions.
> 
> This seems problematic to me, particularly in situations where
> policies relating to a particular access request are generated by
> several individials independently. But I have not read her paper
> completely or thought about it carefully.

Nor. :o)

b