RE: [xacml] Paul's xpath proposal

["Tyson, Paul H" <PTyson@bellhelicopter.textron.com>]

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.

> 
> 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.

> 
> 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.

> 
> 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.
 
> 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.

> 
> 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.

Regards,
--Paul