Proposal to clean up xpath

[Paul Tyson <phtyson@sbcglobal.net>]

We do not use Content, xpath, or AttributeSelector in our XACML
application, but I have been trying mightily to understand how these
features could be used in a real business situation.  I believe the 3.0
spec needs some significant changes to be useful in this area.  I'll
give my specific proposals first, followed by a discussion.

1. Deprecate the use of resource-id (and the other *-id XACML
attributes) with DataType=xPathExpression.  Reserve all *-id XACML
attributes for use as "a primary identifier in the domain of the XACML
application".

2. Remove the 3.0 xpath-* functions from the spec.  Continue deprecation
of previous xpath-* function ids.

3. Remove XPathCategory.

4. Specify 3 new XACML attributes with DataType=xPathExpression, for the
sole purpose of selecting a sequence of nodes in the Content of their
respective categories:

    urn:oasis:names:tc:xacml:3.0:resource:content-selector
    urn:oasis:names:tc:xacml:3.0:subject:content-selector
    urn:oasis:names:tc:xacml:3.0:action:content-selector

These attributes take the place of xpath resource-id, and generalize the
concept to other categories.

5. Add an xml attribute to AttributeSelector called
"ContextAttributeId".  When present, this attribute names the attribute
in the request context that specifies (by xpath) the context node from
which to evaluate the RequestContextPath xpath expression.  This
eliminates the need for XPathCategory.

See attached zip file for Example 2, policy 1 and request rewritten with
content-selector and ContextAttributeId.  There is no need for the
xpath-node-match function, because the required test can be expressed in
the xpath expression itself, given in
AttributeSelector/@RequestContextPath.  In general, there is no need for
any of the XACML xpath-* functions, because the actual xpath language
can be used by AttributeSelector, and the results of the evaluation can
be compared using XACML operators.

Discussion:

In order to make XACML useful for XML content, the full range of xpath
expressiveness must be enabled.  As currently specified, both the
request language and the policy language are severely restricted with
respect to xpath.  Furthermore, the existing xpath features are
difficult to understand and use.

The requirements can be stated in 2 points:

1. The AttributeSelector model must allow the policy writer or the
request context to specify the starting context node for xpath
evaluation.  The concept of a context node for xpath evaluation is
fundamental to the XSLT processing model, for which xpath was developed.
I already proposed a feature to allow the policy writer to specify the
context node for AttributeSelector
(http://lists.oasis-open.org/archives/xacml/200911/msg00033.html).  The
current proposal adds a feature to set the xpath evaluation context node
from the XACML request context.

2. The Attributes model must provide a way for the PEP to indicate what
portion of the XML Content is of interest for the decision.  (In the
absence of any such indication, the assumption is that the entire
content as a whole is of interest.)  I have already mentioned the
problem of overloading "resource-id" with a different meaning when
datatype=xPathExpression.
(http://lists.oasis-open.org/archives/xacml/200911/msg00039.html.)  That
problem is eliminated by deprecating this usage and providing the
content-selector attributes.  In addition, applications can define their
own xpath-datatype attributes and use them for specialized purposes.

I believe that when xpath is fully enabled in the core spec using
features such as I have proposed, many of the other problems around
hierarchical and multiple resources will become less important or will
have obvious solutions.

Regards,
--Paul

example-alt-xpath.zip