Re: [xacml] RE: IPC WD-04 attributes

[Erik Rissanen <erik@axiomatics.com>]

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.
>
>
> -----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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xacml-help@lists.oasis-open.org