RE: [xacml] The <ResourceContent> element again

["Daniel Engovatov" <dengovatov@bea.com>]

The issue here is selecting a proper content element without relying on
the document order.   We have a defined semantics on what to do with the
multiple <attributes> elements with the same category - merge attribute
data contained in them.  One can not "merge" <content> elements, so the
path expression would have to rely on the document order (bad idea), or
on some other way to select an "active" <attributes> element - such as
in the case of the multiple resources profile when you would select the
<attributes> with a particular "resource-id" attribute contained in it.
It effectively creates a new request document with only a single
<attributes> element with "resource" category.
It does not seem that we need the "id" attribute in this case,
especially an optional one.   We would need to model some policy use
cases to see how it looks - in particular for the multiple resources
profile.

Daniel.

-----Original Message-----
From: Erik Rissanen [mailto:mirty@sics.se] 
Sent: Wednesday, February 21, 2007 7:29 AM
To: xacml@lists.oasis-open.org
Subject: Re: [xacml] The <ResourceContent> element again

Daniel,

Thanks for the response.

What about the additional functionality which is possible with the id?
The proposal you had earlier said that the id could be some external
document which the PDP resolves in an implementation specific manner. Is
this something we want to keep?

Regards,
Erik

Daniel Engovatov wrote:
> IIRC the idea of "id" was to be able to select a particular <Content>.
> For example for a multiple resources profile, "id" could be equal to
the
> "resource-id" and content could be either selected with a
> /Request/Content[@id = resource-id] path, or better yet - content node
> (the "." in Xpath) could be set to the particular element as a root
for
> selector.
>
> If this is moved back into the <Attributes> I do believe that id is
not
> needed anymore.   I also see no need for more then a single optional
> <Content> element.
>
> One way to make this mess a little bit more user friendly could be to
> introduce an extension Xpath function that selects content for the
> current resource id.   One Can then write
> xacml:resource-content()/my/path[use].
>
> That also reminds me that now XPath2.0 is a W3C recommendation and
XACML
> 3.0 should probably introduce XPath2.0 for selectors, define levels of
> support and define all the necessary environment settings for its use.
> It would probably help if we define type mappings from XPath2.0/Schema
> types into XACML types.
>
> Daniel;
>
> -----Original Message-----
> From: Erik Rissanen [mailto:mirty@sics.se] 
> Sent: Monday, February 19, 2007 11:42 PM
> To: xacml@lists.oasis-open.org
> Subject: [xacml] The <ResourceContent> element again
>
> 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
>
>
>
_______________________________________________________________________
> Notice:  This email message, together with any attachments, may
contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and
affiliated
> entities,  that may be confidential,  proprietary,  copyrighted
and/or
> legally privileged, and is intended solely for the use of the
individual
> or entity named in this message. If you are not the intended
recipient,
> and have received this message in error, please immediately return
this
> by email and then delete it.
>   

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.