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] Multiple decision result of type xpathExpression

I see. Each Individual Decision Request SHALL be identical to the original request context with two exceptions,
but since the content-selector is the new part, it obvisouly does not have to be identical to anything.
This lets us add the necessary XML namespace declarations on the content-selector.

I have a similar question about an AttributeSelector. The Path attribute holds an XPath expression,
but the spec does not define its namespace context.
Section 5.30 defines what is an AttributeSelector and refers to section 7.3.7 for details
of the XPath evaluation. Unfortunately, neither section mentions the namespace context.

Section A.2 talks about XPath and the namespace context, but the discussion is geared
towards the urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression datatype and AttributeValue.
This is not directly applicable because Section 5,.30 does not mention the datatype of the Path attribute,
and AttributeValue is not used with AttributeSelector.

Obviously, I believe the namespace context is the AttributeSelector itself, but the spec should
be updated to clarify this point.

It would be nice if the namespace context was an input argument of the algorithm in section 7.3.7.
This way the namespace context would have to be specified everywhere the algorithm is invoked
in the spec.
From: Steven Legg
Sent: Thursday, August 01, 2013 8:57 PM

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

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.


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

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