Re: [xacml-dev] xpath, urn:oasis:names:tc:xacml:1.0:resource:xpath

[Niko Matsakis <niko@alum.mit.edu>]

I think there is some confusion about the leading "//" and "/"  
operators in xpath:

	"//foo" searches the entire document for all <foo> elements
	"/foo" only returns the outer-most element

Note that in xpath, the "root node" of the document is NOT the outer- 
most element; instead, it is a fictitious node, of which all the "top  
matter" of an XML document is considered a child.  In other words:

	<?pi?>
	<!-- comment -->
	<foo>
		<bar/>
	</foo>

would create an xpath tree like:

	/
		processing-instruction: pi
		comment: "comment"
		element: "foo"
			element "bar"

The "/" indicates the root node.  So, in an xpath expression, "/foo"  
indicates all children of the root node which are elements named "foo".

The xpath *context* node is denoted by a ".", but this is typically  
implicit.  i.e., "foo" is short for "./foo" (which itself is short  
for "./child::foo").  Likewise, ".//foo" selects all nodes underneath  
the current node that are an element named "foo".

Note also that xpath expressions are not (typically, anyway) combined  
by string concatenation, but instead by using relative paths as shown  
above.

> First, let's assume the context node is xacml-context:Request as  
> stated in sec A.3.15 lines
> 4907-4908. i.e. "//xacml-context:Request"  - do you agree? (If not,  
> please specify.)

No, I think the context node would be "/xacml-context:Request".   
Actually, the two are mostly equivalent, unless you have a document  
like:

	<xacml-context:Request>
		<xacml-context:Resource>
			<xacml-context:ResourceContent>
				<xacml-context:Request/>             <-- a second Request element!

In this case, //xacml-context:Request, which selects all Request  
elements in the document, would return a nodeset with 2 elements in  
it, but only one is expected.

> Now, looking at the specific ResourceMatch fragment you cite below  
> from section 4.2.4.1
> Rule 1 lines 1166[a241]-1174[a247], my interpretation is that  
> argument 1 is "/md:record",
> which would translate to "//xacml-context:Request/md:record". Agree?

No.  Using a node as the context for an xpath expression simply  
indicates what nodeset is returned by ".".  This affects relative  
xpath expressions, like "md:record".  The leading "/" in "/ 
md:record", similar to an absolute path in a file system, is always  
relative to the root of the document, regardless of the context.

In my answers to the rest of your questions, I will assume that  
instead of "/md:record" you had written "md:record".

> If so, then I agree that this would return an empty node-set, since  
> what we want is:
> "//xacml-context:Request/xacml-context:Resource/xacml- 
> context:ResourceContent/md:record"
> Agree?

Agreed.  If the context-node were the Request, then we would need:

	"/Request/Resource/ResourceContent/md:record" (xacml-context's omitted)

so the ResourceMatch from section 4.2.4.1 would need to be "xacml- 
context:Resource/xacml-context:ResourceContent/md:record".

> If so, then if we were to change "/md:record" to "//md:record" then  
> I think this would
> return what I suggested we want just above for arg 1. Agree?

Yes, although it might also return more.

> Now for arg 2, my assumption is that the resource:xpath, which we  
> can probably
> assume is either the default context node "//xacml-context:Request" or
> "//xacml-context:Request/xacml-context:Resource/xacml- 
> context:ResourceContent",
> either one of which is ancestor to //md:record, and thus would  
> result in successful
> match. Agree?

Agreed, but (as explained above) it is not relevant whether or not  
they are an ancestor to md:record.  This is because the leading "//"  
does not take into account the xpath context.  However, to get the  
meaning that you intended, you would need to do ".//md:record" (note  
the leading ".").

> If we agree to here, then I think 2 things would be needed to  
> correct this situation
> in the spec:
>
> 1. we would need to change "/md:record" to "//md:record"

Agreed, this does return the right result, although it entails a  
search of the entire document.

> 2. we would need to specify what the identifier resource:xpath  
> really means:
>    i.e. does it mean the "//xacml-context:Request" node, or the
>    "//xacml-context:Request/xacml-context:Resource/xacml- 
> context:ResourceContent"
>    node. Agree?

Agreed.

> If so, then I suggest that we take it to mean the latter, which I  
> think is the intent of
> section B.6 lines 5041-5046, which I believe is an identifier for a  
> namespace, which should
> match the namespace of the child of the ResourceContent node. (ex.  
> lines 1157[a233]-
> 1165[a240])

So, resource:target-namespace clearly indicates the expected  
namespace of the child of the ResourceContent node.  Furthermore,  
lines 5041-5046 make it clear that the XACML PDP MUST confirm that  
this attribute is correct (* see below).  However, there is nothing  
in that text that indicates to me that the presence of this attribute  
in the request affects the xpath context node.

In fact, if I think about it a bit more, it seems strange to me that  
the *request* should be able to affect the context node for xpath  
expressions.  Even though xacml assumes that the requests are from a  
trusted source, but it still seems like a recipe for confusion and   
possible bugs in the policy.

For example, if an xpath expression were used in a policy which did  
not anticipate the possible presence of a ResourceContent element, it  
might accidentally return Permit or Fail for a request that did  
include a ResourceContent element (and resource:target-namespace  
attribute), because the xpath is now evaluated relative to the  
ResourceContent instead of the Request element that the policy was  
expecting.

> In fact, if we did that, i.e. specify that "resource:xpath"  
> effectively sets the
> ResourceContextPath to "//xacml-context:Request/xacml- 
> context:Resource/xacml-context:ResourceContent",
> then I think "/md:record" would be correct and we would not have to  
> do #1 above
> to make the example correct. Agree?

Agreed except that, as explained above, "/md:record" is not correct.   
However, a plain "md:record" would be.

I hope this e-mail is clear.  In order not to confuse the discussion,  
I am sending a separate e-mail with some questions regarding Resource  
attributes that were raised as I read through the spec, preparing the  
answers to this mail.



regards,

Niko Matsakis