Re: [xdi] XDI TC Notes Unofficial Telecon Monday 2016-01-04

["=Drummond Reed" <drummond@respect.network>]

Good point, Markus. I agree $digest should be in the Crypto spec.

On Mon, Jan 4, 2016 at 4:41 PM, Markus Sabadello <markus.sabadello@xdi.org> wrote:

Quick comment about the following sentence from the notes:
"This uses the $digest keyword, which Markus will add to the Messaging spec."

I believe the $digest keyword will be defined in Cryptographic profiles or Security Mechanisms, rather than in Messaging.

The Link Contracts spec can then give an example how a link contract can use the $digest keyword in a policy.

Markus

On 01/04/2016 08:16 PM, Markus Sabadello wrote:

XDI TC Notes

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

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

REGRETS

Update on Publishing XDI Core 1.0 Committee Specification Draft 01

Drummond gave a brief report on progress.

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

Chet and Ken Holman from the OASIS DocBook TC got back to Joseph and Drummond with answers to most of our questions. That leaves two final tasks:

# ACTION ITEM: JOSEPH AND DRUMMOND to do a final joint editing session.

# ACTION ITEM: DRUMMOND to add a wiki page with any proposed revisions for future versions of XDI Core 1.0.

XDI Agent Demo

Markus gave another demo of new functionality he has developed for an XDI agent (a Java desktop app) that can connect to XDI endpoints:

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

In this demo, he showed an “automatic” connection invitation. In this scenario, Alice sends a connection invitation to Bob, and when Bob accepts, the connection request from Bob back to Alice is automatically accepted by Alice.

To do this, the link contract policy specifies that it will accept an XDI message with a specific digest hash value. This uses the $digest keyword, which Markus will add to the Messaging spec.

The other new functionality is an XDI chat functionality. Markus has implemented this with two link contracts, one in both directions, between Alice and Bob. These link contracts are in fact quite similar to the ones for reading and writing profile data that Markus showed last week.

He showed basic chat messaging between Alice and Bob. These messages are not encrypted but they both have signatures—one from the sender (applied by the agent) to verify the message at Alice’s endpoint, and then one applied by Alice’s endpoint to send to Bob’s endpoint.

Markus explained that the addition of signatures and encryption, and the removal of signatures and encryption, are all controlled either by parameters on a message or server configuration. However the basic sequence of operations is the same, and this is what is documented in Markus’ earlier flow diagrams and in the Messaging spec. Markus felt that some sequence diagrams will be needed in the Messaging spec.

Queues, Conversations, Channels, and Group Messaging

Drummond brought up the idea of messaging queues and conversations as a design approach that enables a single link contract to control access to the queue. This took us into a whole set of topics around design patterns for direct and group messaging.

Markus took the following group notes about this conversation:

A queue has a UUID [$queue]*!:uuid:ex-1

  A queue contains a set of conversations

Conversations have UUIDs

  [$conversation]*!:uuid:ex-2 and [$conversation]*!:uuid:ex-3

# ACTION ITEM: ALL think about $ dictionary word for conversations that is shorter than “$conversation”.

A conversation is a sequence of messages.

Alice and bob want link contract to share a queue that allows both to read/write messages and conversations.

Current "bi-directional link contract pattern" used in XDI Ninja demo app for chat:

(=alice/=bob)$do/$set/=alice#chat$channel[$msg]

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

(=bob/=alice)$do/$set/=bob#chat$channel[$msg]

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

Closed "centrally controlled" channel:

(=alice/+group)$do/$set/=alice#chat$channel[$msg]

(=alice/+group)($do$if/$true)+group/$has/{$from}

+group/$has/=bob

+group/$has/=charlie

 -> =alice controls list of group members

 -> all message are sent via =alice (centralized, hub-and-spoke channel)

 -> group/channel lifecycle is controlled by =alice

Proposed shared queue context link contract pattern:

(=alice)+group/$has/=alice

(=alice)+group/$has/=bob

(=alice)+group/$has/=charlie

(=bob)+group/$has/=alice

(=bob)+group/$has/=bob

(=bob)+group/$has/=charlie

(=charlie)+group/$has/=alice

(=charlie)+group/$has/=bob

(=charlie)+group/$has/=charlie

 -> group continues to exist as long as it still has at least 1 member

 -> new members joining requires / does not require invitation from existing member (depends on policy)

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