Thanks, Erik, for the very clear explanation and examples.
The flexibility of XACML makes it possible to do very strange things, and even without doing anything strange even the simplest policy set can quickly become complicated. The policy writer already has to think hard about policy structure, combining-algorithms, attribute tests, and the MustBePresent attribute. He should not have to worry about getting different results depending on whether he happens to put an attribute test in a Target or in a Condition.
But it doesn't appear the TC is inclined to address this problem right now. Erik's proposal (wd-19 section 7.13, Table 7) seems to be a reasonable approach that will not cause too many surprises.
In the longer term the TC should work out a comprehensive logical framework that explicitly either confirms or denies the "policy equivalence" (or "linearity" as Erik called it) between a policy with a non-empty target and the same policy with an empty target and the attribute tests distributed to the descendant conditions (with appropriate syntactic modifications). Hal has said the TC has avoided previous attempts to define "policy equivalence", but I assume that was in general, not for this specific issue.
However, I don't think we can avoid the question of whether an indeterminate target should override a "permit-unless-deny" or "deny-unless-permit" combining algorithm on the parent of the indeterminate target. Erik's example does not include the combining-algorithm of the top policy. A policy writer who uses one of these algorithms never wants to see "Indeterminate" or "NotApplicable". Either we must amend wd-19 Table 7 to honor these algorithms, or revise the definition of these algorithms to account for indeterminate targets. (Note that if we adopted the notion of policy equivalence and evaluated all descendant rules as "Indeterminate", this would not be a problem.)
Regards,
--Paul
