Proposal for changed context node for xpaths in 3.0

[Erik Rissanen <erik@axiomatics.com>]

All,

At the previous TC call I promised to write up a concrete proposal for 
changing the context node of xpaths in XACML 3.0. This (long) email 
provides such a proposal and explains the benefits.

I do not propose any changes for the XACML 2.0 errata, since this change 
would break many 2.0 policies. 3.0 would not lose any functionality 
which is available in 2.0, but policies have to be expressed slightly 
differently.

The motivation for the change is to allow for some kinds of 
optimizations which are possible when xpaths and attribute designators 
are separate and when xpaths are categorized (by attribute category) so 
the PDP can say something about where in the request context the xpath 
could apply. See the end of this email for a discussion of these 
optimizations.

I would also like to include some normative text which restricts the 
form of the xpath. I want to prevent that xpaths may "climb" outside the 
<Content> element. There are two reasons for this.

First, if we do not restrict the xpath, the context node does not matter 
much since the xpath could still be used to refer to anywhere in the 
resource content and we have not gained anything.

Second, I don't want policy writers to make any assumptions about the 
context in which the XACML request might be in. For instance, if the 
request is enveloped in an SAML assertion, the root element of the 
document is not the XACML <Request> element, and absolute xpaths will 
give different results than if the <Request> element would have been the 
root element. One way for an implementation to solve this would be to 
copy the whole <Request> into its own document so the <Request> is 
always the document element, but this costs CPU cycles. I would like to 
avoid this, so we should write the spec so it is clear that PDP don't 
need to do this.

I propose the following changes (references to wd 5 of the 3.0 core spec):

---8<--- Begin proposal

Section 5.29 Element <AttributeSelector>:

-> Add a new XML attribute to the <AttributeSelector> element:

Category [Required]
    This attribute SHALL specify the attribute category of the <Content> 
element where the xpath is applied.

-> Change the description of the RequestContextPath xml attribute. It is 
currently:

RequestContextPath [Required]
    An XPath expression whose context node is the <Request> element. 
There SHALL be no restriction on the XPath syntax.  See also Section 5.4.

It should be changed to:

RequestContextPath [Required]
    An XPath expression whose context node is the <Content> element of 
the attribute category indicated by the Category attribute. There SHALL 
be no restriction on the XPath syntax, but the XPath MUST NOT refer to 
or traverse any content outside the <Content> element in any way.  See 
also Section 5.4.


Section 7.2.1 Structured attributes

This section currently contains these two alternatives for using 
structures types:

2.    An <AttributeSelector> element MAY be used to select the contents 
of a leaf sub-element of the structured data-type by means of an XPath 
expression.  That value MAY then be compared using one of the supported 
XACML functions appropriate for its primitive data-type.  This method 
requires support by the PDP for the optional XPath expressions feature.
3.    An <AttributeSelector> element MAY be used to select any node in 
the structured data-type by means of an XPath expression.  This node MAY 
then be compared using one of the XPath-based functions described in 
Section A.3.  This method requires support by the PDP for the optional 
XPath expressions and XPath functions features.

-> Change the beginning of both these these paragraphs to the following: 
"The structured attribute MAY be made available in the <Content> element 
of the appropriate attribute category and "...


Section A.3.14 XPath-based functions

-> For each of the three xpath based functions, add one additional 
argument of type anyURI. The following text explains this argument: 
"This argument indicates the attribute category of the <Content> element 
where the xpath expression(s) are applied."

-> In the first paragraph of section A.3.14 replace "The <Request> 
element is the context node for every XPath expression" with "Each 
function takes an attribute category as an argument. The <Content> 
element in that attribute category is the context node of the xpath 
expressions."

-> At the end of the first paragraph of section A.3.14 write: "The 
xpaths MUST NOT refer to or traverse any content outside the <Content> 
element in any way."


-> Allow <Content> in the <PolicyIssuer> element. This is needed to 
allow for structured attributes with attribute selectors on delegates.

Currently it is like this:

    <xs:element name="PolicyIssuer" type="xacml:PolicyIssuerType"/>
    <xs:complexType name="PolicyIssuerType">
            <xs:sequence>
                    <xs:element ref="xacml:Attribute" minOccurs="0" 
maxOccurs="unbounded"/>
            </xs:sequence>
    </xs:complexType>

There is no <Content> element in there, although the policy issuer 
essentially is a special category of request attributes. It should be 
like this:

    <xs:element name="PolicyIssuer" type="xacml:PolicyIssuerType"/>
    <xs:complexType name="PolicyIssuerType">
            <xs:sequence>
                    <xs:element ref="xacml:Content" minOccurs="0"/>
                    <xs:element ref="xacml:Attribute" minOccurs="0" 
maxOccurs="unbounded"/>
            </xs:sequence>
    </xs:complexType>

The descriptive text for the new <Content> element will refer to the 
same place as the description of the <Attributes> element.


-> Also update the examples accordingly: use relative xpaths from the 
<Content> element and add the Category attribute in attribute selectors.

-> Also update the context node of the xpath based functionality in the 
multiple and hierarchical resource profiles. I have not looked into the 
details yet, but from my memory of the profiles, the changes should be 
just to change the context node in a couple of places and insert the 
text which restricts the xpath to the content element.

---8<--- End proposal


The following is not intended as part of the spec document, but explains 
how 3.0 will retain the equivalent functionality as XACML 2.0. (I have 
extracted the text from a previous email I sent on the topic.)

Assume that someone has defined a structured attribute type describing a 
book, and we have a request like this:

<Request>
 <Attributes Category="resource">
   <Attribute AttributeId="resource-id" DataType="book">
     <AttributeValue>
       <Book><Title>This is the title</Title><ISBN>123456</ISBN></Book>
     </AttributeValue>
   </Attribute>
 </Attributes>
 ...
</Request>

Currently an attribute selector can refer to the isbn number like this:

<AttributeSelector 
RequestContextPath="Attributes[@Category="resource"/Attribute[@AttributeId="resource-id"]/AttributeValue/Book/ISBN/text()"/>

(The path is paraphrased and not strictly correct xpath, but you get the 
idea.)

Now assume that we do not allow reference to the <Attribute> element 
with the attribute selector and make the <Content> the context node. It 
would no longer be possible to access the isbn number of the book with 
an attribute selector. However, the same effect can be achieved by 
rewriting the policy and the request.

The alternative is to place the structured data type in the <Content> 
element (note that the <Content> element is available in all categories, 
not just the resource, in 3.0):

<Request>
 <Attributes Category="resource">
   <Content>
     <Attribute AttributeId="resource-id" DataType="book">
       <AttributeValue>
         <Book><Title>This is the title</Title><ISBN>123456</ISBN></Book>
       </AttributeValue>
     </Attribute>
   </Content>
 </Attributes>
 ...
</Request>

This can the be referenced by an attribute selector. And since the XML 
is the same, no loss of functionality occurs.

Of course it will still be possible to define and implement custom 
functions which can be used via attribute designators, as can be done in 
2.0.


The text below gives some more detail about the optimizations which have 
difficulties because of the current behavior. At least the following 
problems with optimizations occur currently:

- Parsing the request context into a some form of optimized/indexed form 
for attribute designators is possible, but because the xpath can refer 
to anything in the request XML, the request has to be also retained in 
XML form unless a custom xpath implementation is used.

This is an issue if the context handler finds attributes from an 
external source. In this case either the request XML has to be updated 
with any attribute which the context handler could possibly find as soon 
as we reach the first xpath function, or we ignore this. If we do the 
updating, then this is a performance issue. If we ignore the problem, 
the behavior of the xpath functions becomes implementation specific. 
(Unless the spec explicitly says that this is how it should be like, 
that is, only the initial XML can be referenced with xpaths. I haven't 
searched the spec for it, but I don't recall ever seeing a statement 
like that. If it says so, let me know.)

- A special case of the above is that administrative requests have to be 
constructed in XML form during reduction.

- Partial evaluation becomes less useful since no xpath based function 
can be evaluated partially currently.

However, if xpaths would be restricted to the <Content> elements and all 
xpath functions would have an explicit marker for the category, we could 
introduce partial evaluation of xpath functions at the category 
granularity. (For instance, if an xpath refers to the subject and the 
subject is part of the partial request, then we can run that xpath, but 
if the xpath refers to the resource and the resource is not in the 
partial request, we cannot run that xpath.)

I think partial evaluation is a very useful function and I think it is 
worth making the spec so it can be implemented efficiently.

- The multiple resource profile becames more complex and less efficient 
to implement.

The multiple resource profile has a form of multiple request with 
repeated <Attributes> elements, like this:

<Request>
  <Attributes Category="Subject">  Alice  </Attributes>
  <Attributes Category="Resource">  A  </Attributes>
  <Attributes Category="Resource">  B  </Attributes>
  <Attributes Category="Resource">  C  </Attributes>
  <Attributes Category="Resource">  D  </Attributes>
</Request>

This is the same as running four separate requests for the four 
resources, with Alice as the subject in all these requests.

If xpaths can only refer to inside the <Content> in the <Attributes> 
element, each Attributes element can be parsed individually into the 
processing form of the implementation and these objects can be combined 
individually into individual requests.

If xpaths can refer to anywhere in the request, for each individual 
request, we have to construct a brand new XML representation as well.

There is a similar issue in the "scope" based multiple resource profile. 
In this case the resource-id attribute of the initial request has to be 
replaced with another resource-id for the individual requests. This can 
probably be done fairly efficiently by just changing the id in the 
internal representation in the PDP when running the individual requests. 
With wide open xpaths, the XML representation has to be changed as well. 
Well, maybe this is not a big deal? Changing this value in a DOM is 
probably not very inefficient. But modifying the DOM could introduce 
synchronization issues in a concurrent implementation, or the whole DOM 
would have to be replicated, which would be inefficient.

Then there is a really obscure problem, which I am not sure we should 
worry about. This is not really an optimization problem, but more a 
matter of details in conformance to the spec. The multiple resource 
profile describes that new requests are to be generated based on the 
original multiple request. This raises the issue of how whitespace in 
the new request relates to the whitespace in the original request. (The 
same issue occurs in generation of administrative requests during 
reduction as well.) I don't think anyone of us thinks of whitespace as 
being significant in XACML, but it is significant in xpath, so in the 
strict sense, since we use xpath, there is an ambiguity here. But then 
it would be pretty stupid to write an XACML policy with an xpath which 
refers to whitespace. :-) If we restrict xpaths to the inside of the 
content element, we don't need to worry about whitespace since we would 
never modify or generate the content element in the PDP processing. 
(Personally, it just bugs me that when I implement the spec, there is 
this ambiguity in there. :-))

Best regards,
Erik