OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Hi Erik,

On 25/07/2012 10:53 PM, Erik Rissanen wrote:
Hi Steven,

Could you elaborate on what you see as the problem? I am not sure I understand what you meant in your latest

I do understand that there is an issue that if the document uses qnames which are not visible to the XML
parser. Then the namespace prefix declarations which those qnames dependon will be lost. This is basically
the same problem as in XML signature with excl-c14n. XML signature with excl-c14n has the
InclusiveNamespaces mechanism to handle it, and something like that would be required to fully solve this
problem with regard to the <Content>.

As a workaround, one may wrap the XML from the PEP in some synthetic XML element to force visibility of the
prefix. Say that you have this what you would like to send from the PEP:

   <Thing xmlns:foo="http://example.com/colors"; color="foo:red"/>

You could force foo to become visible like this:

   <Wrapper xmlns:foo="http://example.com/colors"; foo:bar="bar">
     <Thing color="foo:red"/>

Was this the issue you were concerned about?

It wasn't. Suppose that the PEP had this document:

<IrrelevantStuff xmlns:foo="http://example.com/foo";>
 <Thing foo:color="red"/>

and that the child of <Content> was expected to be a <Thing> rather
than whatever it was wrapped in. If the PEP just copies and pastes
<Thing> into <Content>, like so:

 <Thing foo:color="red"/>

then that isn't valid according to Namespaces in XML. To ensure that
the XML is valid the PEP could copy over the in-scope namespaces for
<Thing>. Either of the following would be valid XML for the request:

 <Thing xmlns:foo="http://example.com/foo"; foo:color="red"/>

<xacml:Content xmlns:foo="http://example.com/foo";>
 <Thing foo:color="red"/>

If the PDP extracts <Thing> from (1) as a separate document, then that
separate document is valid. If the PDP extracts <Thing> from (2) as a
separate document, then that separate document is not valid because it
is missing a namespace declaration for the "foo" prefix. The PDP could
mitigate potential validity problems by copying over in-scope namespaces
from the <xacml:Content> element to the extracted <Thing> element,
but the question is whether it is supposed to. The current text
doesn't clarify the matter. Your earlier response suggests that the
intent is that the PDP should not have to do that (which is fine),
but that does mean that there is a requirement on the PEP to produce
(1) rather than (2), and that a PDP is within its rights to reject (2)
as a syntax error in the request.

With regard to the child element of the Content element, the requirement
on the PEP could be stated something like this: the name of the child
element, the names of any nested XML attributes or elements, and any
nested character data or attribute value that is interpreted as a
qualified name, SHALL NOT depend on namespace prefixes that are declared
by namespace declarations on the <Content> element or any of its ancestor


Best regards,

On 2012-07-06 06:47, Steven Legg wrote:

Hi Erik,

On 4/07/2012 10:45 PM, Erik Rissanen wrote:

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.


Best regards,

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]