Re: [xacml] New Issue#83: CORE ERRATA: error in 7.15.3 Missing attributes

[Erik Rissanen <erik@axiomatics.com>]

Hi Rich,

Here is the full text as it is currently on my hard drive for the next
draft:

---8<---

The absence of matching attributes in the request context for any of the
attribute designators or selectors that are found in the policy may
result in a <Decision> element containing the "Indeterminate" value if
the designator or selector has the MustBePresent XML attribute set to
true, as described in Sections 5.37 and 5.42.  If, in this case, and a
status code is supplied, then the value

<.... no more changes ....>
---8<---

Note that I write "may", not "MAY", although this might still be
confusing. And I am not saying anything about combining algorithms. That
was just discussion on the list to motivate the "may" in this sentence.

My interpretation of this section is that it is not intended to define
that an Indeterminate is to be returned. This is already done in
sections 5.37 and 5.42. Rather, this section is about defining the error
code in case of an Indeterminate. (But perhaps it would be better to put
the error code definition in those sections as well.)

I think the text is correct and quite clear as it is now. The problem
with it previously was that it incorrectly implied that missing
attributes always result in Indeterminate.

Rich, if you think it can still be improved, can you suggest an improved
text?

Regards,
Erik

Rich Levinson wrote:
> Hi Erik,
>
> Possibly my reply to this question got overlooked because it was in
> response to the original context where the issue came up:
>
>    
> http://www.oasis-open.org/archives/xacml-demo-tech/200706/msg00084.html
>
> 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.
>
>     Thanks,
>     Rich
>
>
>
> 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
>> "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
>>>     
>>
>>