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: 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



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