[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
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 "urn:oasis:names:tc:xacml:1.0:status:syntax-error". --- 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? Regards, Erik 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 > ambiguous". > > Regards, > Anne
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]