Re: [xacml] The <ResourceContent> element again

[Erik Rissanen <mirty@sics.se>]

Anne,

I interpreted Daniel's proposal to mean that the xpath expression is
applied at the element with the id, not at the request element. See the
text on issue 40 in the issues list:

---8<---
40. Change ResourceContent

Daniel's proposal: When looking at the generalizing the request schema
as required by Issue#3, I could not find a good place for the existing
ResourceContent context element. Adding schema restrictions for a
particular context attribute category seems to be not a very elegant
solution.In any case – existing way to provide an arbitrary XML context
document inside an element of “any” type does not seem to be optimal.

I suggest:

1. Modify XACML processing model to allow a single arbitrary XML
document to be submitted along with the Request in an implementation
defined way.

2. Modify the AttributeSelectorType and add an optional “ContentURI”
attribute, of type xs:anyURI with a default value of
urn:oasis:names:tc:xacml:3.0:requesturn

This attribute will be used in the following way

1. It identifies document node for the path expression in AttributeSelector

2. Default value is the URI for the request document – default behavior
would be exactly as it is now

3. If an additional document is present in the request this URI resolves
to that document, so the path expression in the selector applies to it.
In this case you can not use the AttributeSelector to select individual
attribute values, but that would be redundant to AttributeDesignator
anyway. An alternative would be to have two reserved URI – for the
request, and for the submitted document.

4. If any other URI is used in the policy, it should be resolved in an
implementation dependent way. That may allow to use an AttributeSelector
to extract values from different documents.

So the main point is to replace the existing ResourceContent with a
separate document, and to allow AttributeSelector to identify document
uri, with default behavior remaining the same as it is now.

20 July 2006 meeting recommendation: Request will be extended to contain
optional sequence of <Content> elements, each with a required XML
attribute specifying a unique URI identifying that content. A <Content>
element can arbitrary XML content, which may be equivalent to the
current ResourceContent, or may be XML elements that contain information
regarding any entity (category) in the Request - essentially, XML-valued
Attributes. AttributeSelector will select the unique URI and then
provide a path to the desired information in the XML content.
---8<---

I particular, note the last sentence. This is the functional requirement
I intended. Yes, you are right that the right Content can be selected by
the xpath expression itself, but I thought people wanted this syntactic
sugar, which would mean a shorter xpath expression.

I didn't want to deviate from this since it was decided during a TC call
in July that we should implement it.

Maybe I misunderstood it?

However, I think Daniel expressed an opinion recently in an email to the
list that the id is not useful anymore since we move the <Content>
inside the <Attributes> element. I think draft 1 of the core still has
the id since the matter hasn't been resolved finally yet.

Daniel's email:
http://lists.oasis-open.org/archives/xacml/200702/msg00047.html

Regards,
Erik

Anne Anderson - Sun Microsystems wrote:
> Erik,
>
> I did not understand why "It is a functional requirement that the
> <AttributeSelector> searches the request for the id elements." I can
> understand that the XPath expression in the AttributeSelector may
> reference the id element, but that is not a functional requirement for
> AttributeSelector, just the meaning of the XPath expression.
>
> Regards,
> Anne
>
> Erik Rissanen wrote On 02/20/07 02:41,:
>> All,
>>
>> I moved the element formerly known as <ResourceContent> inside the
>> <Attributes> element and added anyAttributes to it, to make it backwards
>> compatible, as discussed during the meeting.
>>
>> There is one small issue still which I encountered. According to
>> Daniel's proposal, the <Content> element contains an XML attribute
>> called "id" which is required. An attribute selector may use this
>> attribute to refer to the <Content> element. There was no such id
>> attribute in 2.0, so I made it optional, or otherwise, when translating
>> 2.0 policies, we would have to generate dummy ids which won't be used,
>> which is a bit ugly in my opinion.
>>
>> Another thing I was thinking about: Should we allow multiple <Content>
>> elements in a single category? In 2.0 only one <ResourceContent> element
>> was allowed. If we allow only one <Content> element, now that the
>> <Content> element is inside the <Attributes> element, it is identified
>> by the category of the <Attributes> element, so the id attribute is not
>> really needed. (Thought it is still useful in the attribute selector, to
>> select a document from an implementation specific source, as proposed by
>> Daniel.) Actually, it is strictly not needed in any case, since it is
>> possible to match on any XML attribute in an XPath expression.
>>
>> For now I am writing it so only one <Content> element per <Attributes>
>> element is allowed and the id attribute is optional. It is a functional
>> requirement that the <AttributeSelector> searches the request for the id
>> elements.
>>
>> Let me know if you disagree.
>>
>> Regards,
>> Erik
>>
>>
>