OASIS eXtensible Access Control Markup Language (XACML) TC

All,

I am wondering about an issue with XACML 2.0, which I am not sure
whether it is a bug or a feature. :-) I tried to search the email
archives, but I didn't find anything.

The 

Erik,

I think it is a combination of bug and history.

Background for those not familiar with the "scope" Attribute follows. 
It was designed for the case where the requester included a "scope" 
Attribute in the Resource part of the request that had a value of 
"Children" or "Descendants".  That functionality was described in the 
core specification for XACML 1.0, but was moved into the Multiple 
Resource Profile for XACML 2.0.  It is required when a single request 
refers to multiple resources, and thus the results that apply to the 
various resources need to be distinguished.

Now, as to why it is of type "string": scopes of Children or Descendants 
were primarily envisioned for use with requests covering subtrees of an 
XML document, so the individual resources would be identified using 
XPath expressions.  We originally had no XPath-expression DataType, and 
anything that was an XPath expression was expressed using a string 
"interpreted as an XPath expression".  Why this was not made explicit in 
the description of ResourceId is not clear - I think that is the bug.

We should think this through for XACML 3.0, and allow multiple DataTypes 
in a 

Ok, this sounds good to me. I made it issue 77 on the list so it is not
lost.

Regards,
Erik

Anne Anderson wrote:
> Erik,
>
> I think it is a combination of bug and history.
>
> Background for those not familiar with the "scope" Attribute follows.
> It was designed for the case where the requester included a "scope"
> Attribute in the Resource part of the request that had a value of
> "Children" or "Descendants".  That functionality was described in the
> core specification for XACML 1.0, but was moved into the Multiple
> Resource Profile for XACML 2.0.  It is required when a single request
> refers to multiple resources, and thus the results that apply to the
> various resources need to be distinguished.
>
> Now, as to why it is of type "string": scopes of Children or
> Descendants were primarily envisioned for use with requests covering
> subtrees of an XML document, so the individual resources would be
> identified using XPath expressions.  We originally had no
> XPath-expression DataType, and anything that was an XPath expression
> was expressed using a string "interpreted as an XPath expression". 
> Why this was not made explicit in the description of ResourceId is not
> clear - I think that is the bug.
>
> We should think this through for XACML 3.0, and allow multiple
> DataTypes in a