Re: [xacml] The <ResourceContent> element again

[Anne Anderson <Anne.Anderson@sun.com>]

Thanks for the explanation.  I had forgotten about the decision to allow 
documents outside the Request Context.

Regards,
Anne

Erik Rissanen wrote:

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

-- 
Anne H. Anderson               Anne.Anderson@sun.com
Sun Microsystems Labs          1-781-442-0928
Burlington, MA USA