XDI TC Minutes

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

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

ATTENDING

Drummond Reed

Les Chasen

Joseph Boyle

Animesh Chowdhury

Dan Blum

Markus Sabadello

REGRETS

Phil Windley (travel)

GUESTS

Chet Ensign - OASIS

Paul Knight - OASIS

PRESENTATIONS/DISCUSSIONS

MULTI-PART SPEC DESIGN CHOICES

Chet Ensign and Paul Knight from OASIS joined us to discuss the different options we have for the XDI 1.0 spec suite as a multi-part specification.

Multi-part specifications consist of multiple independent documents. For example:

XDI 1.0 Part 1: Conformance
XDI 1.0 Part 2: Graph Model
XDI 1.0 Part 3: Serialization
XDI 1.0 Part 4: API

All of the parts have to be voted on and versioned as a unit. If they are going to evolve independently, they should not be multi-part.

Another option is to make sets of the documents their own multi-part spec. That might look like XDI Core 1.0, which could have several specs in it.

Another dimension to consider is conformance. Conformance clauses are required for every spec. They can be in each individual spec, or they can be one spec within a multi-part work product.

A third consideration is what additional machine-language artifacts we want to publish, for example a set of schemas. Those can be individual parts, or they can be included in other parts.

Paul offered the following additional considerations: advancing a lot of different parts in lockstep can be procedurally difficult. It involves more work for the editors, particularly in Docbook.

Drummond asked for Chet’s and Paul’s recommendations, given the approximate planned scope of the XDI 1.0 specs.

Chet said it would depend on weighing different factors:

If the specs are independent, then there is a separate public review of each. This is the path that the XACML TC has chosen, but it adds overhead for each.
This works better if the TC has independent workgroups focused on different specs.

Drummond asked how many TCs are using all-independent, all-multi-part, or a mix. Chet said that it varie, for example, XACML is using a mix.

Paul said that when there is a lot of current development going on, it is better to keep things independent, whereas if a spec is pretty mature, a multi-part can be easier.

Chet and Paul also explained that you can also combine a set of independent specs into a new work product that becomes a multi-part spec.

Drummond said that this “migration path” sounded like the most attractive to him, because it strikes a medium balance. Chet and Paul seemed to think that it was a good middle ground, and had worked well for TCs like the XACML TC.

Dan agreed, but with the one concern that at the time a final multi-part spec was published and put up for an OASIS Standard vote, it might draw many more comments from people who were not paying attention to the individual specs.

One additional benefit of this approach would be getting all IPR obligations dealt with at the Committee Specification level, since that is where IPR obligations are triggered.

Drummond asked how spec naming/versioning would change if we took this hybrid approach.

Paul said the versioning would apply to each independent spec. The version number goes at the very end.

# DRUMMOND AND JOSEPH to update the following wiki page with the proposed spec names following this approach:

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

Chet will send us more instructions.

# CHET to send more instructions to the XDI TC list about spec naming guidelines.

DECISION POINTS FOR THIS CALL

This week's decision queue is the following set of proposals:

XDI SECURITY PATTERNS

We continued our review of mechanisms for XDI message authentication and authorization and how they align with OAuth and PKI.

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

https://lists.oasis-open.org/archives/xdi/201305/msg00048.html

Dan gave a presentation on the Respect Network security architecture because, as an XDI network, it helps provide concrete use cases for the different XDI security scenarios we have been discussing.

We discussed the term “personal cloud” and whether it should mean a distributed cloud that can exist across any number of XDI servers and/or XDI service providers (often called CSPs, or Cloud Service Providers). There was agreement that this is how that term should be used. This means we need terminology for describing a specific “instance” or “shard” or “graph” that exists at a particular endpoint.

Animesh proposed that we need to make a distinction between logical and physical levels of reproducing and addressing the graph. This led into a discussion about how XDI addressing and discovery will work for peer graphs representing different facets of the same real-world entity, and whether these represent different XDI peer roots or the same XDI peer root hosted in multiple locations.

Drummond said that if you look at it from an XDI graph model, there does not have to have a single root. It will be much easier conceptually for users if there is a primary root, but there can also be secondary roots.

We agreed this is both a difficult and important topic that needs fuller analysis and documentation.

# DRUMMOND to produce some initial documentation for the TC to review.

# DAN to continue his documentation of generic XDI security scenarios.