XDI TC Minutes

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

Date: Friday, 24 January 2014 USA
Time: 09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)

ATTENDING

Markus Sabadello
Peter Davis
Animesh Chowdhury
Joseph Boyle
Les Chasen

REGRETS

Drummond Reed
Dan Blum

GUESTS

AGENDA

NEWS & UPDATES

Non scheduled.

PRESENTATIONS/DISCUSSIONS

The “Unauthorized $ref Problem”

Markus felt that this problem was sufficiently solved by stating that $ref/$rep arcs can always be followed, independently of the permissions on the target address of an arc, and that link contracts would play no role. Instead, all security would be implemented when $ref/$rep arcs get added to a graph in the first place.

Peter added an interesting perspective by proposing that link contracts could state whether $ref/$rep arcs can be followed or not, or even that some may be followed and some may not, depending on their target address.

#MARKUS to create a proposal on the TC wiki for these idea, or incorporate them into an existing proposal

The “Unbounded $set Problem”

Markus proposed that a possible solution to this problem could be to establish a few fundamental rules, such as completely restricting the creation of link contracts and $ref/$rep arcs to whoever is authoritative for a given graph. Peter felt that this was too restrictive, e.g. this would not support a “power of attorney” use case where a parent might manage a child’s graph.

After some discussion, we agreed that the solution would most likely be built around specialization of the $set permission. This is something we have considered several times before. For example:

- $set allows the creation of any kind of contexts and literals, except for link contracts and $ref/$rep arcs.

- $set{$do} allows the creation of link contracts.

- $set{$ref} allows the creation of $ref/$rep arcs. The permission would have to be granted both on the source context node and the target context node of the arc.

#MARKUS to create a proposal on the TC wiki for these idea, or incorporate them into an existing proposal

“Forwarding” of Messages by a Server

If the “to” peer root of a message does not match the peer root that is authoritative for the graph the message is sent to, the message can be “forwarded” to the authoritative server for the peer root. See the following two lines from the XdiMessagePatterns page:

#1: FROM <--from-peer-->/$set/<--from-->[$msg]<--msg-id-->
#2: TO <--from-->[$msg]<--msg-id-->/$is()/<--to-peer→

We agreed that this functionality can only be triggered if the “from” peer root of the message is authoritative for the graph. For example, Alice’s XDI endpoint will only “forward” messages sent by Alice.

The general flow would be as follows:

1. Alice’s XDI client sends a message to Alice’s XDI endpoint, with Bob as the “to” peer root.

2. Alice’s XDI endpoint processes the message. Since the “from” peer root is Alice, and the “to” peer root is not Alice, the forwarding functionality will be triggered. XDI Discovery is used to find Bob’s XDI endpoint. Before forwarding the message, Alice’s server may process it in certain ways, e.g. add a signature to it.

3. Bob’s XDI endpoint executes the message and returns a message result to Alice’s server.

4. Alice’s XDI endpoint returns the message result to Alice’s client.

Peter commented that in step 3, Bob’s server may have to ask for explicit consent from Bob’s client (this would require some kind of asynchronous variation of the flow).

One open question seems to be the role of link contracts in steps 2 and 3. Would the XDI message need 2 link contracts (one for Alice’s XDI endpoint and one for Bob’s XDI endpoint)?

#MARKUS to create a proposal on the TC wiki for these idea, or incorporate them into an existing proposal