Rich,
I am having a lot of trouble figuring out what this debate is about. The philosophy of XACML is that the policy author and the PEP must have the same notion about the semantics of Actions and Resources. The entities named in policies must correspond to the enforcement done. The Resource and Action should be the actual resource and action requested by the untrusted party. However the PDP knows nothing about this. It simply performs well defined operations on the available data to calculate a result.
If the PEP knows that a user is going to read and write and wants to find out before the read if the write is going to be allowed, then it can ask for a decision on read and on write. If efficiency is an issue, then this can be done in a single request which will produce a decision for each alternative. (I thought we made this legal in 2.0, but apparently it is at least legal in 3.0.)
If the application logic is such that a user wants to do something which involves either doing foo or bar to Resource X, the PEP can ask for decisions on foo and bar and do whichever one is allowed (or pick one if both are allowed.)
If the policy author wants the rules for reading and writing to be different from the combination of rules for reading and the rules for writing, then she can create a policy with an action like "readwrite" as already noted.
In a file system which uses permission bits, there is a special efficiency to retrieving multiple permission bits, since it costs no more (or perhaps even less) to get several permission bits than to get one permission bit. In XACML there is no such economy and in fact the decision for read and for write may involve completely disjoint policies.
I think the model underlying the UNIX file system permissions is flawed in that it breaks encapsulation and presumes a particular implementation. For example, to create a file you need to be able to write the directory and write the file. I think that enforcement and the attributes referenced in policies should reference the actual requests available to users (programs) of the system. If "create a file" is an atomic operation, then that should be an action, not the underlying primitive operations performed by the OS which might involve reading and writing various data structures invisible to the application.
If you are saying we should be writing more "how-to" documents on XACML, I completely agree. A useful task would be for somebody to scan the xacml-users list and put the interesting questions and answers in the developers guide.
I can offer a comment on the history of deciding not to enforce enumerated Actions on resources by defining Resource types. We had already decided to implement data types and do strict typing on all operators and functions. (A majority, but not initially a unanimous decision.) I think the general feeling was that a second type system would just make things too complex and not add enough value to be useful.
Keep in mind that the core spec only addresses the expression and runtime evaluation of policies. Just because the PDP does not enforce enumerated actions per resource type does not mean that policy authoring tools cannot. I believe a good policy editor can and should be aware of legal actions on a resource type and restrict policies at the time they are created, assuming the information is available to it.
Finally note that the "name" of the Action is not the only possible action attribute. For example, I have argued that the contents of an application request message or the input values to a function or subroutine should be encoded in the request contest as Action Attributes.
Or consider the following use case. In some organization, any Delete action on some class of resources is considered a "dangerous" action and requires approval of an Officer of the Company. Conceivably I could construct a policy referencing the "dangerous" attribute and at runtime the context handler would fetch the attribute value from some repository of action/recource pairs.
In short other than the call for more descriptive documentation, which I agree with, I don't see what the TC is supposed to do here.
Hal
