Note from Markus: As usual I tried to write these minutes as accurately as I could, based on live note taking during the call, some notes I took on the side, and some things I remember. Please review and reply if you think something important is wrong or missing.

XDI TC Minutes

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

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

ATTENDING

Drummond Reed
Peter Davis
Markus Sabadello
Jim Fournier
Joseph Boyle
Ning Zhang
Les Chasen
William Dyson
Phil Windley
Dan Blum
Courtney Brown

GUESTS

André Martins
Matthew Sutton
Jamie Clark

REGRETS

NEWS & UPDATES

PRESENTATIONS/DISCUSSIONS

Report from XDI editors subcommittee

https://wiki.oasis-open.org/xdi/XdiOneSpecs
https://github.com/OASIS-XDI-Technical-Committee/xdi-spec-docbook

Notes from today’s Editors Call:

https://www.oasis-open.org/apps/org/workgroup/xdi-editors/manage/modify_event.php?day=1407481200&event_id=38147

Process questions

William asked how the XDI Editors Subcommittee is organized. Peter explained that in this group, no spec decisions are made, and that the purpose of the weekly call is only to coordinate work in a “scrum” fashion. He also added that the TC can submit requests for editorial changes via a JIRA system.

William also asked specifically how the change known as “notation shift” was approved and whether there was a vote on this change. Drummond replied that for approving changes, either a consensus is achieved, or a vote is held. In the case of the “notation shift”, no vote was held. Drummond added that most of the time the TC tries to advance by consensus, which is recorded in the TC minutes. William asked how the decision is made whether to have a vote or not. Drummond replied that whenever there is no consensus, a vote is held. Jamie added that there are also mandatory votes at certain points in the OASIS spec development process.

Global / local / relative identifiers, peer registries, etc.

The question has come up how an organization with a + cloud name would issue = cloud names and cloud numbers. The two syntax options that have appeared in recent discussions are +org=user and +org=(user).

Markus feels there are three levels to this discussion: 1. The syntax/semantics level (what do the identifiers look like and what do they mean), 2. The functionality/behavior of code that runs in an XDI network and operates on the identifiers, and 3. Governance questions around identifiers.

Drummond’s understanding is that there is confusion about the syntax and usage of absolute and relative identifiers in XDI. Specifically, the difference between +org=user and +org=(user).

The key syntactic and semantic difference is the use of cross-references to establish relative identifiers. To illustrate:

=user1 +org1=user1 +org2=user1 =user2=user1

These all identify the same user (person) in different contexts. The same is true of all XDI contexts. For example:

<#email> =user1<#email> =user2<#email> +org1=user1<#email>

These all identify an email address attribute in different contexts.

So, to make an XDI identifier relative to a particular context, you use a cross-reference. For example, this is how identifiers work in DNS.

www.yahoo.com www.cnn.com www.bar.com

In these identifiers, there is no semantic meaning attached to anything below .com, because each identifier is entirely relative to its parent context.

If you need to express a relative identifier in XDI, you use a cross-reference. The purpose of cross-reference syntax is to use an identifier assigned in one context in a different context. This applies to any identifier that can be used in XDI. Examples:

=(user@example.com)

=(http://user.blog.com)

=(user)

+(http://amazon.com)

+(foobar)

#(http://ontology.com#term)

What makes them a cross-reference and not a peer root is the preceding XDI context symbol. A peer root never has a context symbol preceding it. It always starts with a (. Example:

(=user)

(+org)

(http://example.com)

(user@example.com)

So, if you want to identify a user relative to an organization, there are two choices: to identify the user absolutely or relatively. To do it absolutely, you would use an absolute XDI identifier for the user:

+org=user ⇐ with a reassignable identifier or “XDI name”

+org[=]!:uuid:f81d4fae-7dec-11d0-a765-00a0c91e0001 ⇐ with a persistent identifier or “XDI number”

To do it relatively, you would use a cross-reference:

+org=(user)

+org=([=]!anylocaluniquepersistentID)

The difference is that the semantics of the first example, +org=user, are that the =user identified in this context is the same as the =user identified in any other context. In the second example, =(user) can only be identified in the context of +org. However +org=(user) identifies the same user everywhere +org=(user) is used.

(end of Drummond’s explanations)

Markus asked about the behavior of an XDI discovery client. The answer is that with both options, an XDI discovery client would first discover the XDI endpoint of +org, and then from there discover the XDI endpoint of =user or =(user).

Markus pointed out that in the current XDI Core V1.0 WD02, the use of cross-references for peer roots is explained, but there is no mention of “global” or “local” semantics of identifiers. Markus also noted that the same document explicitly states the goals “to not assume or rely on a central authority” (section 2.2), and that “the uniqueness of identifiers is relative to the context in which identification is required” (section 2.3). A while ago we decided to rename “remote roots” to “peer roots”, to emphasize that in an XDI network, all XDI graphs are considered peers and can (among other things) participate equally in a discovery process.

Jim said that it is a common use case for an organization to issue identifiers for its members. If that organization is required to use the cross-reference syntax, e.g. +org=(user), then that might not be in the best interest of user experience. Phil suggested that XDI should be considered an “assembly language of data”, and that usability should be a secondary concern. Jim disagreed and pointed out that at the moment there is a considerable effort of promoting XDI identifiers (cloud names) to a large audience.

Jim described a situation where two organizations +org1 and +org2 would each want to issue =user names within their context, and without using the cross-reference syntax. How can each organization make sure that the names satisfy the “global” semantics? Drummond explained that the XDI spec would not specify a mechanism for enforcing such semantics, and that the only thing that makes a name global is consensus within a community.

Joseph asked what was today’s equivalent of the old * local context symbol. Drummond explained that there is no more distinction between local context symbols (LCS) and global context symbols (GCS). Instead, identifiers are global by default, and the cross-reference syntax is used for local identifiers.

Governor link contracts

Dan requested feedback on governor link contracts in the XDI Policy spec draft:

https://www.oasis-open.org/committees/download.php/53649/XDIPolicyDraft%20v6.docx

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

We did not have time to discuss this topic.

ABNF after notation shift

Joseph requested help with the XDI ABNF, explaining that after the notation shift it would not be possible to have a common ABNF that covers all serialization formats.

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