XDI TC Minutes

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

Date: Friday, 30 August 2013 USA
Time: 09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)

ATTENDING

Les Chasen

Animesh Chowdhury

Joseph Boyle

Drummond Reed

Markus Sabadello

NEWS & UPDATES

XRI TC Closure Report

Drummond reports that consensus has been unanimous on the XRI TC to proceed with closure and contribute the work to the XDI TC.

# DRUMMOND to work with Chet Ensign on the rest of the steps necessary to complete this.

XDI2 Report: Support for JSON Null

Per our discussion on last week’s call, Markus has implemented support for JSON null in the XDI2 code base. It will now roundtrip all JSON value types.

Joseph asked the question, in each of the cases, what does an XDI $get return?

Markus explained that what you get back depends on what you ask for. He illustrated the three options below:

=markus/()/<+smoker> # attribute without value context

REQUEST: $get / =markus<+smoker>

RESULT: =markus/()/<+smoker>

REQUEST: $get / =markus<+smoker>&

RESULT: - empty graph (see note below) -

=markus<+smoker>/()/& # attribute with value context, w/out literal

REQUEST: $get / =markus<+smoker>

RESULT: =markus<+smoker>/()/&

REQUEST: $get / =markus<+smoker>&

RESULT: =markus<+smoker>/()/&

=markus<+smoker>&/&/null # attribute with value context, w/ literal (null)

REQUEST: $get / =markus<+smoker>

RESULT: =markus<+smoker>&/&/null

REQUEST: $get / =markus<+smoker>&

RESULT: =markus<+smoker>&/&/null

Markus noted that the actual format of the response containing an empty graph depends on the serialization format. In the JSON format, an empty graph is { }.

Drummond noted that in all examples, if there were other subcontexts of =markus<+smoker>, they would be returned, since they are part of the =markus<+smoker> branch of the graph.

PRESENTATIONS/DISCUSSIONS

Progress on Working Drafts

Joseph expects to check in a first draft of his section next week, and Drummond expects to do his first drafting that week.

Markus has started writing but has not checking anything in yet.

Link Contract Initiation

We continued our discussion of link contract initiation, with a goal of analyzing the structure of the three related versions of a link contract:

A link contract template.
A link contract instance.
A meta link contract.

We reviewed the sequence diagram for the Alice->Acme scenario. The flow we discussed was for the Respect Connect button on the Respect Network XDI network for personal clouds, but it is identical to a generic XDI link contract initiation flow that uses the same services.

The Connect button contains two key data items:

The XDI address of the “acceptor”—the XDI authority that is accepting link contract instances.
The XDI address of the link contract template that will be used to create the link contract instance.

To solve the classic federated identity WAYF (“Where Are You From?”) problem, the Connect button parameters are submitted to a Connect service operated by the associated trust framework (in this case Respect Network). This service prompts Alice for her XDI address (or a discovery key for it) so it can discovery Alice’s Connect service where it can redirect her.

Alice’s Connect service first authenticates Alice, then it processes the Connect button parameters to request the link contract template from Acme along with a human-readable name for Acme.

What distinguishes a link contract template is the presence of XDI variables.

At this point we began a discussion about how to best model personas in the XDI graph model and ran out of time. We agreed to continue the link contract analysis on next week’s call.