Paul's xpath proposal

[Erik Rissanen <erik@axiomatics.com>]

Paul, All,

Thanks Paul for the xpath proposal write up at

http://wiki.oasis-open.org/xacml/XpathDiscussion

Permanent link to the version I am discussing in this email:

http://wiki.oasis-open.org/xacml/XpathDiscussion?action=recall&rev=1

It seems mostly good as far as I understand it and does not appear to 
have the performance issues that some of the ideas which have been 
floating around earlier.

I have a few questions:

1. Regarding the request model, you propose a new element 
Request/Content[@Category="general"]. Can't we make it 
Request/Attributes[@Category="general"]/Content instead? It would have 
the same capabilities and the benefit is that we don't need to change 
the current schema or introduce new constructs to reach the new 
<Content> element directly under the <Request> element.

2. I don't understand why the xpath-node-match, xpath-node-equal and 
xpath-node-count functions are no longer needed. The capabilities of 
these functions are very different from the capabilities of the 
attribute selector and I don't see how you could use the attribute 
selector as an alternative, even with your proposed changes.

Here is an example target with the xpath-node-equal function:

<Target>
<AnyOf>
<AllOf>
<Match
                            
MatchId="urn:oasis:names:tc:xacml:3.0:function:xpath-node-match">
<AttributeValue
                                
XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
                                
DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression">
                                md:record/md:patient_info
</AttributeValue>
<AttributeDesignator
                                
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
                                
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
                                
DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"/>
</Match>
</AllOf>
</AnyOf>
</Target>

The target will allow any request where the resource-id is an xpath 
which selects a node within the md:record/md:patient_info element. I 
don't think you can do this with an attribute selector. An attribute 
selector retrieves a value from XML content, while xpath-node-match 
tests whether two expressions select the same nodes in the XML content.

3. I think the IncludeInResult attribute can be inherited from the 
multiple:content-selector attribute, rather than always be true.

4. Can't we do with a single URI urn:...:content-selector, rather than 
one for each category: ...:subject:content-selector, 
...:resource:content-selector? That would make it more general and the 
same mechanism would work for user/application defined categories such 
as "web-service-message", or whatever somebody might need in the future.

5. To verify that I understand you, is this what you propose?

<xs:complexType name="AttributeSelectorType">
<xs:complexContent>
<xs:extension base="xacml:ExpressionType">
<xs:attribute name="Category" type="xs:anyURI" use="required"/>
New ---> <xs:attribute name="ContextAttributeId" type="xs:anyURI" 
use="required"/>
<xs:attribute name="RequestContextPath" type="xs:string" use="required"/>
<xs:attribute name="DataType" type="xs:anyURI" use="required"/>
<xs:attribute name="MustBePresent" type="xs:boolean" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>

Description for the new ContextAttributeId would be: The 
ContextAttributeId selects by the AttributeId an <Attribute> in the 
request context within the <Attributes> element with Category equal to 
the Category of the <AttributeSelector>. The selected <Attribute> MUST 
have datatype urn:..FIXME..:XPathExpression and contain exactly one 
value. The selected XPathExpression is applied with the <Content> 
element in the given category as the context node. The XPath expression 
must select a single node within the <Content> element. This node 
becomes the context node of the RequestContextPath xpath expression. << 
Various error conditions need to be defined as well >>


Note that I think Paul assumes that we have dropped XPathCategory 
attribute of the XPathExpression data type. That is correct if the xpath 
is to be used with the selector since in this case the path is relative 
to a context node defined by the selector. Hoever, if we would have to 
keep the xpath match functions, then the XPathExpression is still 
required since the xpath match function itself does not define a context 
node. (An alternative would be to specify the context node as another 
argument to the xpath node function, and we did in an early draft, but 
this has the problem that the xpath node match functions can no longer 
be used in a target <Match> because of the number of arguments.)

If we find that we need to keep the xpath match functions, we could make 
the XPathCategory optional.

6. I am not sure if I like the name "ContextAttributeId". I can't think 
of a good alternative though. Maybe "ContextSelectorAttribute"?

Best regards,
Erik