XDI TC Notes

Following are the notes of the unofficial telecon of the XDI TC held on:

Date: Tuesday, 17 January 2017 USA
Time: 9:00AM - 10:00AM Pacific Time (17:00-18:30 UTC)

The TC operates under a standing rule approved 17 July 2008 under which the TC does not hold regular official meetings and conducts all business by electronic ballot only. Unofficial weekly meetings are held to enable discussion among members but no business is conducted nor actions taken.

ATTENDING

Markus Sabadello
Drummond Reed
Phil Windley

NOTES

XDI Link Contracts WD02

Markus will report on a new WD02 of XDI Link Contracts:

http://xdi.org/xdi-spec-docbook/xdi/xdi-link-contracts-1.0/xdi-link-contracts-1.0-wd02.xml

This WD has various bug fixes, as well as some new content based on the last XDI TC call, e.g. a "Deletion Policy", a "Trigger Policy", and a "Trigger Message".

We discussed whether both the Deletion branch is needed if we have the Trigger branch. We looked at the examples and concluded that the Deletion branch was not needed because it was just a special example of an action that can be taken with a Trigger Policy.

Markus explained that the Trigger Message is a very flexible construct. It represents an action that is taken every time a link contract is exercised. It can be used to apply changes to the current graph (e.g. setting a link contract to inactive, or deleting someone from a list of friends), but it can also be used to send messages to remote peers (e.g. for notification or audit purposes).

We also agreed that each Trigger Policy and Trigger Message should be atomic, so if there is more than one Trigger Policy and Trigger Message, they should be in a collection, and each member of the collection should be evaluated independently.

Drummond further suggested that it should be an ordered collection, because the order of the triggered messages can be critical.

The $purpose Link Contract Branch

Drummond drafted a wiki page describing the “branches” of a link contract and specifically a proposal for how a link contract branch can define data usage permissions.

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

Drummond first explained why the $purpose branch was not a $if branch (i.e., an executable policy branch). The reason is that, while a link contract template that contains a $purpose branch is required to display the purpose(s) and allow the user (authorizing authority) to opt-in or opt-out of optional purposes, once the link contract is instantiated, no further evaluation of the $purpose branch is needed. It just becomes a static part of the instantiated link contract, recording the purpose(s) for usage of the permissioned data to which the parties have agreed.

Drummond’s proposal divides the $purpose branch into three subbranches:

$required$purpose is a purpose that cannot be changed by the authorizing authority.
$opt-in$purpose is a purpose that will not be instantiated unless the authorizing authority explicitly authorizes it.
$opt-out$purpose is a purpose that will be instantiated unless the authorizing authority explicitly denies it.

Each of these subbranches then uses a $has relation to aggregate the purpose statements that fall under that branch. This design enables purpose statements to be as global or local as needed. From the standpoint of developing common understanding and trust in the market, it will be beneficial to have widely referenced purpose statements (perhaps even iconic representations such as those Creative Commons developed for copyright policies).

Drummond explained that this design maps to the privacy policy and data protection law he has been dealing with it in many jurisdictions over the past two decades.

One example would be a website registration use case. A website may require a certain purpose in order for users to be able to log in, and it may optionally ask for an additional purpose e.g. to send regular newsletters.

Markus asked about the relationship between the $do$if execution policy branch and the $purpose branch. While the former is a machine-readable component of the link contract, the latter is human-readable and relevant for legal aspects of the link contract.

Markus thought that the $has aggregation pattern could be used not only for the $purpose branch, but also for branches such as the $do$if execution policy.

The $purpose branch can also contain additional attributes to describe the jurisdiction and/or trust framework within which it operates. Trust frameworks may define purposes which can then be referenced by the link contract's $purpose branch.

# DRUMMOND to post more information about the relationship between link contracts, trust frameworks, and jurisdictions.

NEXT REGULAR CALL

The next call will be the following week at the usual time (Tuesday 9AM PT). The link where agenda items can be posted for the next meeting is: https://docs.google.com/document/d/19oDl0lbb56Grehx2a5flZnhrgnua5l8cVvC_dJ8fTXk/edit?usp=sharing