[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]