RE: IPC WD-04 attributes

["Tolbert, John W" <john.w.tolbert@boeing.com>]

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: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Tyson, Paul H
Sent: Monday, October 10, 2011 7:54 AM
To: xacml@lists.oasis-open.org
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: xacml-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xacml-help@lists.oasis-open.org