[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 "(/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]