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: Minutes: XDI TC Telecon Friday 2014-02-14

XDI TC Minutes

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

Date:  Friday, 14 February 2014 USA
Time:  09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)


Drummond Reed

Dan Blum

Peter Davis

Phil Windley

Joseph Boyle

Markus Sabadello

Les Chasen

Animesh Chowdhury



XDI Tutorial

Markus has completed Part 4 of the XDI Tutorial (about XDI Messaging):


Animesh and Drummond gave Markus high kudos for such a clear explanation of how XDI messaging works.


Working Session on Link Contracts

We reviewed the Link Contract patterns at:


Dan mentioned that he had been working on a “Technical and Operational Specification” for Respect Network, which contains a section on using link contracts for controlling access to Personal Clouds. Dan explained that there are different purposes for link contracts, e.g. between individuals, or between an individual and groups, or link contracts based on external authorization services.

This resulted in a discussion around link contracts and policy _expression_ statements and the potential issues around portability. One question here is whether or not all the information needed to evaluate a link contract is part of the XDI graph. Peter commented that link contracts may become very complex, considering that they may contain a lot of personal preferences.

Drummond clarified that the policy _expression_ associated with a link contract is itself expressed as XDI and should therefore be portable. Peter warned that most likely there will be cases of non-portable (parts of) policy expressions. For example, a CSP in the healthcare space may have an internal policy which may require that only the last 4 digits of a SSN would ever be returned to an XDI client, even if the full SSN is stored in the XDI graph.

Dan mentioned that he and Andy Dale were also concerned with cases like this. It may make sense to distinguish between personal policies that are part of the XDI graph, and CSP-internal policies, which would not be portable. Dan called this an “extensibility point” for CSPs for policy processing. Peter saw a need to view policies as a “framework” within the XDI specs, which RN and others could then profile.

One conclusion was that the XDI Policy Spec should specify very precisely how code should process a link contract and all the policy expressions it contains. Then implementations should try to faithfully conform to that spec so that there is 100% interop to the extent those implementations are conformant.

We next discussed the link contract patterns. Markus explained the “old” approach to link contract paterns (which basically allowed storing link contracts at any arbitrary address in the graph), and the “new” approach which is currently documented on the LinkContractPattern page. This page describes very concrete patterns based on an authorizing party, requesting party, and other components, e.g.:


We agreed that this pattern is very useful for many common link contracts, including the root link contract and public link contract.

Markus asked whether this pattern is a loose recommendation, or whether it is strictly enforced. He also asked if the pattern influences any policy decisions when a link contract is evaluated. Animesh explained that in his opinion, the link contract patterns do not actually affect how a link contract is processed. Drummond agreed, and added that the purpose of these patterns is scoping and uniqueness, not policy evaluation.

Markus next asked whether the above link contract pattern would work for more complex link contracts, e.g. when there are multiple requesting parties. We came up with different options to address this:

- Markus suggested that the “requesting authority” of the pattern could be optional, if it is not obvious who the “requesting authority” is.

- Animesh proposed that in such a case, one would invent an identifier for the abstract/unspecified “requesting authority”.

- Drummond said that scoping is important. If there is no clear “requesting authority”, then unique scope of the link contract has to be achieved in some other way.

Finally, Markus raised two more questions which we did not have time for:

1. The LinkContractPattern page also specifies a pattern for a Meta Link Contract. This pattern is however incompatible with the above mentioned pattern. Markus asked if these two patterns could somehow be more closely aligned.

2. The LinkContractPattern page also specifies a pattern for Link Contract Templates, which just like Link Contracts uses the $do identifier. Markus felt that this was not correct, since Link Contract Templates are not actually themselves Link Contracts. Maybe a different identifier such as {$do} could be used.

I-JSON and JSON Schema

Within the XDI2 project, the potential use of I-JSON and JSON Schema for the XDI/JSON serialization format has come up.

We did not have time to discuss this topic.

Next Steps on Working Drafts

We will discuss the additions/corrections we want to make to produce XDI Core 1.0 Working Draft 02, including:

We did not have time to discuss this topic.


None scheduled.


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]