Re: [xacml] The context node of an attribute selector

[Erik Rissanen <erik@axiomatics.com>]

All,

I got an email from Anne who remembers that the choice of context node 
was made like this to allow references to nodes in regular attributes 
whose values were structured XML.

I would still be inclined to change this since such references could be 
done with explicit accessor functions, or those structured attributes 
could be put in the Content element instead of being "normal" 
attributes. So there is no real loss in functionality.

Regards,
Erik

Erik Rissanen wrote:
> All,
>
> I have question and perhaps a suggestion, depending on how you answer 
> the question.
>
> In XACML 2.0 the context node of the xpath expression in an attribute 
> selector is the <Request> element. Why is it so, rather than being the 
> <ResourceContent> element?
>
> Since it is the <Request> element, it is possible to use the attribute 
> selector to reference the "regular" attributes outside the resource 
> content document. Has this been a design goal?
>
> My concern with this is that I don't really see the need for using 
> attribute selectors for accessing the regular attributes since they 
> can be accessed with attribute designators. But making it a 
> possibility is a problem for an optimizing PDP which does not keep the 
> full request in the form of an XML document. If we don't do deeply 
> arcane analysis of the xpath expression in an attribute selector, 
> potentially an attribute selector could refer to any part of the 
> request document, and the request document has to be instantiated as 
> soon as an attribute selector is used, despite them usually only been 
> used to access the resource content. (Or one has to implement a custom 
> xpath library which works on the non-XML form of the request context.)
>
> This represents quite a significant implementation hurdle and would 
> also slow down a conforming PDP whenever attribute selectors are used.
>
> Was there some major benefit seen from the current functionality, 
> which is seen as more important than these concerns, or is this just 
> something that nobody thought about?
>
> Since we are changing the schema for 3.0, which "breaks" the xpaths in 
> the current policies anyway, I think we should reconsider the context 
> node in 3.0. I would propose that we make the context node the 
> <Content> element and use an XML attribute in the selector to indicate 
> the attribute category of the <Content> element it refers to. Also, we 
> should say that the xpath expression MAY NOT "climb out" from the 
> content element to refer to other parts of the request document. This 
> allows the content to be a stand alone document for optimization 
> purposes and the rest of the request can remain in optimized, non-XML 
> form. (And I can imagine that there are still other kinds of 
> optimizations which can be done once the resource content is decoupled 
> from the rest of the request.)
>
> This would also decouple the resource content from the XACML schema, 
> which would make any future schema change simpler. BTW, if we want to 
> improve this decoupling even more, we might want to disallow 
> referencing the <Content> element name or namespace as well in the 
> xpath expression.
>
> This also has the benefit to make the xpath expressions somewhat more 
> readable since we don't need to "dig in" to the content element using 
> the expression.
>
> Regarding backwards compatibility with 2.0, XACML 2.0 policies and 
> requests would still be interoperable with 3.0 in the manner which we 
> have discussed previously. However, if someone has used attribute 
> selectors to refers to subject attributes for instance, these policies 
> cannot be forward ported to 3.0 using attribute selectors, rather they 
> must be rewritten to use designators instead. However, I don't see 
> this as a major concern.
>
> What do you think?
>
> Regards,
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php