OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only
  • 1.  IPC WD-04 attributes

    Posted 10-10-2011 14:54
    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


  • 2.  RE: IPC WD-04 attributes

    Posted 10-14-2011 21:15
    Regarding IP-Data: I think that this may, in some cases, be the most useful attribute for IP access control decisions. I would rather keep this as a separate attribute but used in conjunction with IP-Type for writing policies. For the sake of simplicity, I believe it is easier to read and understand combinations of IP-Type and IP-Data values, rather than creating separate attributes for each of the IP-Type/Data permutations. Defining the common attributes in a specific domain promotes interoperability, but I don't believe that it is necessary to strictly enumerate and then constrain all possible attribute values. Agreement-Type: Consider a case where you may have multiple agreements between organizations, but you want to restrict access such that certain documents could not be given out only under a PIA. Agreement-Type allows policy authors to write rules in a more generalized way without having to know and list particular agreements. Effective/Expiration-Date: I agree simply using a date function works in many circumstance. However, consider the case where resources are tagged with metadata, perhaps in a situation of a one-time document exchange under PIA. The licensor uses the Effective/Expiration-Dates to signify the validity period to the licensee's PEP/PDPs.


  • 3.  Re: [xacml] RE: IPC WD-04 attributes

    Posted 10-20-2011 07:38
    Hi John, I agree with Paul that the profile should use normal, individually named XACML attributes instead of the ip-data construct. It's much easier to work with XACML attributes in XACML, than to have to do pattern matching or value extraction from an embedded string inside a bag of attribute values. I also agree with you that the agreement type is probably a useful attribute. For instance, it can be used to split up the XACML policy into different types of policies, applying to different types of IP resources. And since different types of IP would have different of attributes, it is useful to first test for the type of IP resource, so you know what other attributes are expected to be present, and how they are used. Best regards, Erik On 2011-10-14 23:14, Tolbert, John W wrote: Regarding IP-Data: I think that this may, in some cases, be the most useful attribute for IP access control decisions. I would rather keep this as a separate attribute but used in conjunction with IP-Type for writing policies. For the sake of simplicity, I believe it is easier to read and understand combinations of IP-Type and IP-Data values, rather than creating separate attributes for each of the IP-Type/Data permutations. Defining the common attributes in a specific domain promotes interoperability, but I don't believe that it is necessary to strictly enumerate and then constrain all possible attribute values. Agreement-Type: Consider a case where you may have multiple agreements between organizations, but you want to restrict access such that certain documents could not be given out only under a PIA. Agreement-Type allows policy authors to write rules in a more generalized way without having to know and list particular agreements. Effective/Expiration-Date: I agree simply using a date function works in many circumstance. However, consider the case where resources are tagged with metadata, perhaps in a situation of a one-time document exchange under PIA. The licensor uses the Effective/Expiration-Dates to signify the validity period to the licensee's PEP/PDPs.