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"


You are reading an old version of the spec. The current table looks like this:

Target    Rule values     Policy Value
“Match”    Don’t care    Specified by the rule-combining algorithm
“No-match”    Don’t care    “NotApplicable”
“Indeterminate”    See Table 7 See Table 7

The change was introduced in wd 20 in order to make sure the new combining algorithms were always invoked. It would be confusing if a policy with permit-unless-deny could return not-applicable since this algorithm was specifically introduced to guarantee that N/A or Indeterminate are never returned.

Best regards,

On 2012-02-23 21:58, rich levinson wrote:
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.
Target Rule values Policy Value
“Match” At least one rule value is its Effect Specified by the rule-combining algorithm
“Match” All rule values are “NotApplicable”
“Match” At least one rule value is “Indeterminate” Specified by the rule-combining algorithm
“No-match” Don‟t care “NotApplicable”
“Indeterminate” Don‟t care “Indeterminate”
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]