Specifying a specific associated Resource in a Policy

[Hal Lockhart <hal.lockhart@oracle.com>]

The idea I raised on the call last week was to profile a way of specifying that the resource which the policy applies to is not at a fixed location, but is the document or other information object that the policy is associated with or attached to. In recent years I have heard of a number usecases for which this might be useful functionality.

1. One obvious case is where a condition of obtaining the information object and potentially distributing it to others is that the requesting party agrees to enforce some access control policies relating to the object. Typically this is for privacy reasons, but it does not have to be. 

2. Another case is where the information object is being transferred from one server to another within a domain and there is a desire to maintain the "same" policy wherever it is located. However, the source may not know what name the resource will be given on the other server.

Notice that both of these cases are essentially an administrative transfer of policy information, which in principle could be accomplished by transferring policy via some other channel. In both cases, I assume the policy will not be evaluated as is, but will be modified to incorporate the local name or other attributes of the resource before the policy is used by a PDP.

The usecase I am not sure is real is one of directly evaluating such an associated policy. It seems to me that inevitably in the context of an access control request the requester and PEP will need to identify the resource in some way which distinguishes it from all other resources protected by that PEP. Although XACML policies can be evaluated which only specify the resource by means of non-unique attributes, it seems to me that in all of these cases, the goal is to transfer policy which applies to the particular object, not a class of objects with the same properties. 

During the call, Greg pointed out that the sticky policy requirement for PII (usecase #1) may include policies which are outside the scope of the XACML Access Control Architecture. For example, the source might require any party distributing the data to display some logo. This is true and would have to be handled by means of Obligations or Advice values, the implementation of which is outside the scope of XACML, as has been the case all along.

However, it did occur to me afterwards that Greg's example, "destroy the data after 30 days" which is certainly a commonly cited requirement, might in fact be handled via enforceable policy. If the policy was rigorously enforced and contained a condition that the access not be after a certain date (30 days hence), then it seems to me that the desired intent would be met. The actual removal of the data could be viewed as a matter of system maintenance (garbage collection). I realize there is an issue of exposure to unauthorized access, but I wonder in practice whether parties who agree to "destroy" the data simply remove it from their online system or locate and scrub every backup copy. In other words, I am suggesting that "destroying" the data actually represents a spectrum of possible actions, not a binary condition.

What I suggested on the call was that we simply profile an identifier such as urn:oasis:names:tc:xacml:1.0:resource:associated to somehow indicate that the resource is the information object associated with (attached to) the policy. I have not really thought out whether this would be an attribute id or a value of the resource-id or some other attribute. I am not suggesting that we provide for a signature to bind the policy to the object as it seems that this will tend to be specific to the object type and in many cases the issue of how to include metadata (such as policy) and sign over it is currently being addressed by standards activities specific to the information object type. (e.g. PDF, ODF)

Since the usecases imply that the attached policies will not be directly evaluated, but that local information will be added, perhaps this profile is not needed. Perhaps it would be sufficient to omit any mention of the resource in the policy. This would be understood to indicate the associated object, the name or other properties of which would be added later.

Assuming we use the identifier, the question arises as to how to evaluate a policy which contains the associated resource identifier as well as other attributes. One approach would be to prohibit such a construct or perhaps simply ignore the other attributes. For consistency with the XACML policy evaluation algorithm, I suggest that such attributes simply be treated as additional conditions to applicability. It might be useful to construct a sticky policy that says the associated data may only be accessed for the purpose of medical research and only if the data is marked as public. Presumably, in the absence of other policies, if the object was not marked public the policy would evaluate to not applicable and the request would be rejected.

What do other people think about any of these issues?

Hal