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: [xdi] Minutes: XDI TC Telecon Friday 2013-09-06

XDI TC Minutes

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

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


Markus Sabadello

Joseph Boyle

Phil Windley

Animesh Chowdhury


Drummond Reed



None scheduled.


Progress on Working Drafts

Joseph and Markus shared their experiences with working on the Docbook templates. Joseph has made several improvements to the XDI Messaging template, which makes it more “correct” as an official OASIS spec. Joseph’s updates affect for example document naming, citations, and other important details. These improvements have to be made to the other templates as well.

We had a discussion on how to collaborate on the specs, which are currently hosted on Github:


Besides Joseph, Phil has also contributed a small change to the repository (updated the README file). We noticed that there seem to be several different options in which TC members (and external contributors) can collaborate on the specs:

Option #1: Make a change on the master branch, then commit and push the changed file(s) to Github. This can only be done by TC members.

Option #2: Create a new branch, make the change within the branch, commit and push the changed file(s) in the new branch to Github. Then issue a pull request for the new branch to be merged into the master branch. The pull request can only be accepted by TC members.

Option #3: Clone (i.e. make a copy of) the TC repository. Make the change on the master branch within the cloned repository, then commit and push the changed file(s) to Github. Then issue a pull request for the master branch of the cloned repository to be merged into the master branch of the TC repository. The pull request can only be accepted by TC members.

Joseph has used Option #2 for this updates. Phil has used Option #3 for his updates.

Markus’ recommendation is to use Option #1 when you are working on a file you “own” (e.g. you are the main editor of the spec), and to use Option #3 when you want to contribute to a file you do not “own”.

Link Contract Initiation

Continue our discussion of link contract initiation, focusing on the structure of the three related versions of a link contract:

  1. A link contract template.

  2. A link contract instance.

  3. A meta link contract.

Drummond has posted a wiki page:


We walked through a detailed example of these three structures in a web-based link contract initiation flow:

Alice’s Cloud Number: [=]!1111

Acme’s Cloud Number: [@]!2222

Link Contract Template ID: [$do]!3333

Link Contract Instance ID: [$do]!4444

Link Contract Template Example:


The field <--instance-id--> is a bit misleading here, because it does not refer to a link contract instance. It only refers to one link contract template in a collection of link contract templates.



Link Contract Instance Pattern and Example:


Markus felt that the pattern was missing a <--to--> field before the <--object-graph--> field.



We also felt that while Drummond’s proposal included both singleton and collection patterns, in practice the singleton patterns would probably not be used when it comes to link contract templates and link contract instances.

Meta Link Contract Pattern and Example




Markus felt this would probably not work exactly like this, and it needs to be improved.

Animesh thought the name “meta link contract” was not ideal, since it is not in any way abstract, or a “link contract of link contracts”. Technically it works just like any other link contract, therefore maybe “counter link contract”, “feedback link contract”, or some other term might be more appropriate.

Link Contract Initiation Flow

Besides working on the above examples, we also talked about other aspects of the link contract initiation flow.

Animesh was concerned about phishing attempts. How could a user Alice be sure that an XDI Connect button on a website would actually result in a connection with the party that appears (or pretends) to be running the website. Animesh felt that a solution would be to enable XDI registries to make Cloud Names discoverable if the corresponding Cloud Number is known. This could enable Alice to be certain she is establishing a link contract with the Cloud Name @acme, rather than an unknown entity identified by a Cloud Number. Historically, XDI registries have not supported this functionality for privacy reasons, but since pseudonyms and personas are now going to be handled in a different way, this historically limitation may no longer be necessary.

Markus added that to prevent phishing, another measure is be the addition of a reputation service to the flow. Such a service can provide Alice with additional trust-related information that enables safer decision making.

Patterns for Link Contract Addresses

The above examples use link contract instances with addresses such as this:


These link contract basically represent one-to-one connections between two parties.

Animesh reminded us that in his implementation work, he has used link contract instances with addresses such his:


His link contracts represent permissions given to parties with whom I have a certain relationship (e.g. +friend).

We agreed that it is useful to have such “well-known” addresses (i.e. locations in the graph) for link contract instances of certain types.


None this week.


The decision queue stack is shown on the following three auto-generated Category pages:




See also this list of proposals that need to be developed:



The next call is next week at the regular time.

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