Re: [xacml-comment] Multiple decision result of type xpathExpression

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

Hi Clement,

I wasn't around when this profile was written so I can't speak authoritatively on
what the authors had in mind, but I can offer an opinion.

The goal is to turn an original single request for multiple decisions into a
set of individual decision requests. The original request in this case contains
a "multiple:content-selector" attribute with a value of the xPathExpression
data-type containing an XPath expression.

The XACML core specification says that the content of a value of the xPathExpression
data-type "also includes the context in which namespaces prefixes in the expression
are resolved". I take this to mean, in XML Infoset terminology, that the
[in-scope namespaces] of the <AttributeValue> element of the "multiple:content-selector"
attribute are used to resolve namespace prefixes in the XPath expression.

The XPath expression in the value of the "multiple:content-selector" attribute in
the original request will evaluate to some number of nodes, N, within the <Content>
element. Therefore there will be N individual decision requests; one for each of
the N nodes. The corresponding node for each individual decision request is specified
by the "content-selector" attribute, which shall also contain a value of the
xPathExpression data-type. An implementation is free to use whatever XPath expression
it likes in that xPathExpression value as long as it evaluates to exactly one of
the N nodes (a different one for each of the N individual decision requests).
Any namespace prefixes in that XPath expression are resolved using the
[in-scope namespaces] of the containing <AttributeValue> element, so an implementation
must arrange for those [in-scope namespaces] to be appropriate for the XPath
expression it generates.

Here's a simple strategy for generating the "content-selector" attribute. For
illustration, assume that the XPath expression in the "multiple:contents-selector"
attribute's <AttributeValue> element is "/x:foo/y:bar". The namespace declarations
for the "x" and "y" prefixes being in the [in-scope namespaces] of the <AttributeValue>.

First count the number of nodes in the nodeset that results from evaluating the XPath
expression in the "multiple:contents-selector" attribute value, i.e., find N.
For example, evaluate "count(/x:foo/y:bar)".

To create the "content-selector" <AttributeValue> for each individual request I,
where I varies from 1 to N, give it the same [in-scope namespaces] as the
"multiple:content-selector" attribute's value and make the contained XPath expression
"(/x:foo/y:bar)[I]".

More below.

On 2/08/2013 5:04 AM, Pellerin, Clement wrote:
> The section 2.2.3 of the XACML v3.0 Multiple Decision Profile v1.0 states that:
> Each Individual Decision Request SHALL be identical to the original request context with two exceptions: the "multiple:content-selector" attribute SHALL NOT be present and an added "content-selector" attribute value SHALL be an XPath expression that evaluates to a single node in the <Content> element.
>
> The spec intentionally leaves the exact syntax of the XPath expression as an implementation detail.
> Balana returns an invalid XPath expression and I'm looking for guidance what should be returned instead.
>
> The obvious answer is to return something like /parent/child
>
> What should be done with elements in a namespace?
> What is the namespace context of the returned XPath expression?

The [in-scope namespaces] of the <AttributeValue> element containing the
XPath expression.

> Can the PDP augment the response with namespace declarations that it needs in the XPath expression?

A PDP doesn't return individual decision requests, but whatever system component
expands a request for multiple decisions into a set of individual decision requests
not only can, but must, augment the <AttributeValue> element of the "content-selector"
attribute (or an ancestor element) to have the namespaces declarations it needs
for the XPath expression.

Regards,
Steven

> The work-around for the lack of namespace context would be to write a predicate
>    /*[local-name()='parent' and namespace-uri()='http://ns.com']/*[local-name()='child' and namespace-uri()='http://ns.com']/
> A predicate is already required to distinguish identical siblings with their index.
>
> The complicated predicate works but I wonder if that's the solution the authors had in mind.