The context node of an attribute selector

[Erik Rissanen <erik@axiomatics.com>]

All,

I have question and perhaps a suggestion, depending on how you answer 
the question.

In XACML 2.0 the context node of the xpath expression in an attribute 
selector is the <Request> element. Why is it so, rather than being the 
<ResourceContent> element?

Since it is the <Request> element, it is possible to use the attribute 
selector to reference the "regular" attributes outside the resource 
content document. Has this been a design goal?

My concern with this is that I don't really see the need for using 
attribute selectors for accessing the regular attributes since they can 
be accessed with attribute designators. But making it a possibility is a 
problem for an optimizing PDP which does not keep the full request in 
the form of an XML document. If we don't do deeply arcane analysis of 
the xpath expression in an attribute selector, potentially an attribute 
selector could refer to any part of the request document, and the 
request document has to be instantiated as soon as an attribute selector 
is used, despite them usually only been used to access the resource 
content. (Or one has to implement a custom xpath library which works on 
the non-XML form of the request context.)

This represents quite a significant implementation hurdle and would also 
slow down a conforming PDP whenever attribute selectors are used.

Was there some major benefit seen from the current functionality, which 
is seen as more important than these concerns, or is this just something 
that nobody thought about?

Since we are changing the schema for 3.0, which "breaks" the xpaths in 
the current policies anyway, I think we should reconsider the context 
node in 3.0. I would propose that we make the context node the <Content> 
element and use an XML attribute in the selector to indicate the 
attribute category of the <Content> element it refers to. Also, we 
should say that the xpath expression MAY NOT "climb out" from the 
content element to refer to other parts of the request document. This 
allows the content to be a stand alone document for optimization 
purposes and the rest of the request can remain in optimized, non-XML 
form. (And I can imagine that there are still other kinds of 
optimizations which can be done once the resource content is decoupled 
from the rest of the request.)

This would also decouple the resource content from the XACML schema, 
which would make any future schema change simpler. BTW, if we want to 
improve this decoupling even more, we might want to disallow referencing 
the <Content> element name or namespace as well in the xpath expression.

This also has the benefit to make the xpath expressions somewhat more 
readable since we don't need to "dig in" to the content element using 
the expression.

Regarding backwards compatibility with 2.0, XACML 2.0 policies and 
requests would still be interoperable with 3.0 in the manner which we 
have discussed previously. However, if someone has used attribute 
selectors to refers to subject attributes for instance, these policies 
cannot be forward ported to 3.0 using attribute selectors, rather they 
must be rewritten to use designators instead. However, I don't see this 
as a major concern.

What do you think?

Regards,
Erik