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
|