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] Comment on issue 8? "choice element" or "Policy w no Rules"

Hi Paul,

As I recall the "extensive discussions" on the combining algorithms last
year had to do w correcting some inconsistencies and unnecessary gaps
based on the handling of Indeterminates that was in 2.0.

Also this is not a matter of "exclusively" relying on combining algorithms
vs policy or rule evaluation. The policy and rule evaluation provides the
inputs to the combining algorithms. Basically, what the table says is
no Rules means NotApplicable, as explained in previous email.

I agree that there has always been a notion of "biased" evaluation, where
a "final" answer of either Permit or Deny is required as opposed to
returning Indeterminate or NotApplicable. My understanding is that
this is the purpose of the Deny-unless-permit and Permit-unless-deny
combining algorithms.

As such, in order to allow this special case of zero Rules to exist, I think
it would be reasonable to say that a Policy with zero Rules is equivalent
to a Policy with one Rule that always evaluates to NotApplicable.
i.e. we can define default inputs to the combining algorithm in the
absence of any explicit input from the Policy itself, which I think
is a reasonable interpretation of the current contents of Table 5.

Bottom line: I see no reason why Table 5 needs to be changed as
it already appears to cleanly specify the case we have been discussing,
except that it needs a vehicle for sending the NotApplicable to
the combining algorithm in the absence of any physical Rule.


On 2/23/2012 4:17 PM, Tyson, Paul H wrote:

Yes, Table 5 assumes the existence of a rule in the policy. I think our extensive discussion last year of combining algorithms, which resulted in rewriting the pseudo-code, reflects our current intent of relying exclusively on the combining-algorithm. I don’t see any reason to back away from that position, but whatever we do Table 5 must be adjusted.


To harmonize in the direction of combining-algorithm control, we would remove rows 2 and 3 of the table body, and put “Don’t Care” for all Rule values.


To say that a policy with no rules is “NotApplicable” we could remove the 1st body row; change “All rule values are NotApplicable” in the 2nd body row to “No rules in policy”;  and change the existing 3rd row to “Don’t care” under Rule values.


If we wanted the condition “All rule values not applicable” to result in “NotApplicable” even when the algorithm says “permit-unless-deny” or “deny-unless-permit”, we would say “No rules in policy or all rules NotApplicable” = NotApplicable.


I prefer the first approach (rely exclusively on combining algorithm) because it introduces no special cases and therefore will cause the fewest surprises.





From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of rich levinson
Sent: Thursday, 23 February, 2012 14:58
To: xacml
Subject: [xacml] Comment on issue 8? "choice element" or "Policy w no Rules"


To TC:

To collect the info from today's discussion, which was ref'd in the
Feb 9 minutes:

the "latest email" I thought Erik and I had agreement that a statement
would be made in the "implementor's guide" that a Policy w no Rules
may be ignored  by developers:

"It would seem to me that at a minimum, we could include
an advisory note to developers that a PDP may ignore
a Policy that contains no Rules, since there is no point
from a XACML functional perspective to provide any logic
to do anything specific with such Policies.

Such an approach would remove any questions from developers,
and could leave the schema unchanged."

During today's discussion, the notion was introduced that somehow a
combining algorithm could effectively introduce a decision despite the
fact that there were no Rules in the Policy.

However, I think that interpretation is wrong for the following reason.
For Policy evaluation, we have to refer to section 7.11 "Policy Evaluation".
According to Table 5 there, the following is normative behavior:

The policy truth table is shown in Table 5.


Rule values

Policy Value


At least one rule value is its Effect

Specified by the rule-combining algorithm


All rule values are “NotApplicable”



At least one rule value is “Indeterminate”

Specified by the rule-combining algorithm


Dont care



Dont care


Table 5 Policy truth table

I think we can agree that the Target is a "Match", since, by section 7.7, even
an empty Target matches any request.

Also, I think that rows 1 and 3 that begin with "At least one rule ..." do
not apply since there are "zero Rules" in the use case we are discussing.
Since those rows are the only places that cause the rule-combining
algorithm to  be invoked, I think we can assume that even combining
algorithms, such as "Deny-unless -permit" (section C.6) or
"Permit-unless-deny" (section C.7) will not get invoked.

Therefore, the only thing that is left is row 2, which states:
"All Rule values are "NotApplicable"". I believe this statement
is TRUE, because in order to be false there must be at least
one Rule which has a value other than "NotApplicable", which
is FALSE, and therefore the statement is TRUE.

Therefore, a Policy w no Rules must evaluate to NotApplicable.
QED. :)


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