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: Re: [xdi] Minutes: XDI TC Telecon Friday 2014-09-26

The minutes note that 
"We did not have time to discuss these other open topics:
  • Template versioning - what if the Template Authority changes a template? How does this affect existing link contract instances?

  • What do “deferred” connection requests look like?"

Deferred connections

I've thought about the topic of "deferred connection requests." In our analysis of link contract (LC) instantiation, or connections, we haven't found a protocol issue with the deferred processing of a connection request (CR). The XDI message protocol is stateless and waits. 

As an implementation issue, there might some cleanup required for deferred connection requests that are never completed, or are completed after the requesting party no longer cares about the connection. We could put something like this into the eventual spec.

"RAs MAY track connection requests and, if no expected response is received within a desired time period, clean up any connection subgraph entries recording the requests and remove any requestor link contracts or other data originally pre-positioned for the connection."

The only un-graceful result I can see from a connection request timing out on the RA side is that both sides will contain data about connections and link contracts they will now never use. The AA may try to write an LC instance to a requestor LC; that write could fail if the RA has cleaned up the detritus of unprocessed connection requests and AA's behavior is indeterminate then. We need to look at that when we work on requestor LC issues.

Another think we could do would be to require or recommend specifying temporal data in link contract templates, link contract instances and connection requests. So that every LC instance and template, and every CR and CI have an $add$t for its creation date. CRs and CIs could also have an $expires$t that would cause them to be dropped out of all subgraphs during houskeeping.

Template versioning

Here are some notes from the deep dive we had in Berkeley last month.

Discussion of versions of templates



Note: the $v needs to be extensible to the major/minor pattern, but you can do that through [$v]@[$v]@

Note for TC: the XDI versioning spec may need to be put on the critical path, too complex to go in the dictionary

Inline image 1

Figure above shows the potential use of version with both the link contract template and the link contract instance

Best regards,

On Sat, Sep 27, 2014 at 11:00 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:

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:

  • XDI POST Binding

  • XDI Browser Binding

  • XDI Artifact Binding

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:

  • Connection is the short term for link contract instantiation.

  • Connection request is a message sent from the RA to the AA with a ($do} operation whose object is a link contract template.

  • Connection invitation is a message sent from the AA to the RA with a $is($do} operation specifying a link contract template (and which typically results in the RA sending a connection request back to the AA).

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:

  • Template versioning - what if the Template Authority changes a template? How does this affect existing link contract instances?

  • What do “deferred” connection requests look like?

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]