Issue 78 and proposals

[Erik Rissanen <erik@axiomatics.com>]

All,

This email contains description of and proposals for issue 78. Both as
an errate for 2.0 and an expanded proposal for 3.0 for a more complete fix.

There is a problem with using strings for xpath expressions because the
namespace resolution depends on the context of the string and that
context is not part of the string data type. For instance, imagine a
request like this:

<Request
  xmlns:ns1:=”somenamespace1”
  xmlns:ns2:=”somenamespace2”>
  <Attributes Category=”foo”>
    <Attribute id=”my-id”>
      <AttributeValue DataType=”string”>
        ./ns1:element/ns2:anotherElement
      </AttributeValue>
    </Attribute>
  <Attributes>
  ...
</Request>

In a policy we could write:

<Apply FunctionId=”some-xpath-based-function”>
  <AttributeDesignator Category=”foo”
      AttributeId=”my-id” DataType=”string”>
</Apply>

This will fetch the xpath string from the request context and apply it
as an xpath. The namespace resolutions of prefixes ns1 and ns2 are lost
since they are not part of the string data type.

An explicit xpath data type could contain the namespace context as part
of the value and we avoid this issue. We should introduce such a type
for XACML 3.0 together with new xpath based functions which use this new
data type instead of strings and deprecate the old functions.

Another issue is if we should say something as errata for 2.0. One
possibility is to introduce the new data type and associated functions
into the errata. Another possibility is to define some resolution of
namespaces in the errata. There is really only one possibility if we
stick to strings, and that is to use the namespaces from the <Apply>
element in which the xpath based function is defined. However, this is
not good for the above example.

We could also ignore the problem. In this case only xpaths which do not
use prefixes will work in XACML 2.0. Or implementers will figure
something out by themselves.

*** XPath errata for XACML 2.0

For XACML 2.0 errata I propose that we make a "quick and dirty" fix for
the current xpath functions and fix some errors in the specification
text. We also make the proposed 3.0 solution as an optional fix in the
errata. However, the existing 2.0 xpath stuff are not deprecated by the
errata.

** Attribute Selector

The XACML 2.0 specification does not specify explicitly how namespace
resolution is performed, but it is intended that the resolution is done
based on the <AttributeSelector> element.

PROPOSAL: say this in the errata

** Examples

The XACML 2.0 specification states that the context node of the xpath in
the AttributeSelector is the <xacml-context:Request> element. This means
that some of the examples in section 4 of the specification are wrong.
The examples with xpaths which do not include the Resource element are
not right.

Note that the examples use absolute xpaths. So this means that the paths
should also contain the <xacml-context:Request> element.

Also, if absolute xpaths are used, the embedding the request context in
another document, for instance as defined by the SAML profile would
affect the result.

BTW, should the SAML profile say that the embedded request must be
instantiated into its own document or should we recommend relative
xpaths in the core? From a practical point of view it would be nice that
the copying is not needed, but from the point of view of the spec, the
request context XML is really only an abstract model.

PROPOSAL: Fix the errors, but still assume that the request context is
its own document. Point out in the SAML profile that the request context
must be treated stand alone.

** XPath based functions

XACML 2.0 defines a number for xpath based functions in A.3.15. These
functions use the string data type for the xpath expressions and do not
specify anything about namespace resolution.

PROPOSAL: The errata states that namespace resolution SHALL be based on
the <Apply> element in which the xpath function is applied, regardless
of the source of the xpath containing string. An implementation may also
choose to implement the new 3.0 data type and functions.

*** For XACML 3.0

For XACML 3.0 I propose that we implement a new xpath datatype and
deprecate all the old xpath stuff.

** PROPOSAL: XPath data type

URI:  urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression

This data type represents an xpath expression. The data type value
consists of the actual xpath expression and the namespace bindings which
are needed to interpret the xpath expression.

When an instance of this data type is constructed from a constant
<AttributeValue> element in an XML document (a policy or a request
context), namespace resolution is defined by the namespaces in effect in
that particular element. If the xpath value is produced by some other
means, then the particular producing function MUST define namespace
resolution.

The initial context node “.” is defined by the particular XACML function
in which the xpath will be used as a parameter.

** XPath functions

PROPOSAL: We should deprecate the XACML 1.0/2.0 xpath functions and
redefine them in 3.0 using the new xpath data type.

** AttributeSelector

Namespace resolution is based on the <AttributeSelector> element. The
initial context node “.” is the <Request> element of the request context.

Best regards,
Erik