XDI TC Notes

Following are the notes of the unofficial telecon of the XDI TC held on:

Date: Monday, 15 February 2016 USA
Time: 10:00AM - 11:30AM Pacific Time (17:00-18:30 UTC)

The TC operates under a standing rule approved 17 July 2008 under which the TC does not hold regular official meetings and conducts all business by electronic ballot only. Unofficial weekly meetings are held to enable discussion among members but no business is conducted nor actions taken.

ATTENDING

Markus Sabadello
Kapil Vats
Les Chasen

REGRETS

Drummond Reed
Phil Windley

Update on Publishing XDI Core 1.0 Committee Specification Draft 01

We will check in with Joseph on the publishing status to get to CSD 01.

https://lists.oasis-open.org/archives/xdi/201511/msg00011.html

We will check in with Joseph next week when he is able to join.

XDI Cryptography Update

Markus can give a report of a call he had with Peter Davis, to ask for input on issues in the XDI Cryptography WD01:

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

Markus reported that he and Peter Davis discussed the following topics:

Graph Normalization: Peter’s advice was that specifying canonicalization (turning an XDI graph into a byte sequence) is always the most challenging aspect of any cryptographic application. Therefore, this part of the spec needs to be as detailed as possible. Our current approach is to serialize a graph in JSON in a deterministic way and then sign the result. Another approach may be to serialize the graph using an algorithm that doesn’t involve JSON serialization and instead operates on the graph structure directly. Markus also asked if there could be any challenges regarding the treatment of JSON data types (use by XDI literals). Peter said he didn’t expect any problems with that.
Cryptographic Algorithms: Which algorithms should be mandatory/optional? Peter suggested a small number of algorithms should be mandatory (e.g. AES plus one Elliptic Curve algorithm), but cryptography should be extensible and additional algorithms optionally supported.
Cryptographic IDs: Peter warned that cryptographic IDs may not be suitable in many situations. The challenge is that if a key has to be replaced, the identifier also needs to be replaced, and therefore relationships break. Markus thinks cryptographic IDs can be useful to identify entities that have no need for long-term relationships, or in cases where relationships can easily be re-established.
Encryption: We also discussed the need to have some parts of a subgraph encrypted (e.g. message body), and some parts not encrypted (e.g. message recipient, or a signature on a message). Markus said this is called “cryptographic scope” in the spec draft, and that it can include any arbitrary subgraph.

Case Study: Parent/Child Messaging + Link Contracts

Kapil, Markus, Les and others at Respect Network have been working on XDI personal clouds for parents and their dependents, and functionality for creating chat connections. Let’s review some use cases from this work, e.g. requesting and approving parent-parent connections, and child-child connections:

https://www.oasis-open.org/committees/download.php/57536

https://www.oasis-open.org/committees/download.php/57535

The purpose of these flows is essentially to request and approve a “connection” (which is represented by two reciprocal link contracts that allow bi-directional communication between endpoints).

We went over the parent-parent and child-child flows, noting that the former consists of 1 request and 1 approval part, and the latter consists of 1 request and 2 approval parts. We noted that in between the request and approval parts, there should actually also be a “view connections” part (i.e. get a list of deferred requests), which is missing/implied in the diagrams.

In addition to parent-parent and child-child, we also discussed parent-child and child-parent connection flows and realized that those would not be completely different but would basically to a large extent re-use parts from the other flows. Kapil suggested that even though these flows are technically different (parent-parent, child-child, parent-child, child-parent), from the user’s perspective there is not much difference, since it is always a “connection request”. Markus agreed and noted that the actual XDI messages for requesting connections are also the same across all the flows. The difference between the flows rather lies in the nature of the link contracts and in who approves connection requests.

Kapil asked if it was possible by a requesting peer to see the connection requests that have been sent. Markus remembered that we came up with a solution for keeping copies of sent messages during the recent 2016-01-25 XDI TC call (see notes here).

In the current parent-parent flow, the steps are as follows 1. Parent1 sends connection request, 2. Parent2 approves. At the end of this flow, a connection request from Parent2 to Parent1 is automatically approved due to a temporary $msg$digest link contract that was set up in the beginning. Kapil coined the term “auto-approve” to describe this pattern.

In the current child-child flow, the steps are as follows: 1. Child1 sends connection request, 2. Parent2 approves, 3. Parent1 approves. We discussed two potential improvements to this flow:

Improvement #1: 1. Child1 sends connection request, 2. Parent2 approves, 3. Child2 approves, 4. Parent1 approves. Markus explained that this can probably be achieved with another level of nested $send messages, i.e. each level of nested message can separately become “deferred” in a graph and then approved appropriately by a parent or child.

Improvement #2: 1. Child1 sends connection request, 2. Parent1 approves, 3. Parent2 approves. In other words, Parent1 has to approve the connection request before it reaches Child2’s endpoint. Markus said this could be done if the initial message from Child1’s agent to Child1’s endpoint gets “deferred” instead of executed immediately, and that Parent1 can approve it then.

This second improvement led to a longer discussion about the link contracts between agents and endpoints. We realized that for most XDI-enabled apps, those agent link contracts would NOT be root link contracts. They would only provide the permissions that a specific app needs, and in some cases decide that messages be “deferred” (as in the child use case). Such more limited app link contracts would be instantiated from a link contract template that will typically be placed in an app cloud.

Les explained that while the above is true for most apps, there will also be administrative apps (“dashboards”, etc.) that will have root link contracts with a graph. Kapil agreed and added that even though such administrative apps have root link contracts, they are still “agents” in the XDI sense, and they are identified by * thing cloud numbers just like any other agent.

We remembered that the “old way” to access a graph with root permissions was for an = entity (person) to operate directly on their own graph using their root link contract and a secret token (password). We realized that this approach is discouraged now since now we have concepts such as agents and app clouds.

NEXT REGULAR CALL

The next call will be the following week at the usual time (Monday 10AM PT). The link to where agenda items can be posted for the next meeting is: https://docs.google.com/document/d/19oDl0lbb56Grehx2a5flZnhrgnua5l8cVvC_dJ8fTXk/edit?usp=sharing