XDI TC Minutes

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

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

ATTENDING

Animesh Chowdhury
Dan Blum
Peter Davis
Markus Sabadello

GUESTS

REGRETS

Drummond Reed

NEWS & UPDATES

None scheduled.

PRESENTATIONS/DISCUSSIONS

Working Session on Link Contracts

We talked more about link contracts:

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

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

Dan asked if link contracts are always local, or if they can be retrieved from a remote location. In theory, link contracts could be retrieved from a remote location. Given a link contract address, standard XDI discovery could be used to discover its authoritative location.

Markus explained that today, when an XDI server processes a message, it currently uses only link contracts in the local graph that is the target of the incoming message. In other words, a link contract can only govern access to its own graph.

Peter reminded everybody of the “power-of-attorney” use case as well as certain “group/membership” scenarios, in which it would be desirable for a graph’s permissions to be handled by an external link contract.

One idea we came up with is that even though a link contract can only govern its own graph, the link contract may be able to reference data from an external graph when making an authorization decision.

We came up with the following example: I want all XDI TC members to be able to read my email address. So I could have a link contract like this:

…$do/$get/=markus<+email>

…$do$if/$true/(@xdi.tc/+member/{$from})

But the problem here is that I would have to maintain my own list of XDI TC members in my own local graph. Instead it would be better the be able to reference the “authoritative” list of XDI TC members in the @xdi.tc graph:

…$do/$get/=markus<+email>

…$do$if/$true/((@xdi.tc)@xdi.tc/+member/{$from})

We agreed this would be a useful feature.

Dan next asked whether a link contract policy can call external scripts (e.g. _javascript_), for example to validate OpenID Connect tokens. Dan also suggested that additional $ words could be added to XDI to express support for such external protocols. Peter responded that this could also be achieved by setting up standard XDI authorities (without $ words), which would have external protocol integration “hidden” behind the XDI layer. Animesh recalled that we actually used to express link contract policies in _javascript_, but then moved to express them in XDI itself, which is better from a portability perspective.

Finally we came up with an interesting demo scenario: We could create link contracts that grant permissions to all my Facebook friends. This would be done by 1. exposing Facebook friends in XDI using an XDI connector, an 2. linking Facebook identifiers to Cloud Numbers using the “discovery keys” feature of a registry.

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:

MIME types for serialization formats.
Formatting improvements.
Adding missing sections.
Improved Github merging process.

We did not have time to discuss this topic.

DECISION POINTS FOR THIS CALL

None scheduled.

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.

xdi message