Hi Bill, et al,
I am not sure I am following the argument. If I removed the comma or replaced it with a slash or dash would that address the concern?
Basically, I am saying in the simplest case, let's take simply file read and write that there are 3 possible "services" that can be offered (possibly a different rate is charged for each):
As described in previous email, each time a new file is selected, the user picks the desired service level and hits submit. The policy determines if the user has been granted access to that file at that level of service.
If so, then the user is presented with the appropriate form for using the service, which only has 2 operations: read and/or write. Each time the user requests one of the operations the policy determines if they have that access (and they are charged a usage fee).
There are no compound operations. It is simply specify the service you want, then if you get it, use the service.
The fact is that a file is a more complicated resource than just the number, n, of possible discrete "runtime" operations you can perform it. When a real file system is used each file has potentially n**2 - 1 "modes" in which it can be initialized prior to providing "runtime" access. The problem I have seen using XACML is that attempts have been made to provide access to these actual n**2-1+n discrete operations (or actions) using only n actions.
I believe my proposal is simply addressing the reality of the problem by enabling the ability to express the options that are physically available, and doing this in a manner where a user specifies the exact action they are going to use at the time they are about to use it and nothing more.
Comments?
Thanks,
Rich
Bill Parducci wrote:
FF1E46C5-E8E5-49FF-B6FD-7AF53B68EB74@parducci.net" type="cite">Rich,
I think that it does introduce complexity in that once compound actions are introduced the relationship between them is ambiguous unless further machinery/description is also introduced to handle it. The comma used in "read,write" lacks referenceable meaning in the current specification and therefore lends itself to open interpretation. In general we have always tried to avoid this type of situation because it tends to lessen the chances for interoperability.
Therefore I would offer that is not just a complexity/performance issue. One could argue that the TC doesn't dictate attribute values, however it seems to me that there is merit in discouraging the creation of non-normative syntax for creating compound attribute values, particularly since there seems to be a viable alternative at hand that provides the desired functionality.
b
On Sep 18, 2008, at 10:31 AM, Rich.Levinson wrote:
Hi Erik,
I agree there are multiple ways to address the problem. Personally, I do not believe the approach I have suggested necessarily results in any significantly increased complexity.
However, I do not think that can be the basis for how the TC presents its recommendations and guidelines. For example, the fact that the whole policy structure and requests and responses are written in the spec in xml does not constrain the implementor to use xml at all, as I understand it.
It is very possible that different implementation technologies lend themselves to more or less efficient policy processing depending on how one writes the policies. Just because an XML representation of a Policy is complex doesn't mean that the underlying implementation of that Policy necessarily has to be complex.
Thanks,
Rich
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php