Yes I agree it begins to feel quite real.. Once we work out the last few details, we can probably soon to a proof-of-concept implementation..
How do you like the terms "XDI Connect", "XDI Connect Button", etc?
Markus
On Mon, Sep 9, 2013 at 5:38 PM, Drummond Reed <> wrote:
+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.
