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] New Issue#83: CORE ERRATA: error in 7.15.3 Missing attributes

Hi Erik,

Possibly my reply to this question got overlooked because it was in
response to the original context where the issue came up:


however, in any event my reply there was this:

"" ... I (Rich) noticed when reading section 7.15.3 lines 3593-3595, it says "... SHALL result ... 'Indeterminate' ... as described in Sections 5.37 and 5.42". In both these sections there a description of the Optional "MustBePresent" attribute, which explicitly says "This attribute governs whether the element returns 'Indeterminate' or an empty bag ...". My interpretation of these statements together is that they appear to support what Anne says is intended, so possibly there is not an issue there after all? ""

I am concerned that simply replacing "SHALL" with "MAY" is going to confuse readers
unless there is additional context explaining why.

Also, I think that bringing in the issue of the policy-combining algorithm is not
an appropriate context, since I think it is pretty clear that when we are talking
about the what the AttributeSelector element or the SubjectAttributeDesignor
element returns (as stated in 5.37, 5.42) not what the ultimate policy decision is.

I have no stake in the original wording of these conditions, however, I find that
what is there now upon scrutiny is pretty clear to me, at least, and that the
change as proposed is going to make things more confusing. I would support
clarifying text in section 7.15.3 so that one doesn't have to hunt down
5.37 and 5.42 in order to understand what is going on.


Erik Rissanen wrote:
I am correcting this in 3.0 and the errata. I changed it to "may result"
since it is not certain the end result will be indeterminate. There
could be another policy which works and is selected by the policy
combining algorithm. I also added "if the designator or selector has the
MustBePresent XML attribute set to true", to not confuse with empty bags.

While looking into this I think I have found another minor error. In
section 5.42 it says:


If the node selected by the specified XPath expression is not one of
those listed above (i.e. a text node, an attribute node, a processing
instruction node or a comment node), then the result of the enclosing
*/policy/* SHALL be "Indeterminate" with a StatusCode value of


I think this is incorrect. It should be that the value of the attribute
selector element is indeterminate, not the enclosing policy. The value
of the policy (or rule actually) would depend on the combining
algorithm, which could find another policy which it prefers.

Do you agree with me?


Anne Anderson - Sun Microsystems wrote:
Section 7.15.3 says that the absence of matching attributes referenced
"in the policy" "SHALL result" in a decision of "Indeterminate". This
is INCORRECT. Unless an AttributeDesignator or AttributeSelector
contains the "MustBePresent" XML attribute, it will evaluate to an
empty bag if its referenced Attribute is not present in the Request
Context. An empty bag does not necessarily result in "Indeterminate" -
you have to look at the definition and use context of each XACML
function to determine how it deals with an empty bag. For some
functions, such as "type-bag-size", "type-is-in", "type-intersection",
an empty bag is a normal input to the function. Also, in the Target
element MatchId functions, an empty bag parameter results in
"NotApplicable" rather than "Indeterminate".

I stumbled across this in checking a claim by one of the interop
participants that "the definition of Indeterminate seems to be



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