RE: [xacml] Issue 40: <ResourceContent> element

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

Would not it be more natural to change the multiple resource profile to
include multiple requests, rather then multiple instances of the same
resource category?

For example if you want to represent your "resource" with two categories
- for example "static-resource-attributes" and
"dynamic-resource-attributes", coming from different paths, you would
have to choose which one would contain your "content".  Also, for most
attribute categories, content is an evil construct, that goes against
the whole idea of representing evidence in the context as a bag of named
attributes, rather then an opaque XML "any" object.

So, maybe we should go and create a top level <Requests> element, that
contains multiple requests, to use in the multiple resources profile?

Daniel.

-----Original Message-----
From: Erik Rissanen [mailto:mirty@sics.se] 
Sent: Friday, February 02, 2007 6:17 AM
To: xacml@lists.oasis-open.org
Subject: [xacml] Issue 40: <ResourceContent> element

All,

I've been editing the 3.0 core and I have found a small problem with the
proposal Daniel made for the ResourceContent element. See issue 40 on
the issues list.

If I understand the proposal correctly, the <ResourceContent> element
which used to be in the <Resource> element of the request context is
replaced with a number of <Content> elements directly in the <Request>
element.

This is not quite backwards compatible with 2.0 and the multiple
resources profile. The multiple resources profile allows multiple
<Resource> elements, which may contain <ResourceContent> elements:

<Request>
...
<Resource>
...
<ResourceContent>...</ResourceContent>
</Resource>
<Resource>
...
<ResourceContent>...</ResourceContent>
</Resource>
...
</Request>

If we follow the current proposal, this becomes:

<Request>
...
<Attributes Category="...:resource>
...
</Resource>
<Attributes Category="...:resource>
...
</Resource>
...
<Content>...</Content>
<Content>...</Content>
</Request>

and the connections to the specific resources are lost. Instead I
suggest that we place the <Content> element inside the <Attributes>
element:

<Request>
...
<Attributes Category="...:resource>
...
<Content>...</Content>
</Resource>
<Attributes Category="...:resource>
...
<Content>...</Content>
</Resource>
...
</Request>

In this case it is simpler to provide backwards compatibility.

BTW, talking about backwards compatibility of attribute selectors,
translating 2.0 policies into 3.0 means rewriting the xpath expressions
in attribute selectors since the <Resource> element is now called
<Attributes>. Are there any concerns about this? For simple expressions
it is obvious how to do it, but what about in general?

Another minor issue is that the schema which Daniel wrote earlier does
not allow anyAttribute on the Content element, which the old one did.
This could be a problem with backwards compatibility, so I suggest we
allow that.

Finally, I think the examples in the 2.0 spec are wrong. On page 31,
line a217 the xpath expression looks like
"//xacml-context:Resource/...."
while it on page 34, line a290 looks like "//md:record/...". As far as I
can tell, the latter is wrong. Right?


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