[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] Agenda for November 15 Telecon...
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC