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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] NotApplicable and combining algs



On Thu, 2004-08-26 at 10:47, Polar Humenn wrote:
> > Shouldn't I be free to write a combining algorithm, for example, that
> > returns Deny if no elements apply?
> 
> Of course, you can write combining algorithms that return Permit when
> everything states Deny. You are free to do what you want. There is nothing
> that stops you from doing that. However, I would think, that you would
> have to state the exact reasons for doing so.

Wrong. In its current state, the spec specifically permits me from
writing a combining algorithm that returns Deny when no elements apply.
This is the issue I'm raising.

> In anycase, these are some of the guidelines to follow, and basically
> makes things work with some expectation of consistency. Much like the
> applicability predicate (target) of each rule, which states that the
> result of a rule is only combined if the target is true.

We're not talking about guidelines. I'm fine with providing guidelines
and suggestions. We're talking about explicitly forbidding something
that I don't think we want to forbid.

> > I think it's clear that we don't want that model.
> 
> Well, I guess I won't speak for the group, but I want that model, which
> gives integrity and consistency to the logic, and has the ability to
> compose policies in an expected manor.

Polar, have I suggested anything that would throw caution to the wind?
No, so stop with the drama :) I simply want the spec to allow me as the
author of a combining algorithm to decide what result to return if none
of my elements is applicable. That's the only issue I've raised.

> > Basically, I think this is another case where we should say that the
> > combining algorithm decides, and it just so happnes that all the
> > standard algorithms return NotApplicable in this case.
> 
> What's the use case, other than some convience?

I provided two use cases, and you added a third (replacing Permit
fall-though rules). None of these three cases is far-fetched.

> You can use the standard algorithms, and put "default" rules with true
> applicability predicates and true conditions, and get a never return
> NotApplicable result.

Yes, of course you can. But it's extra processing, and (based on many
conversations with XACML users) very error-prone. It is much cleaner to
have a combining algorithm with a default behavior when nothing applies.
This is based on a year of experience helping people write policies with
fall-through rules.


seth



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]