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