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