OASIS eXtensible Access Control Markup Language (XACML) TC

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 

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 

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:



Currently an attribute selector can refer to the isbn number like this:

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:
>
> 
>
> Currently an attribute selector can refer to the isbn number like this:
>
> 

Hi Rich,

See some discussion inline.

Regards,
Erik

Rich Levinson wrote:
> 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.

Line 2715 is not a mistake. According to Anne it is a deliberate design 
choice to allow pulling of attributes from the full request context. 
This is made to support easy access to attributes consisting of 
structured XML. Basically it's a form of syntactic sugar. However, I 
don't think it was realized that this makes strict conformance with the 
spec difficult unless the request context is kept in XML form at all 
times. So I think we should change this.

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

Exactly. This separation allows for easier optimization of the 
*Designator part. Without this separation, it's very complex to do 
optimizations.

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

The resource:xpath attribute does provide a different kind of 
functionality than attribute selectors.

With attribute selectors you can write a policy which allows/denies 
access if the resource content document contains some particular values. 
For instance, "allow access if the medical record