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: 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: xdi@lists.oasis-open.org [xdi@lists.oasis-open.org] on behalf of Drummond Reed [drummond.reed@xdi.org]
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 <markus.sabadello@xdi.org> 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 <drummond.reed@xdi.org> 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 <markus.sabadello@xdi.org> 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:

  1. A link contract template.

  2. A link contract instance.

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






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