IPC WD-04 general comments

["Tyson, Paul H" <PTyson@bellhelicopter.textron.com>]

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