Preserving the work of the XRI TC

Please add me to the agenda for next Friday for 1 hr as I would like to address the TC with a call to action urging submission of the last XRI 3.0 draft as a committee draft, a
 discussion of blockers to that, and a discussion of how those blockers can be removed. I think this is extremely important, though I know there are differing opinions.

Kind regards,

 

Bill Barnhill

Booz Allen Hamilton - Belcamp,MD



Cell: 1-443-924-0824 

From:  [] on behalf of Drummond Reed []

Sent: Monday, September 09, 2013 11:38 AM

To: Markus Sabadello

Cc: OASIS - XDI TC

Subject: [External] Re: [xdi] Minutes: XDI TC Telecon Friday 2013-09-06

+1. I'm not saying it's done (or even that the term "meta link contract" is the right one ;-) But I like the progress, and I think we can boil it down pretty quickly now that we are starting to nail down the details.

On Mon, Sep 9, 2013 at 2:02 AM, Markus Sabadello 
<> wrote:

Yes it was pretty productive. But there are certainly a few details (especially about the meta link contract pattern) that still have to be worked out..

Markus

On Mon, Sep 9, 2013 at 5:50 AM, Drummond Reed 
<> wrote:

Markus, great minutes. I was sorry to miss this meeting as the link contract initiation topic is white hot right now and I would have loved to have been there. But the minutes are great and I am eager to reflect this feedback in updates to the
 proposal this week.

BTW, I especially agree that well-known link contract templates are going to be very useful and popular. I plan to add a section on that this week to
the link contract patterns page.

On Sun, Sep 8, 2013 at 6:35 PM, Markus Sabadello 
<> wrote:

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)

ATTENDING

Markus Sabadello

Joseph Boyle

Phil Windley

Animesh
 Chowdhury

REGRETS

Drummond
 Reed

AGENDA
NEWS
 & UPDATES

None
 scheduled.

PRESENTATIONS/DISCUSSIONS

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:

https://github.com/OASIS-XDI-Technical-Committee/xdi-spec-docbook

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:

A
 link contract template.

A
 link contract instance.

A
 meta link contract.

Drummond
 has posted a wiki page:

https://wiki.oasis-open.org/xdi/LinkContractPattern

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:

<--from-->{$from}[$do]<--instance-id-->/<--operation-->/{$to}<--object-graph-->

<--from-->{$from}[$do]<--instance-id-->$if<--boolean-context-->/<--operator-->/<--condition-->

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.

Example:

[@]!2222{$from}[$do]!3333/$get/{$to}<+email>

[@]!2222{$from}[$do]!3333$if/$true/…

Link
 Contract Instance Pattern and Example:

<--to--><--from-->[$do]<--instance-id-->/<--operation-->/<--object-graph-->

<--to--><--from-->[$do]<--instance-id-->$if<--boolean-context-->/<--operator-->/<--condition-->

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

Example:

[=]!1111[@]!2222[$do]!4444/$get/[=]!1111<+email>

[=]!1111[@]!2222[$do]!4444$if/$true/...

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

<--from-->[$do]<--instance-id-->/<--operation-->/<--to--><--from-->[$do]<--instance-id-->

<--from-->[$do]<--instance-id-->$if<--boolean-context-->/<--operator-->/<--condition-->

Example:

[@]!2222[$do]!3333/$set/[@]!2222[=]!1111[$do]!3333

[@]!2222[$do]!3333$if/$true/...

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:

[=]!1111[@]!2222[$do]!4444

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:

+friend$do

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.

DECISION
 POINTS FOR THIS CALL

None
 this week.

DECISION
 POINT QUEUE REVIEW

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

  https://wiki.oasis-open.org/xdi/CategoryLastCall

  https://wiki.oasis-open.org/xdi/CategoryCurrent

  https://wiki.oasis-open.org/xdi/CategoryHighPriority

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

  https://wiki.oasis-open.org/xdi/XdiPendingIssues

NEXT
 CALL

The
 next call is next week at the regular time.