Errors in the 2.0 hierarchical resources profile

[Erik Rissanen <erik@axiomatics.com>]

All,

I have got into the deep gory details of the multiple/hierarchical 
resources profiles, which seem broken regarding the xpath variant of 
them (this is not on the issues list yet). I also ended back at the 
already closed xpath datatype (issue 78).

The 2.0 hierarchical resources profile defines a new datatype called 
...:xpath-expression and mandates the use of this data type for 
requesting access for some form of hierarchical resources. The problem 
with this is that there is no XACML function which actually makes use of 
this data type, so the profile won't work as it stands today.

Also, in case you don't remember, I would remind you about the related 
issue that we have decided to introduce an xpath data type for XACML 3.0 
and we have defined new 3.0 identifiers for the xpath match functions 
which use this new data type instead of strings. The motivation is that 
an xpath expression is more than a string in the sense that it also has 
a context for resolving namespace prefixes used in the expression. With 
strings this is problematic. This new 3.0 xpath-expression data type is 
a bit different from the 2.0 one since the 2.0 xpath-expression is 
defined to have a value which consists of the node set which results 
from evaluating the expression. (In contrast to simply the expression 
itself.)

I searched through the XACML TC mailing list to try to understand what 
was intended with the 2.0 xpath-expression. (BTW, the search function 
seems to be broken. I get an error stating that I am not allowed to 
access some perl script on the web server, so I had to use my web 
browser's find function on the mailing list archive pages. I might have 
missed something because of this.)

I found a discussion about this type at the later stages of the 2.0 
work. See the archive for August 2004 and look for the postings with 
"xpath" in their subjects.

Back then the main motivation behind the idea to have such a type seems 
to have been to introduce type safety and checking of syntactical 
validity, rather than the namespace issue. The idea seems to have been 
rejected back then because there was a desire to be able to construct 
xpath expressions dynamically and the proposal would have made that 
impossible. Also, there were objections saying that it was too late in 
the 2.0 process to make such a change. However, the data type seems to 
have made to the docs and I suspect that it was just forgotten to drop 
this from the hierarchical resources profile once the decision was made 
that there should be no special xpath-expression data type. The 
discussions in August 2004 mention removing the data type from the 
examples in the core doc. I might be wrong of course, but all should 
work if we just replace the use of this data type with strings in all docs.

Regarding the new 3.0 xpath expression data type, maybe the dynamic 
construction of xpath expressions is still a concern? Nobody has raised 
this issue in the 3.0 discussion, but it might still be valid. We should 
introduce a xpath constructor function which takes a string and converts 
it into the xpath data type, which would make dynamic construction of 
xpath expression possible. Though, I am not sure how to handle namespace 
prefixes here. One option is that no name space prefixes will be 
resolvable. Another is that they are resolved from the <Apply> element 
where the conversion function is used.

(I went even further back to the 1.x work, and there was some discussion 
on namespaces in xpaths, but I didn't understand these discussions. They 
seem to have been related to some construct which was dropped and never 
made 1.x.)

Related to the namespace issue is the issue of xpointer. If one looks at 
the 1.1 examples (or the 2.0 examples once one fixes the typos), some 
examples define the namespaces using the xpointer namespace 
initialization extension. Since xpointer is not mentioned in the 
normative parts of XACML, I am not sure what to think of this. Was 
xpointer seen as "the way" to take care of namespace declarations?


I propose the following:

- I still think we should keep the new 3.0 xpath-expression datatype 
since it makes it possible to write xpath expressions with namespace 
prefixes in a "natural" way, that is, simply using those namespaces 
which are in scope in the part of the policy/request document where the 
xpath expression appears.

- I think the old 2.0 xpath-expression type from the hierarchical 
resources profile should be dropped from 3.0 and an errata be issued 
which replaces its use with strings. This because the xpath functions in 
XACML 2.0 work on strings, not this data type. We don't want to keep it 
3.0 either since the value is said to consist of the node set which the 
xpath expression resolves to, which isn't really what we want. We want 
just the expression itself and leave the resolving to whatever function 
makes use of the xpath.

- The 3.0 version of the hierarchical resources profile should use the 
new 3.0 xpath-expression data type.

- We should introduce a string -> xpath conversion function for those 
who want to generate xpath expressions dynamically.


The following open issues remain:

- Is xpointer part of XACML? If so, we should say so somewhere in the 
normative text.

- What do we do about namespaces when a string is converted to an xpath 
expression? The best approach is probably to take the namespaces from 
the <Apply> element where the function is applied.

- Finally, I know very little of xpath, so really, really, someone who 
knows more should check all this. Does anyone know someone who could 
lend a hand here?!

Regards,
Erik