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

[Rich Levinson <rich.levinson@oracle.com>]

Hi Erik,

This looks like a good approach to me. This should clear up a bunch
of problems including those in issue 87. My conclusion is that when
XACML 2.0 went out there was some unfinished business having
to do with AttributeSelector and *AttributeDesignator.

AttributeSelector appears to be meant to pull attributes out of the
ResourceContent node, although line 2715 says their location in
the "request context", which I think is a mistake.

The reason I think it is a mistake is because *AttributeDesignator is
already sufficient to pull an attribute out of anywhere in the request
context except the ResourceContent.

Combine this with Erik's analysis that I think is very valuable that
by confining the xpath lookups to the ResourceContent we can
avoid having to reconstruct XML Request documents where they
have been optimized to higher performing formats.

It is unlikely that the ResourceContent data would have been changed
from its original format since it can have any xml format and should
be preserved since there is nothing to be gained by changing it. In fact,
we should probably require that this data be delivered to the PDP in
its original form and not be allowed to be restructured except for
possible compression or encryption while in transit from PEP to PDP.

This provides a nice division of responsibility between xpath lookups
in ResourceContent using AttributeSelector and direct lookups in
the main Request document using *AttributeDesignator.

The only left-over appears to be the somewhat redundant use
of "resource:target-namespace" and "resource:xpath", which team
up to allow a *AttributeDesignator to specify an xpath to an
attribute, again, only sensibly to be located in ResourceContent.
Maybe this provides a way out for systems that do not support
the "optional" AttributeSelector, to be able to xpath into the
ResourceContent.

Bottom line, I think that this collection of stuff, along with
tidying up the examples to match the now clarified intents,
very likely will put things in the shape that the original
designers may have intended, but never quite cleaned
up all the loose ends.

Finally, I suggest we drop the XPointer from the examples.
This appears to me to be a spec that has fallen thru the
cracks as the technology has evolved and really doesn't
appear to be needed for anything anymore, except possibly
some legacy implementations of things that are outside the
scope of xacml. Since the examples are non-normative,
our removal of it from the examples should not cause anyone
to claim that we have broken something that was committed
to work, since there is no commitment in any normative part
of the spec.

    Thanks,
    Rich

Erik Rissanen wrote:
> Hi again,
>
> To clarify the two approaches I suggested below, here are examples. 
> For instance, assume that someone has defined a structured attribute 
> type describing a book, and we have a request like this:
>
> <Request>
>  <Attributes Category="resource">
>    <Attribute AttributeId="resource-id" DataType="book">
>      <AttributeValue>
>        <Book><Title>This is the title</Title><ISBN>123456</ISBN></Book>
>      </AttributeValue>
>    </Attribute>
>  </Attributes>
>  ...
> </Request>
>
> Currently an attribute selector can refer to the isbn number like this:
>
> <AttributeSelector 
> RequestContextPath="Attributes[@Category="resource"/Attribute[@AttributeId="resource-id"]/AttributeValue/Book/ISBN"/> 
>
>
> (The patch is paraphrased and not strictly correct xpath, but you get 
> the idea.)
>
> An expression like this is tricky to handle since the request context 
> might not be in XML form and might be dynamically created by the 
> context handler. The PDP would need to either a) dynamically fetch all 
> possible attributes that could occur in the request context, form an 
> XML document of the request and use a standard xpath implementation, 
> or, b) use a custom xpath implementation which works on the optimized 
> version of the request context and figures out which parts of the 
> request need to be generated given a particular xpath expression.
>
> Now assume that we do not allow reference to the <Attribute> element 
> with the attribute selector and make the <Content> the context node. 
> It would no longer be possible to access the isbn number of the book 
> with an attribute selector. However, the same effect can be achieved 
> by rewriting the policy and/or request.
>
> The first alternative which I suggested is the "explicit accessor 
> function". It means that whoever implemented the Book data type also 
> implements matching and/or accessor functions to refer to the various 
> parts of the book data type. For instance:
>
> <Match>
>  <AttributeDesignator MatchId="book-isbn-equals" ...>
>  <AttributeValue>...
> </Match>
>
> The second alternative is to place the structured data type in the 
> <Content> element (note that the <Content> element is available in all 
> categories, not just resource, in 3.0):
>
> <Request>
>  <Attributes Category="resource">
>    <Content>
>        <Book><Title>This is the title</Title><ISBN>123456</ISBN></Book>
>    </Content>
>  </Attributes>
>  ...
> </Request>
>
> This can the be referenced by an attribute selector (so a bunch of 
> accessor/matching functions need not be implemented). But we still 
> have the benefit that the rest of the request context can be in an 
> optimized/dynamic form, while the content element alone can be held in 
> XML form, for easy reuse of existing xpath implementations.
>
> /Erik
>
> Erik Rissanen wrote:
>> 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
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
> ---------------------------------------------------------------------
> 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