[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-comment] Multiple decision result of type xpathExpression
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]