OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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,

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

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.


[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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]