Re: [xacml] Paul's xpath proposal

[Erik Rissanen <erik@axiomatics.com>]

Hi Paul,

See comments inline.

On 2009-12-04 15:50, Tyson, Paul H wrote:
> Erik, thanks for your review and comments.  See inline and revised page
> at http://wiki.oasis-open.org/xacml/XpathDiscussion?rev=3.
>
>    
>> -----Original Message-----
>> From: Erik Rissanen [mailto:erik@axiomatics.com]
>> Sent: Friday, December 04, 2009 06:02
>> To: xacml
>> Subject: [xacml] Paul's xpath proposal
>>
>>
>> 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.
>>      
> But that would also allow Attribute children in the general category,
> and I don't know what those would mean in XACML.  If you're going to
> allow uncategorized attributes, why specify any categories at all?  It
> seems easier to use schema control by doing it as I propose, even if it
> means that Content/@Category really only means anything on
> Request/Content elements.
>    

Yes, it would allow attributes in the general category, but I don't 
think this is a serious problem.

You are right that categories are not really needed in the strict sense. 
You could in principle put everything in a single category and assume 
that the policy matches that, it work fine for evaluating the request.

The reason to specify the categories are:

1. It helps to keep policies clean and tidy.

2. It's necessary for "boxcarring" multiple requests. (If you cannot 
tell what is the subject and what is the resource, you need to repeat 
the subject attributes as well.)

3. The PDP can work more efficiently when it knows that certain 
attributes are related. This improves performance.


>> 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.
>>      
> I revised wiki page to include an example.  I do not have any real-world
> experience with this use of XACML, but I believe if anyone presented a
> use case for the XACML xpath-* functions I could rewrite it using native
> xpath expressions and the proposed content-selector attributes.
>    

I don't think your example works as you intended it. The attribute 
selector (at least in 2.0, and it did not change in 3.0) is defined such 
that it will take the textual representation of the selected node and 
use that in the constructor function of the given data type. The 
contructor function is defined to be the same as the cast function in 
XPath/XQuery. So, an attribute selector for a boolean is looking for 
string values such as "true" and "false". You cannot use it test whether 
a node set is empty or not. xs:boolean() is not the same as fn:boolean().

(The reference to XQuery was updated to the final version in XACML 3.0, 
so it is possible that functions have been renamed in XQuery so the 
refernce is broken. We have to check this.)


>> 3. I think the IncludeInResult attribute can be inherited
>> from the multiple:content-selector attribute, rather than
>> always be true.
>>      
> Yes, but I can't imagine what good a Decision would be if it did not
> mention what the decision was about.  I guess we could leave it up to
> the application to make that mistake.
>    

The application could perhaps simply want to combine the individual 
results into a joint decision, without caring which decision relates to 
which resource.

>> 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.
>>
>>      
> I haven't worked this out completely.  Originally I thought it would
> meet the need that XPathCategory now meets.  We'll need to analyze more
> use cases to determine this.
>    

Yes, at least I need to think this through at least once more. But I 
think you got it right. The XPathCategory is not needed for a "relative 
xpath",that is an xpath which is applied in a given context, such the 
attribute selector. However a "stand alone xpath" needs it. An example 
would be the xpath match function, where the function itself does not 
define the context node.


>
>    
>> 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>>
>>      
> Yes, that's about it, except ContextAttributeId should be optional.
> (Default context is the anonymous "root" represented by the Content
> element.)
>
>    
>>
>> 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.
>>      
> I'm not sure about XPathCategory.  More analysis is required.  I
> definitely do not believe the xpath-* functions are useful.
>    

I think the xpath functions do something completely different than the 
selector and I think the example you gave was mistaken.

And if we drop then, we should translate each of the dropped functions 
into their equivalent selector form so we know we did not drop anything 
significant.

>> 6. I am not sure if I like the name "ContextAttributeId". I
>> can't think of a good alternative though. Maybe
>> "ContextSelectorAttribute"?
>>      
> Yes, that might be better.
>    

Still not happy myself. Bill, you are usually good at making up names. 
Any ideas? ;-)

Best regards,
Erik

> Regards,
> --Paul
>