OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Minutes: XDI TC Telecon Friday 2014-09-26

XDI TC Minutes

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

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


Peter Davis
Les Chasen
Hubert Le Van Gong
Drummond Reed
Dan Blum
William Dyson
Markus Sabadello
Patrick Reilly
Joseph Boyle


André Martins


Phil Windley



Report from XDI editors subcommittee


The editors reported that there were no new drafts posted, but the following was discussed:

First, these three names were selected for the three bindings to be defined in XDI Bindings 1.0:

Second, Drummond and Joseph set the expectation that they are shooting to have another draft of XDI Core ready for review by mid-October, so that the TC could get in comments and they would be reflected before Internet Identity Workshop the last week of October.

Proposal to eliminate value context node

Joseph posted a proposal to eliminate the value context node, and instead have literal nodes (and their values) attached directly to attribute singleton or attribute collection member nodes.


Markus has a diagram of XDI2’s implementation of the graph model:


Joseph began by explaining his proposal.

The TC then had a long discussion about the proposal. The discussion was not about the merits of the proposal, because there was consensus about its merits. Rather it was about:

  1. The impact of the change. This is the fourth “shift” this calendar year, and there is a very strong sentiment to try to avoid further shifts. Drummond pointed out that none of the shifts was anticipated, all of them were approved by consensus (i.e., everyone agreed that they were worth the pain), and that all but the symbol shift resulted in significant simplification of either XDI syntax and/or the graph model.

  2. The need for backwards compatibility whenever possible. This is important for existing graphs and code bases.

On the latter topic, Peter suggested that the spec should:

  1. Have a backwards compatibility note about XDI graphs that include value nodes.

  2. Specify that value nodes will be deprecated with the next release of the spec.

The 1.0 requirement will only be to support graphs without value nodes.

Joseph recommended that code bases try to move through the transition as quickly as possible.

There was concern on the call that it is difficult to build commercial software based on a technology that is undergoing such shifts. Dan and Drummond agreed but also explained that this must be expected at a stage in which there are only working drafts, and that after the 1.0 spec release, any potential future shifts (breaking changes) will not be possible so easily.

Markus added that in the XDI2 codebase, there will be a well-documented code and graph migration process, as it was with the previous three shifts (symbol, link contract, notation).

CONSENSUS: We agreed to move forward with Joseph’s proposal, and for Joseph and Drummond to put this proposal into the next draft XDI Core spec, together with a backwards compatibility note that servers and clients SHOULD support historical graphs that include value nodes.

XDI Connections

We continued the discussion of XDI connection requests, link contracts, templates, community contracts, requester contracts, etc.

One insight from work by Markus and Dan this week is that there are “connection requests” and “connection invitations”. The latest version of the “Link Contract Instantiation” document:


Markus first explained the terminology that he and Dan had been developing:

We discussed the progress that Markus and Dan have made in defining the different roles that are played. Markus showed the four different cells in the matrix and explained the uses cases it fulfills. We discussed the use of the {$to} variable in connection requests and connection invitations in conjunction with the XDI Browser Binding, where the message recipient is not know in advance.

Drummond explained that on a XDI2 discussion yesterday, the callers realized that there was a very elegant solution to the question of how to automate approval of a connection request or connection invitation. In essence it boils down to this:

  1. If an AA wants to automatically approve a connection request when it is received from a particular RA for a particular link contract template, the AA writes a connection invitation for that RA and that link contract template into the AA’s own graph.

  2. If an RA wants to automatically approve a connection invitation when it is received from a particular AA for a particular link contract template, the RA writes a connection request for that AA and that link contract template into the RA’s own graph.

The reciprocal nature of connection requests and connection invitations makes this fit together very nicely.

During the call, Dan created and presented a diagram showing the set of chained connection requests and connection invitations that would result in a pair of reciprocal unidirectional connections between Alice and Bob a single flow:

We did not have time to discuss these other open topics:

Collection of Documents:

Link Contract Instantiation:


XDI Policy draft spec:


Deep Dive notes:



We did not have time for the following topics.

Variables and variable collections

We have been using variables such as {$from} or {$msg} or {$do}.

It seems we have consensus on variable syntax, but we may need to discuss in more detail how variables are processed.

Transactional integrity

We have discussed the topic of transactional integrity a number of times in the past without reaching a conclusion. This seems to now have new relevance in conjunction with link contract instantiation.

The following document has a section titled “XDI Message Transactional Integrity Notes”, let’s review and discuss:



The next call is next week at the regular time.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]