Re: [xacml] Paul's xpath proposal

[Erik Rissanen <erik@axiomatics.com>]

Hi Paul,

I gave it some more thought. Your example can probably be fixed by 
casting the xpath boolean value type into a string representation within 
the xpath expression. But I don't know the syntax myself, and I am not 
sure it is available in xpath 1.

Best regards,
Erik


On 2009-12-04 10:29, Erik Rissanen wrote:
> 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
>