Update to TC on XDI Policy Spec

I’ve really been struggling with XDI Policy. First, I took the policy and link contract pages out of the wiki and created a single document and uploaded the word file to OASIS. Please give me feedback on whether that draft is a faithful merge of the wiki docs and whether you have other comments. XDI Policy needs to be a working draft in June to support implementations of link contracts.

Second, while working on the XDI Privacy Mechanisms specification, which is probably not to be a working draft in June, I identified the need for additional policy expressions, over and above what was in the wiki.

To this point, I’m excerpting from a message thread I had with Markus, Drummond and Peter. Please feel free to chime in.

The net of this thread is consensus not to try to try to solve the full complexity of XDI usage policies by June, but to try and get a basic framework for some simple usage policies.

Drummond, Markus and Peter - have you had the chance to go simple XDI usage policies on the whiteboard this week?

Summary of email thread below.

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Dan:

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Should usage, confidentiality and accountability obligations be expressed as policy expressions embedded with the data, much like timestamps are in some of our examples, new $ words (see below))

· $do-not-collect

· $anonymize

· $do-not-persist

· $expire

· $use-once

· $audit or $log

· $encrypt

Or can link contracts express the obligations implicitly by constraining the permissions they grant.

Markus words this as two alternatives:

1. Store the data use policy in a sub-context of the data it protects. This means that it would be independent of any given link contract.

2. Store the data use policy in a sub-context of a link contract. In this case, it would automatically protect all the data covered by the link contract.

Markus also gave an example (with the obligation highlighted in blue) of a link contract from Markus to Dan that allows you to get my email address, but not copy it:

=dan$to=markus$from$do/$get/=markus<#email>

=dan$to=markus$from$do$if$and/$true/({$from}/$is/=dan)

=dan$to=markus$from$do$if$and/$true/({$msg}<$sig><$valid>&/&/true)

=dan$to=markus$from$do$use$if$not/$true/$copy

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Drummond replying to Dan and Markus

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

I strongly agree that data usage policies SHOULD be expressed in XDI just like any other link contract policy _expression_. After all, that's why we created XDI semantics.

Secondly, I believe there is a key difference between two types of policies:

1. Operational policies are stored in the $if branch of a link contract and evaluated to allow or deny an XDI operation. To date, this is what all XDI policy _expression_ examples have been focused on.

2. Usage policies, which are not evaluated to allow or deny XDI operations but are intended to control usage of the requested data outside the scope of XDI enforcement.

From an XDI architecture standpoint, the key difference is that while the latter need to be expressed in XDI, they are not evaluated in order to allow or deny an XDI operation.

For example, a simple link contract might say the following: You have access to get my phone number...

1. ...IF you are one of my friends...

2. ...BUT

1. You can't use it to call me between midnight and 8AM PT.

2. You can't sell it.

#1 is an operational policy; it is evaluated in order to provide access to XDI data (in this case, a phone number).

#2 is a set of two usage policies that are associated with the requested data but which are outside the scope of XDI to enforce (well, technically, in an all XDI-network, including VoIP connections governed by XDI endpoints, both of these policies could be enforced technically, but the point is that these policies apply to usage of the data whether they are enforced by XDI endpoints or not).

So, my conclusion about usage policies is that they belong in a link contract (or referenced by the link contract), but in a different branch than the operational policies, which live in the $if branch.

Suggestions for the data usage policy branch of a link contract are:

• $for

• $allow

As with operational policies, usage policies could also be expressed in the negative, i.e.:

• $not$for

• $not$allow

For example,you could use the following to express that the data subject to a link contract cannot be sold:

• $do$not$for$sale

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Markus:

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Yes it seems right to consider this a third type of policy.
You didn't mention message policies, they can be supplied by a client as part of a message, to request that the server only execute the message if the policy evaluates to true (conditional message execution).

Syntactically, we have:
$do$if for operational policies (or the collection form of this)
$msg$if for message policies (or the collection form of this)

For this reason, I would argue that data usage policies should also use the $if word. I thought a good candidate would be:
$use$if for data usage policies (or the collection form of this)

And not only that, I think all three kinds of policy should support the same condition and operation words that we have already, e.g. $and, $or, $not, $true, $false. This way, the mechanism for evaluating them would always be consistent.

So your example "cannot be sold" could maybe look like this:

$use$if$not/$true/#sold

As long as this policy evaluates to true, you are still "allowed" to use the data.

Another note: I'm not sure if the data usage policy would always have to be associated with a link contract. As an alternative, you could just allow data usage policies on any arbitrary sub-graph, so they would just cover that sub-graph, independent of whatever link contracts you may have. We also discussed this on the call, but didn't get to a conclusion I think.

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Dan

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Ø Another directional question that Peter and I discussed was how to deal with the full complexity of policy as per XACML. Peter is very deep into this and has sent me a paper to read. He mentioned one challenge: how do you express circumstances where mutually exclusive policies may exist and be dealt with dynamically at runtime? He mentioned policy classes, the application of object oriented concepts I suppose.

Ø I can study all that but it will take a lot of cycles and not just from me. As a practical question of how to allocate our time, the "XACML-level" XDI Policy and XDI Privacy Mechanisms sound decidedly "post-June". That is, we might address some of it, but we can't hope to produce a full-scale implementation-tested solution of all the potential complexities.

Ø So: Should we defer the entire question of "usage policies" to post-June or should we attempt to have some "starter functionality" or "basic groundwork" laid in by June?

Ø Also: XDI Policy is definitely a June spec, but XDI Privacy Mechanisms may have to wait until we have more comprehensive content for it. This and the scope/depth question may be related.

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Drummond

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Yes. Policy evaluation gets wicked complex wicked fast. We really need to apply the 80/20 rule here.

+1 to post-June for that portion of the spec.

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Dan

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Ø Then, do we want just a "place holder" in XDI policy, or do we want enough "usage policies" to at least support the concept of "data by reference" and "contractual anonymity"? That might be the low hanging fruit we could implement ALL the 7 architectural elements of Big Privacy.

Ø Syntactically and semantically it might not be difficult to put a $do-not-copy and $anonymize-this in (you'll have help me understand and explain where it should go). That might get some basic usage policies in place without tackling the "wicked complexity."

Ø A bigger challenge then specifying this is implementing "data by reference" in the business process of relying parties and not making disastrous mistake with bad anonymization.

Ø But I think at least putting the specification in place and doing some kind of reference implementation would let us say that we've provided the big 7. Then we'd just have to be careful how we implement it in the real world.

Ø The risk of doing this 80/20 approach is we could end up with something that's not a fully generalizable solution to usage policies. In that event, we'd have to be prepared to deprecate this and move on to something more sophisticated.

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Drummond

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Agreed. The best way to see if we can get there is to just do it. I'm rooming with Markus this week so let's see how much whiteboard time we can get.

xdi message