Re: [xacml-comment] Requirements on the Construction of XML Data Structures for XPath Processing

[Erik Rissanen <erik@axiomatics.com>]

Steven,

The intent with this was to make sure that XPath expressions evaluate in 
the same manner regardless of in which context the XACML request might 
be wrapped. Such wrapping XML is likely to have XML namespace 
declarations (say for instance SOAP namespaces), which do not really 
relate to the <Content> but would still be in scope of the <Content> and 
could therefore be referenced by XPath unless we said no to that.

This formulation is probably a leftover from an earlier draft which did 
not specify that the XPath should be evaluated in a stand alone 
document, like it says now. BTW, the "MAY" should not be capitalized. 
It's not a "MAY" in the sense of a conformance criteria.

In any case, it does not have any implication to the processing since 
the fact that the content is split up into a separate document means 
that this is not an issue.

Since we are so late in the process, I am inclined to just leave it in 
the spec rather than to do a full cycle from working draft again.

Best regards,
Erik


On 2012-05-23 03:05, Steven Legg wrote:
> The following statement appears in Section 7.3.7 (AttributeSelector 
> evaluation)
> of the XACML 3.0 core specification (Committee Specification 01):
>
>     Namespace declarations which are not "visibly utilized", as 
> defined by
>     [exc-c14n], MAY not be present and MUST NOT be utilized by the XPath
>     expression in step 3.
>
> It is not at all obvious what this statement is trying to achieve.
>
> Firstly, "MAY not be present" seems to be an awkward way of saying 
> "MAY be
> absent". Either way it implies processing that is not well described, 
> which is
> to add namespace declarations to the document element of the 
> constructed XML
> data structure for at least each of the namespace declarations on the 
> <Content>
> element and its ancestors that are visibly utilized within the content 
> of the
> <Content> element. However, omitting namespace declarations that are not
> visibly utilized is not entirely safe. The definition of visibly utilized
> does not account for prefixes used in the values of XML attributes or the
> character data of elements, so some of the namespace declarations that 
> are not
> "visibly utilized" in the content the <Content> element may 
> nonetheless be
> required to properly interpret that content. The safe and easy thing 
> to do is
> just add in all the in-scope namespaces of the <Content> element, 
> whether they
> are visibly utilized or not.
>
> Secondly, the "MUST NOT" applies to the XPath expression in the Path 
> attribute
> of an AttributeSelector, which is in an entirely separate XML 
> document; the
> Attribute Selector is in an XACML policy, while the <Content> element 
> is in
> an authorization request, Taken literally, this "MUST NOT" compels 
> PEPs to not
> use any namespace declarations on the <Content> element or its 
> ancestors that
> are not visibly utilized within the content of the <Content> element 
> and have
> been used in the Path of any AttributeSelector. It also compels PAPs 
> to not
> use any namespace declarations in the in-scope namespaces of an
> AttributeSelector that are used in any authorization request but not 
> visibly
> utilized by the content of the <Content> element in that request. It 
> is not
> practical for either PEPs or PAPs to satisfy those requirements, and 
> doing so
> serves no useful purpose that I can discern. I assume the intent must 
> have been
> something else.
>
> If someone could tell me what purpose the offending statement is 
> supposed to
> serve, then I can suggest better text; otherwise, it should be removed.
>
> A similar statement appears in Appendix A.2 under the XPath expression
> data-type. At least in this case the XPath expression and the 
> <Content> element
> may be in the same authorization request (though not always). However, if
> the requirement cannot be satisfied in practice for XPath expressions in
> AttributeSelectors I don't see the point in enforcing it here.
>
> Regards,
> Steven