XDI TC Notes Unofficial Telecon Monday 2016-01-25

[Markus Sabadello <markus.sabadello@xdi.org>]

XDI TC Notes

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

Date: Monday, 25 January 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

Drummond Reed
Les Chasen
Markus Sabadello
Joseph Boyle
Kapil Vats
Phil Windley

Update on Publishing XDI Core 1.0 Committee Specification Draft 01

We invited Chet to join the call but he responded to an email this morning that he had reviewed the revised XML document and he was satisifed that everything had been dealt with, so he was going to proceed to publish.

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

Joseph noted that in the final version he sent Chet, the SVG images did not render properly, so he is fixing that.

# ACTION ITEM: Joseph will send updated SVGs to Chet.

XDI Messaging and XDI Link Contracts

Markus is working on updated versions of both of those. For Messaging, it will be Working Draft 05. He is doing the work in a branch of our Github repository.

https://github.com/OASIS-XDI-Technical-Committee/xdi-spec-docbook/tree/markussabadello

Update on XDI Messaging Use Case Implementation

Markus will update the TC on XDI2 documentation of the messaging scenarios that have been implemented:

https://github.com/projectdanube/XDINinja-swing

This covers four flows:

1. Request Connection to Profile

2. Invite Connection to Profile (Manual)

3. Invite Connection to Profile (Auto)

4. Request Bi-Directional Chat

For each one of these flows, an architecture diagram, sequence diagram, and walkthrough are provided, as well as the implementation.

Markus raised the question of whether the terms “uni-directional” and “bi-directional” should be in the link contract spec.

He also suggested that one or more of these scenarios should be added to the Messaging spec as examples.

He also pointed out that while these examples currently use signatures, that is a dependency on the Cryptographic Profiles spec.

Link Contract Expiration

Markus has seen frequent use cases for one-time-use contracts, for example for deferred push contracts, invitations, etc.

One specific use case is for link contracts that only work once, for example, to authorize a message that can only be received once. One example is an connection invitation that is effectively a one-time use contract. It will only authorize a single message that will create the link contract.

Les brought up a use case when the owner should be notified that a link contract is about to expire. Drummond said that link contract expiration and notification policy should be part of the link contract vocabulary.

Markus agreed that we should be using XDI policy statements to govern link contract expiration. This implies an additional policy branch.

Markus pointed out that we already have three policy branches in link contract processing:

(=bob/=alice)$do$if

(=bob/=alice)$do$defer$if

(=bob/=alice)$do$defer$push$if

Link contract expiration could be governed by a fourth branch. Here is an example of what this vocabulary could look like, using $del as the branch for link contract expiration.

(=bob/=alice)($do$del$if/$true){$do}[$msg]<$n>/&/1

Drummond wondered if the verb for the expiration branch should be $expire.

Link Contracts and Storing Copies of Messages

This is also a use case we are seeing frequently—storing sent/received messages (much like email). We need to discuss link contract vocabulary for this.

Markus suggested that there are three options for where policy could govern this:

1. The link contract being referenced by the message.

2. The message policy.

3. Global policy for an endpoint.

Drummond suggested that #1 is where we should concentrate initially, since that’s already the control point.

Markus thinks that we have two mechanisms that can potentially be re-used for storing copies of messages:

1. Messages that are deferred and stored in a graph due to link contract policy decision

2. Push link contracts

Basic structure of a push link contract:

(<--publisher-->/<--subscriber-->)$do/$push/<--target-address-->
(<--publisher-->/<--subscriber-->)$do/$is()/<--subscriber-->
(<--publisher-->/<--subscriber-->)($do/$push)<$xdi><$uri>/&/"<--subscriber endpoint-->"
(<--publisher-->/<--subscriber-->)($do/$push)<$content>/&/<--light-or-content-push-->

Example deferred message by =drummond in =markus’ graph with an index statement:

$get{$do}[$msg]/$has/=drummond[$msg]*!:uuid:m-1

=drummond[$msg]*!:uuid:m-1/$is()/(=markus)

=drummond[$msg]*!:uuid:m-1$do/$connect/$get{$do}

=drummond[$msg]*!:uuid:m-1$connect{$get}/$is/=markus<#email>

Markus suggested that the indexes of messages—message logs—should be configurable so that the logs could be organized the way the endpoint authority wants them.

(<--AA-->/<--RA-->)$do/$has()/[$msg]

The behaviour could be as follows:

1. If a link contract has a $do/$has() statement with an object node, the message is kept and indexed under that object node.

2. If a link contract has a $do/$has() statement with an empty object node, the message is kept but not indexed.

3. If a link contract does not have a $do/$has() statement with an object node, the message is deleted after processing.

We agreed this simple rule covers the cases and leaves message log indexing easily configurable for each endpoint.

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