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

[Steven Legg <steven.legg@viewds.com>]

Hi Erik,

Apologies for the duplicate emails. This is just a resend. I forgot
I wasn't subscribed to xacml-comment under my new email address.

On 4/07/2012 10:45 PM, Erik Rissanen wrote:
> 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.

I agree with the intent, but I don't agree that it does not have any implication
to the processing. Given that the goal is to allow the PDP to treat the child
element of the <Content> element as a standalone XML document, then there is a
requirement on the PEPs to ensure that there are no qualified names anywhere
within the child element that are dependent on namespace prefixes defined on
the <Content> element or any of its ancestor elements. If the PEP has just
cut and pasted a valid XML document into the <Content> element, then the
requirement is trivially satisfied. However, there are other ways the PEP
could populate the <Content> element (a synthetic Infoset, an extract of
some XML document, etc.) in which case it must take care so that the
serialization of the child of the <Content> element is valid as a standalone
XML document.

Understanding that that is what is supposed to happen is useful for PEP and PDP
implementors to know.

> 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.

Something for the errata then.

Regards,
Steven

> 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