RE: IPC WD-04 general comments

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

I like the "first-person" and "third-person" analogy.  With the changes in the latest working draft, I believe that either approach could be implemented.  We've tried to include all the possible attributes that may need to be considered in IP access control decisions.  Given that organizations wishing to employ a federated authorization model will arrive at a set of attributes through a process of both legal and technical negotiation (much like we have been doing with SAML for years), having a range of attribute choices should allow policy authors the flexibility to build policies as needed, but still promote interoperability.  The agreement itself can be referenced, or it can be omitted (optional attribute as defined in the conformance section).  

In some industries and for some use cases, IP agreements may be volatile.  However, there are many cases where agreements are long-term and routinely renewed, thereby decreasing volatility.  Standardizing attributes and the access control model should facilitate the construction and deployment of enterprise IP access control and audit policies.  I don't believe that possible complexity and volatility should prevent us from codifying the attributes and model.  As for the robustness of the enterprise attribute environment, I am certain that most organizations will have to improve in this area, not only for implementing an XACML-based access control system, but also just to provide better protection for their intellectual property.  This profile can assist in those efforts by providing a standard taxonomy to guide access control system architects, policy authors, IP-owners, IP-designees, etc.

-----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 6:40 AM
To: xacml@lists.oasis-open.org
Subject: [xacml] IPC WD-04 general comments

This is to start a clean thread on the intellectual property control WD.
See [1] for link to document and [2] for previous comment thread.

First to answer John's questions about the diagram in Figure 1 of the
profile.  John asked:

"What type of contract is Contract-0001 and what IP does it transfer?
What IP does PIEA-0001 cover?  Is there an agreement between Org-0001
and Org-0004?  What is the relationship between Org-0003 and Org-0004?
What does "hold" mean?  What subject attributes do users A-E have?  Are
documents 1-5 tagged with resource attribute metadata?"

The diagram is a template, or stereotype, representing many possible
scenarios.  The details will vary, but we want a standard that will
accommodate a reasonable degree of variation.  I meant this diagram to
illustrate two main points:

  1. There are many other entities and relationships involved in IP
decisions than can be easily represented in a XACML request context.
  2. All IP decisions are governed by some type of legal agreement
between parties.

Therefore a XACML profile for IP protection must provide for the
consistent and unambiguous representation of complex entity
relationships in the XACML request context.  And it must particularly
provide for the representation of IP agreements and their relationships
to XACML subjects, resources, and actions.  (By "agreement", I mean any
business document that can be construed to authorize any use of IP by a
party other than the owner--to include contracts, PIAs, licenses, etc.)

Regarding the last point, it seems to me there are two basic approaches
to representing an IP agreement in XACML.  One approach translates the
agreement directly into a XACML policy.  In this case the agreement
itself never appears in the XACML request context.  The conditions in
the agreement are translated to conditions on the subject, resource, and
action attributes.  In this case it does not make sense to have a
condition or match on the ip-agreement itself--that would be like saying
"this rule applies to all resources covered by this rule".  To use a
literary analogy, this is writing policies in the "first person".

Alternatively we could write policies in the "third person".  In this
approach, ip-agreements are entities that can be represented in the
XACML request context.  Using this approach, you could write a rule like
"if the subject is covered by ip-agreement X and the resource is covered
by ip-agreement X, then Permit"  (or, more generically: "if the subject
and resource are covered by the same ip-agreement, then Permit").  Of
course, any variation involving further attribute conditions could be
used.

The first approach--direct translation of IP agreements into XACML
policies--is the best way to maintain clear connections between your
XACML policy set and the governing business documents.  However, there
are two potential drawbacks: first, the volatility of IP agreements can
stress the digital policy management process; second, IP agreements may
resist translation to specific attribute conditions, either because the
enterprise attribute environment is not robust enough, or because the
authors of the agreements take no heed of implementability.  In the
ideal environment, both of these deficiencies would be mitigated in
order to support XACML policies that directly represent IP agreements.

The 2nd approach may be easier to implement initially, but at the cost
of muddying the reasons for control.  Overall, this approach will
require much more maintenance and coordination between policy authors
and attribute providers.  It tends to hide important business rules in
code (e.g., exactly *why* is a particular resource covered by a
particular IP agreement?).

I will start another thread to continue the discussion of particular
attributes proposed by the IPC profile.

Regards,
--Paul

[1]
http://www.oasis-open.org/committees/download.php/43459/xacml-3%200-ipc-
v1%200-spec-wd-04-en.docx
[2] http://lists.oasis-open.org/archives/xacml/201109/msg00033.html


---------------------------------------------------------------------
To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xacml-help@lists.oasis-open.org