XDI TC Minutes

Following are the minutes of the unofficial telecon of the XDI TC at:

Date: Friday, 27 September 2013 USA
Time: 09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)

ATTENDING

Markus Sabadello

Joseph Boyle

Animesh Chowdhury

Drummond Reed

Dan Blum

Phil Windley

NEWS & UPDATES

Preparations for Fall IIW 2013 (Mountain View Oct 22-24)

We discussed our goals for this conference:

Show our first Working Draft specs (Core and hopefully Messaging)
Show tutorials

Markus’s XDI2 tools
Steve Greenberg Developer's Guide to XDI
Drummond’s Alice and Bob Tutorial (using new graph annotation format)

Summary and pointers at XDI.org site
Flow diagrams of XDI usage

Joseph asked what XDI sessions we were thinking of. Suggestions:

Drummond: Respect Connect flow showing XDI link contract initiation
Steve: Developer's Guide to XDI
Drummond: XDI Tutorial

We can also hold a review of the specs themselves if there is demand.

PRESENTATIONS/DISCUSSIONS

Progress on Working Drafts

Joseph has concluded he doesn’t need a dedicated XML editor; he’s going to be used EMacs. Markus is using Eclipse. Drummond plans to use Oxygen.

Joseph showed an early version of what the formatting in XDI Core will look like:

http://xdi.org/xdi-spec-docbook/xdi/xdi-core-1.0/xdi-core-1.0-wd01.xml

Joseph is going to investigate what will be needed to produce PDF.

Link Contract Review

We continue our discussion of link contracts.

https://wiki.oasis-open.org/xdi/LinkContractPattern

Markus used the XDI2 Local Messenger utility to demonstrate several questions he has had about link contracts.

The first example policy used ({from}/$is/=markus) policy statements to provide the functionality of classic access control lists.

The second example used ({$msg}$secret$token&/$equals/$secret$token&) policy statements. $equals is used because in this policy the comparison is between literal values.

The third example uses the ({msg}$secret<$token><$valid>&/&/true) pattern.

We discussed how this proposed form could be applied to other “implied” or “virtual” attributes of a message, including IP address, HTTPS transport, or valid session.

Some of these would require specific security vocabulary, e.g., $valid or $expiration or $now. Others, such as saving session state, only require evaluating whether a statement exists in the graph or not.

The “Unauthorized $ref Problem”

Work on link contract implementation has surfaced the following problem: If a link contract gives you access to a certain part of a graph, and that part of the graph contains a $ref or $rep equivalence relation, and the target of that relation is not covered by the link contract, what should happen?

For example:

Graph:

([=]!:uuid:1111)/$ref/()

()/$is$ref/([=]!:uuid:1111)

(=demo2)/$ref/([=]!:uuid:1111)

[=]!:uuid:1111+friend$do/$all/[=]!:uuid:1111+friend

[=]!:uuid:1111+friend$do/$get/[=]!:uuid:1111+profiles[<+work>]

[=]!:uuid:1111+friend$do/$get/[=]!:uuid:1111[+invitations]

[=]!:uuid:1111+friend$do/$set/[=]!:uuid:1111[+invitations]

[=]!:uuid:1111+friend$do$if$or/$true/([=]!:uuid:1111/+friend/{$from})

[=]!:uuid:1111+friend$do$if$or/$true/({$from}/$is/[=]!:uuid:1111)

[=]!:uuid:1111+profiles[<+work>]<!:uuid:4444>/$ref/[=]!:uuid:1111+last<+name>

[=]!:uuid:1111+profiles[<+work>]<!:uuid:5555>/$ref/[=]!:uuid:1111+first<+name>

[=]!:uuid:1111+first<+name>&/&/"Demo2FirstName"

[=]!:uuid:1111+last<+name>&/&/"Demo2LastName"

[=]!:uuid:1111/+friend/[=]!:uuid:2222

[=]!:uuid:1111[+invitations]!1/$ref/()

=demo2/$ref/[=]!:uuid:1111

$do/$all/()

$do$if$and/$true/({$from}/$is/[=]!:uuid:1111)

$do$if$and/$true/({$msg}$secret<$token><$valid>&/&/true)

Message:

[=]!:uuid:2222[$msg]!:uuid:3333/$is()/([=]!:uuid:1111)

[=]!:uuid:2222[$msg]!:uuid:3333/$do/[=]!:uuid:1111+friend$do

[=]!:uuid:2222[$msg]!:uuid:3333$do/$get/[=]!:uuid:1111+profiles[<+work>]

[=]!:uuid:2222[$msg]!:uuid:3333/$is()/([=]!:uuid:1111)

[=]!:uuid:2222[$msg]!:uuid:3333/$do/[=]!:uuid:1111+friend$do

[=]!:uuid:2222[$msg]!:uuid:3333$do/$set/([=]!:uuid:1111[+invitations]!1/$ref/())

[=]!:uuid:2222[$msg]!:uuid:3333/$is()/([=]!:uuid:1111)

[=]!:uuid:2222[$msg]!:uuid:3333/$do/[=]!:uuid:1111+friend$do

[=]!:uuid:2222[$msg]!:uuid:3333$do/$get/[=]!:uuid:1111[+invitations]!1

Message Result:

[=]!:uuid:1111+profiles[<+work>]<!:uuid:4444>/$ref/[=]!:uuid:1111+last<+name>

[=]!:uuid:1111+profiles[<+work>]<!:uuid:5555>/$ref/[=]!:uuid:1111+first<+name>

[=]!:uuid:1111+first<+name>&/&/"Demo2FirstName"

[=]!:uuid:1111+last<+name>&/&/"Demo2LastName"

Problem Description:

The first name and last name are returned, even though they are not covered by the +friend$do link contract that is being used. The threat here is that if one has access only to a very limited part of a graph, they might just add a $ref equivalence relation to another part of the graph that they should not be authorized to access.

Is this problem similar to symbolic links in UNIX filesystems?

Proposed Approaches:

#1: Do not process $ref and $rep equivalence relations if their target is not covered by the current link contract.

#1A: Ignore them.

#1B: Or raise a link contract error.

#2: Somehow add semantics to the link contract to specify if and how $ref and $rep equivalence relations should be processed.

#3: Somehow limit the ability to create $ref and $rep equivalence relations in the first place

#3A: Allow their creation only if the creator has access to the target. (Animesh’ idea)

#3B: Only allow the owner of the graph to create them.

#3C: Define a new type of permission, e.g. $set.ref (Andy’s idea)

Thoughts:

Drummond offered the following thoughts:

All forms of equivalence relations have this potential problem. In other words, $is, $ref, and $rep all share this issue.
Equivalence relations within an authority’s own graph are not a problem. The issue only arises when equivalence relations need to cross authorities.
Equivalence relations across graphs controlled by the same authority are not a problem. In fact this functionality is in critical to how pseudonyms work in XDI.
Thus the key issue is equivalence relations that cross graphs controlled by different authorities. In this case, a solution is to specify that such equivalence relations must be authorized by the target authority just like any other operation on the target graph.

The “Unbounded $set Problem”

We ran out of time to consider this issue, which is related to the one above, and will continue discussion of this on the list.

A second link contract issue is this: if a link contract gives you $set access to a very limited part of a graph, you may add an arbitrary link contract to that part of the graph, and in a subsequent message refer to it in order to obtain any desired access to the graph.

For example:

Graph:

([=]!:uuid:1111)/$ref/()

()/$is$ref/([=]!:uuid:1111)

(=demo2)/$ref/([=]!:uuid:1111)

[=]!:uuid:1111+friend$do/$all/[=]!:uuid:1111+friend

[=]!:uuid:1111+friend$do/$set/[=]!:uuid:1111+profiles

[=]!:uuid:1111+friend$do$if$or/$true/([=]!:uuid:1111/+friend/{$from})

[=]!:uuid:1111+friend$do$if$or/$true/({$from}/$is/[=]!:uuid:1111)

[=]!:uuid:1111+profiles[<+work>]<!:uuid:4444>/$ref/[=]!:uuid:1111+last<+name>

[=]!:uuid:1111+profiles[<+work>]<!:uuid:5555>/$ref/[=]!:uuid:1111+first<+name>

[=]!:uuid:1111+first<+name>&/&/"Demo2FirstName"

[=]!:uuid:1111+last<+name>&/&/"Demo2LastName"

[=]!:uuid:1111/+friend/[=]!:uuid:2222

=demo2/$ref/[=]!:uuid:1111

$do/$all/()

$do$if$and/$true/({$from}/$is/[=]!:uuid:1111)

$do$if$and/$true/({$msg}$secret<$token><$valid>&/&/true)

Message:

[=]!:uuid:2222[$msg]!:uuid:3333/$is()/([=]!:uuid:1111)

[=]!:uuid:2222[$msg]!:uuid:3333/$do/[=]!:uuid:1111+friend$do

[=]!:uuid:2222[$msg]!:uuid:3333$do/$set/([=]!:uuid:1111+profiles$do/$all/())

Graph after Message:

([=]!:uuid:1111)/$ref/()

()/$is$ref/([=]!:uuid:1111)

(=demo2)/$ref/([=]!:uuid:1111)

[=]!:uuid:1111+friend$do/$all/[=]!:uuid:1111+friend

[=]!:uuid:1111+friend$do/$set/[=]!:uuid:1111+profiles

[=]!:uuid:1111+friend$do$if$or/$true/([=]!:uuid:1111/+friend/{$from})

[=]!:uuid:1111+friend$do$if$or/$true/({$from}/$is/[=]!:uuid:1111)

[=]!:uuid:1111+profiles[<+work>]<!:uuid:4444>/$ref/[=]!:uuid:1111+last<+name>

[=]!:uuid:1111+profiles[<+work>]<!:uuid:5555>/$ref/[=]!:uuid:1111+first<+name>

[=]!:uuid:1111+profiles$do/$all/()

[=]!:uuid:1111+first<+name>&/&/"Demo2FirstName"

[=]!:uuid:1111+last<+name>&/&/"Demo2LastName"

[=]!:uuid:1111/+friend/[=]!:uuid:2222

=demo2/$ref/[=]!:uuid:1111

$do/$all/()

$do$if$and/$true/({$from}/$is/[=]!:uuid:1111)

$do$if$and/$true/({$msg}$secret<$token><$valid>&/&/true)

Problem Description:

Using the new link contract [=]!:uuid:1111+profiles$do, full access to the entire graph is possible for everyone. The location of the link contract in the graph does not affect the permissions granted by the link contract.

Possible Approaches:

#1: Somehow specify that the location of the link contract in the graph affects the permissions granted by the link contract.

#2: Somehow limit the ability to create link contracts in the first place

#2A: Allow their creation only if the creator has access to the target.

#2B: Only allow the owner of the graph to create them.

#2C: Define a new type of permission, e.g. $set.do

#3: Other ideas?

#4: Drummond’s idea specific to the meta link contract pattern:

What if, instead of the meta link contract pattern looking like this...

<--from-->{$to}$do/<--operation-->/<--to--><--from-->$do

...it looked like this:

<--from-->{$to}$do/<--operation-->/<--to--><--from-->{$do}

In short, we would specify that if a meta link contract target graph ends with the typed variable {$do}, the permitted operation only applies to an instance of the link contract template. So the authorizer can $set an instance of the link contract template, $get an instance (even though they already have a copy), and $del an instance of the link contract template—but that's it.