XDI TC Minutes

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

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

As usual, if you have comments about the minutes, or if you think anything is missing or inaccurate, please reply to the TC list.

ATTENDING

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

Patrick Reilly
Amanda Navarro
Phil Windley

GUESTS

André Martins

REGRETS

NEWS & UPDATES

New XDI Tutorial Chapter

Srinivas Pakanati has contributed a new chapter to the XDI Tutorials, “XDI Graph Model Part 3”:

http://tutorial.xdi.org/

Markus reported that Srini is requesting feedback, and will subsequently work on another tutorial about link contracts.

Peter suggested the tutorials could be published as an official (non-normative) XDI TC document. XDI.org may also be an option.

ACTION for all: Please review the new tutorial and provide feedback.

ACTION for all: Feel free to also review and contribute to other tutorials, or start a new one.

ACTION for Markus: Inform Srini of a few bugs we found while looking through the slides.

XDI2 Virtual Hackathon Oct 2 2014

Markus gave a short report on a 2-hour virtual hackathon on yesterday’s XDI2 call.

The objective was to answer the question

"What is the simplest way to send a message between two graphs?"

A summary is available here:

https://groups.google.com/d/msg/xdi2/yOJvv3p4MKo/koeeSsFGIH8J

Markus said that the participants were divided into groups that either did “XDI inboxes” or sent messages to be received in these inboxes. By the end of the two hours, everyone was able to send messages and receive them in the inboxes. Some important aspects of the scenario were improvised and not “realistic”, e.g. the absence of link contract policies and signatures.

PRESENTATIONS/DISCUSSIONS

Report from XDI editors subcommittee

https://wiki.oasis-open.org/xdi/XdiOneSpecs
https://github.com/OASIS-XDI-Technical-Committee/xdi-spec-docbook

Peter reported that:

Hubert uploaded a new version of XDI Bindings
Peter renamed the XDI Signatures spec to XDI Cryptographic Profiles
Some processes around the Jira system were discussed
The process of creating HTML/PDF files from the specs was discussed

On the XdiOneSpecs wiki page, we also renamed “XDI Signatures” to “XDI Cryptographic Profiles”.

$add and $mod

Markus brought up the “virtual hackathon” raised the question about $add and $mod behavior with regard to collections. We discussed this on a TC call about two months ago, and the recollection was that we reached a conclusion about how assignment of $msg IDs would work. There were two options:

Client assignment
Server assignment using a variable.

Drummond asked if we should have the XDI Messaging editors develop a proposal on this?

Joseph suggested that the editors of XDI Messaging do this.

XDI Connections

Let’s continue to discuss XDI connection requests, connection invitations, link contracts, templates, community contracts, requester contracts, etc.

Topics:

Review in more detail what happens when a connection invitation is processed.
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:

https://www.oasis-open.org/committees/download.php/54205/LinkContractInstantiation25Sep2014.pdf

XDI Policy draft spec:

https://www.oasis-open.org/committees/download.php/54016/XDIPolicyDraft%20v7.docx

Deep Dive notes:

https://www.oasis-open.org/committees/download.php/53986/xdi%20deep%20dive%202014-8-27.pdf

https://www.oasis-open.org/committees/download.php/53985/linkcontractExamples.pdf

Dan explained that he was in the process of pulling sections related to “link contract instantiation” out of the “XDI Policy” spec draft, and add them to the new “XDI Connections” spec. Drummond suggested the two specs should reference each other and clearly explain their relationship.

Dan sent an email to the TC list on several of the above topics:

https://lists.oasis-open.org/archives/xdi/201409/msg00052.html

Dan reviewed this content from that email:

*************

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 housekeeping.

******************

Drummond’s input was that the Connections spec should cover the topic of deferred connection requests, because many implementations might need to deal with this. In particular he liked the idea of timestamps describing the link contract template and link contract instances, so policy can be applied on either the AA’s or RA’s part to “clean up” or manage link contracts.

Markus asked about whether any special data structures were needed for connection management. The consensus was no, it was just a matter of storing connection request messages or connection invitation messages.

*******************

Template versioning

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

Discussion of versions of templates

+acme#registration[$v]@...

+acme<#tel>[<$v>]@

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

*************

Drummond gave this example of how versioning works:

This is the XDI address of the third version of Alice’s default telephone number:

=alice<#tel> <== Alice’s current telephone number

=allice<#tel>[<$v>]<@3> <== Alice’s fourth version of her telephone number (ordered indexing starts with 0)

If you need to version the dictionary definition of the #tel, then this is what it would like to use the third version of the dictionary definition:

=allice<#tel>|[<$v>]||<@2> <== Alice’s current phone number using the third dictionary definition of <#tel>

And this would be a versioned instance of that definition:

=allice<#tel>|[<$v>]||<@2>|[<$v>]<@3>

This same pattern applies to link contract templates.

We discussed that the versioning of link contract templates and instances gives rise to the same legal issues of what happens when a real-world contract changes, such as when a website updates a privacy policy. Dan explained that this must be covered in the XDI Connections spec.

Drummond said that this is yet another example of how XDI link contracts are aptly named because they are in fact data structures that need to model real world legal relationships.

Questions from Patrick Reilly

As a new member of the TC, Patrick sent an email asking the following:

*********

I’d like to quickly address the questions below in the “new business” period of today’s Telecon.

My first goal joining the the XDI Technical Committee (“TC”) is to understand how the TC operates and further how actions of the TC sponsor or impede the development and market introduction of actual products and services. To this end, I’d like to quickly address the questions below in the “new business” period of today’s Telecon.

I submit my effort at clarifying questions regarding the interplay of XDI Connections and the emerging products of Respect Network:

1. What is XDI Connections?

It is the new name for what had been called XDI Link Contract Instantiation, which is the part of the XDI specification suite that covers negotiating link contracts.

2. Is XDI Connections meant to be a part of the XDI spec at OASIS?

Yes.

3. Has the TC approved an XDI Connections; initiative?

The XDI Connections spec is not approved yet, no. None of the XDI 1.0 specs have reached Committee Draft status yet.

4. If so, was an XDI Connections spec initiative reviewed and approved by the TC?

No -- see above. All Working Draft specs are reviewed by the TC, and all of them will go through the standard OASIS Technical Committee voting process to advance to Committee Drafts.

5. How long has the XDI Connections specification been in development? (By the TC?)

As explained above, the negotiation of XDI link contracts has been a core focus of the TC for the past several years.

6. Who has been developing the XDI Connections specification?

Dan Blum is the lead editor. Markus Sabadello, Hubert Le Van Gong, Peter Davis, Joseph Boyle, Andy Dale, and myself are all involved.

7. Where (in what venue) has XDI Connections specification been proceeding?

Like all of our work, the XDI TC is the venue. TC members talk about the work directly between themselves in between TC calls or posting updated documents, but we come together every week to sync up.

8. What is the Respect Network reputation service?

It is a component of the Respect Trust Framework, which has been listed with Open Identity Exchange since May 2011.

9. Will the Respect Network reputation service integrate XDI Connections?

Yes, along with all the XDI 1.0 specifications as soon as they are ready. Respect Network is planning to implement the Respect Reputation System on an XDI network, so all components of an XDI network will be involved.

10. If so, what are the functional/technical differences between Respect Connect and XDI Connection?

“Respect Connect” is a profile of XDI Connections and the other XDI 1.0 specs that will incorporate use of the Respect Trust Framework, the XDI.org registry and discovery services, the specific crypto profile, and Respect Network core services.

11. Will the Respect Network reputation service also be based on the XDI open standard at OASIS?

The Respect Reputation System has a legal definition in the Respect Trust Framework that is independent of any technical protocol. The implementation that Respect Network is planning will be based on an XDI network as explained above.

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.

We did not discuss this topic.

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:

https://www.oasis-open.org/committees/download.php/53921/LinkContractInstantiation17Aug2014.pdf