This is to focus discussion on the proposed IPC attributes about which agreement has not been reached. See [1] for previous attribute discussion and [2] for discussion of general approaches that will determine requirements for IPC attribute vocabulary. Attribute "...resource:ip-data": Apparently the value of this attribute will be a colon-separated string consisting of an attribute name and corresponding value. Furthermore, the range of ip-data attribute names will not be specified in this profile, but will be agreed upon by coordinating parties, or standardized within an enterprise. I don't think this is a useful feature to standardize. Nothing in the profile prevents companies or coordinating parties from using other XACML attributes to carry information about resources. It would set a precedent for using attribute values with a peculiar syntax, which I do not think is warranted or desirable. (There is already XML available for complex attribute values.) Instead of the generic "ip-data", why don't you just propose full-fledged XACML attributes for the desired data? For example, the concept of "author/creator" is already fairly well represented by the Dublin Core "creator" attribute ("
http://purl.org/dc/terms/creator" ;). DC and other XML or RDF vocabularies could be tapped for additional common attributes relevant to the IP domain. Attribute "...resource:ip-agreement-type": I still need to see an example of a policy and a request context where this makes sense. Consider the two basic approaches described in [2]. If we are using the "first-person" approach, by which agreements become XACML policies, then this attribute is superfluous. If we are writing "third-person" policies that refer to IP agreements, then the authorization is determined by the agreement itself, not by its type. (Or else the semantics of "...resource:ip-agreement" are not as I expected.) Also, how do you account for the common case where several agreements pertain to the same subject or resource? ip-agreement-type is properly an attribute of the IP agreement--not of a XACML resource or subject. By convention, you could make it a resource attribute, meaning "this resource is covered by an ip agreement of this type". Attributes "...resource:effective-date" and "expiration-date": As with ip-agreement-type, these are attributes of an IP agreement, not of a XACML resource. There could be multiple agreements that apply to a single resource, and they could all have different dates. It would be difficult to keep this all straight in a XACML request context. If you are going to use "third-person" policies for IP agreements, you need to arrange your attribute finder to only return ip-agreement values that are currently valid. If you are writing "first-person" policies based on the actual agreements, then you simply include a test against current-date in the target match conditions. Regards, --Paul [1]
http://lists.oasis-open.org/archives/xacml/201109/msg00033.html [2]
http://lists.oasis-open.org/archives/xacml/201110/msg00006.html