OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] Resource id attribute in response


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 <Result>.  That would either require an additional XML
> attribute to specify the DataType by which the string ResourceId is to
> be interpreted, or else we need to move ResourceId into an element in
> the Result that can have its own DataType, like an Attribute.
>
> My $.02.
>
> Regards,
> Anne
>
> Erik Rissanen wrote:
>
>> 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 <Result> element contains an optional XML attribute called
>> ResourceId of type xs:string. But, what if the resource id is some other
>> data type, for instance a structured type? It won't work in this case.
>> Is this by design, or is it a bug?
>>
>> Regards,
>> Erik
>>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]