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

[Rich Levinson <rich.levinson@oracle.com>]

Hi Erik,

I have done a preliminary analysis of the issue at hand and am finding it
to be fairly complex, although maybe it needs a review so we can get
it clear once and for all.

I have partially analyzed the situation and included the results of the
partial analysis in the modified paragraph below, which is obviously
incomplete. However, before going thru all the details, I would at
least like to find out if there is agreement on how interpreted things
this far. In addition to what's there, if there is agreement on the approach
I think the whole paragraph needs to be reordered so as to relate to the
scopes where missing attributes apply and the possible outcomes of their
evaluating to "Indeterminate" in those scopes.

Here is a preliminary recommended modification to the paragraph you provided:

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

<.... no more changes ....>

I am slightly concerned we are opening a Pandora's box here, however,
it is probably not a bad idea to review the current logic in the core spec,
and in the aftermath of the XACML Interop this may not be a bad time
to do it.

In particular, I think we need a clear definition of the scope of return values.
We have the following hierarchy of elements, in general:

    PolicySet
       Target
       Policy
          Target
          Rule
             Target
             Condition

First, consider Target evaluation, section 7.6. It says "If any one of the subjects,
resources, actions, and environments specified in the target are "Indeterminate",
then the target SHALL be "Indeterminate".

Now, let's see if we can determine what will cause any of the subjects, resources,
actions, or environments to return "Indeterminate". According to sections 5.7 Subject,
5.10 Resource, 5.13 Action, and 5.16 Environment, "The <*> element shall contain
a conjunctive sequence of <*Match> elements."

The above statement implies to me that if any <*Match> in the above elements, returns
"Indeterminate" then the whole element (Subject, Resource, Action, Environment)
will return "Indeterminate".

Unfortunately, the <*Match> elements in sections 5.* do not say under what conditions
they return what.

However, section 7.5 appears to cover this. In particular, lines 3392-3407. However,
I am finding those lines difficult to mentally parse. First it says "If an operational error ...
then the entire expression SHALL be 'Indeterminate'." This sounds like it covers the
missing attribute case, but I am not 100% sure of that, because, while a "missing
attribute" (with a MustBePresent) will return an "Indeterminate", I am not sure that a
missing attribute is considered to be an "operational error".

However, for the sake of discussion, let's say the missing attribute w MustBePresent
based on the above logic implies that the parent element (Subject, Resource, Action,
Environment) will return "Indeterminate".

Now that puts us up at the collective parent elements (Subjects, Resources, Actions,
Environments), which are disjunctive matches.

Presumably, these elements are the source of the "may" since if there are multiple
children, and one returns "Indeterminate", but another returns Match then the
final value is "Match", ex Table 2, line 3443, Subjects match table.

    Thanks,
    Rich




Erik Rissanen wrote:

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