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.
-----Original Message-----
From: [mailto:] On Behalf Of Tyson, Paul H
Sent: Monday, October 10, 2011 7:54 AM
To:
Subject: [xacml] IPC WD-04 attributes
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
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
