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

[Hal Lockhart <hal.lockhart@entegrity.com>]

Title: RE: [xacml] Agenda for November 15 Telecon...

Bill,

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

One thing that concerns me about your example is that it is a completely different problem space from any of our use cases. 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. 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?

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

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

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.

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.

Hal

> -----Original Message-----
> From: bill parducci [mailto:bill@parducci.net]
> Sent: Tuesday, November 20, 2001 9:13 AM
> To: xacml list
> Subject: Re: [xacml] Agenda for November 15 Telecon...
>
>
> i am having trouble coming to grips with this concept in a
> practical sense.
>
> here is an example of something that i work with on a regular basis:
> content filtering.
>
> let's suppose that i want to use a  PEP to filter e-mail/news/media
> feeds, etc. based upon content. here are some examples:
>
> ALLOW (the easy stuff)
> ----------------------
> ^From.*root\@.*(mydomain\.net|(mydomain|yourdomain|hisdomain|h
> erdomain)\.com)
> ^From.*xacml\@lists.oasis-open\.org
>
> DENY
> ----
> ^Subject:.*LOVEYOU
> ^Subject:.*invest.in.credit.card
> ^Subject:.*[sS]av((e)|(ings))?.up.to
>
> DENY ('score' based, may require multiple hits to deny)
> ----------------------------------------------------
> Content: [(no)?(without)?].obligation
> Content: over.(18|eighteen)
> Content: bargain
> Content: (^debt|[ ]debt)
> Content: save.big
> Content: no.*fee
>
> this is a small sample of the hundreds (if not thousands) of
> conditions
> that can be used (i personally have hundreds). conversely,
> the number of
> possible character combinations comprising a request is litterally
> infinite. describing the ALLOWs is easy, but how does one generate a
> policy that says:
>
> deny message if the content contains: (^debt|[ ]debt) ?
>
> thanks
>
> b
>
>
> Pierangela Samarati wrote:
>
>  > Hi
>  >
>  > as mentioned in the concall today al the last policy committee
>  > call we discussed the issue of positive (meaning permissions; e.g.,
>  > "this principal can access this resource") and negative
> authorizations
>  > (meaning denials: "this principal cannot access this resources").
>  > While it is true that you cannot do with permissions alone
> (many cases
>  > call for more flexibility), it is also true that having denials
>  > complicates the framework (mostly also since when you start having
> denials
>  > you start thinking of the different semantics that they
> can carry - and
>  > that who specified the rule may have intended).
>  >
>  > i had proposed an alternative solution inspired by a
> recent work, which
>  > goes as follows. Distinguish two kinds of rules:
>  >
>  > 1) the ones that specify sufficient conditions (which are
> the permissions
>  > above)
>  >
>  > 2) the ones that specify necessary conditions.
>  >
>  > instead of repeating descriptions and examples here, i am
> attaching you a
>  > file of that work where the two forms of rules are
> introduced (Section
>  > 4.2). Of course our language is different as more
> expressive; but that
>  > gives the idea.
>  >
>  > only one thing, what i call "subject"
>  > there is our "principal", what i call "object" is our "resource"
>  >
>  > pls just send me email (or post the group) for any
> clarification that may
>  > be needed, and any comments.
>  >
>  > best
>  > -p
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>