XDI TC Minutes

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

Date: Friday, 22 May 2015 USA <== NOTE THE NEW CALL TIME BELOW
Time: 09:00AM - 10:30AM Pacific Time <== NOTE THE NEW CALL TIME BELOW

ATTENDING

Peter Davis
Drummond Reed
Markus Sabadello
Phil Windley
Les Chasen
Joseph Boyle

Revisit New XDI TC Call Time

Although we had decided to move the XDI TC call to Mondays 9-10:30AM Pacific Time starting the week of May 25, it turns out Dan Blum has a conflict at that time. After discussion among those on the call:

#CONSENSUS - The weekly telecon will move to 10AM PT on Mondays starting June 1.

Also note that the weekly XDI2 call on Thursdays is moving from 11AM to 1PM Pacific Time.

Update on XDI Security Mechanisms

Drummond noted that he had a full day meeting with Christopher Allen, co-author of the SSL 3.0 standard, about XDI security mechanisms and the use of XDI with blockchain technologies. Chris had just published the following article:

http://www.reddit.com/r/Bitcoin/comments/36mhs1/revocable_selfsigned_tls_certificates_using_the/

Chris was particularly interested in XDI canonicalization for digital signatures and in XDI connectors for building data bridges between legacy and blockchain-based systems.

Update on XDI Core 1.0

Drummond reported that while he had not drafted another new section yet, he did work on a revised outline for the XDI Addressing section. He plans to finish the XDI Variables section before the June 1 TC meeting.

Op and Non-Op Messages

Work on the XDI Messaging spec raised the possibility that it may be necessary to distinguish between:

XDI messages that request an operation on the graph (“op messages”)
XDI messages that do not request an operation on the graph but only deliver content directly in the body of the message (“non-op messages”).

Here are the arguments for why the XDI Messaging spec should make this distinction:

Every XDI message is itself a change in graph state. Whether the message is saved in the graph or not, it is always a change in graph state. An operational message may explicitly change graph state. But even a non-operational message that contains human content (e.g., the XDI equivalent of a text message or email message) should have the option of being saved in the graph, which is a change in graph state.
The human-readable content of a non-operational message is most naturally a property of the message itself, not of any other entity. This is the way it works with email and text messaging.
The inverse is also true, i.e., the message metadata associated with the body of non-op message (such as a text or email) is most directly associated with the message envelope.
Link contracts for non-operational messages are simply a special case of $do link contracts. More on this below.

A non-op message could be identical to a op message except:

It would not include the authorization statement (template line #7 on https://wiki.oasis-open.org/xdi/XdiMessagePatterns) or operation statement(s) (template line #8).
It would include one or more non-operational message “body” attributes.

Following are examples of possible attributes of a non-op message:

=drummond[$msg]*!:uuid:x-1[<#text>]<@0>/&/”Hi Markus”

=drummond[$msg]*!:uuid:x-2[<#mail>]<*!:uuid:x-3>/&/”body-of-mail”

One way to recognize these as non-op messages would be associated type statements:

=drummond[$msg]*!:uuid:x-1/$is#/$text$msg

=drummond[$msg]*!:uuid:x-2/$is#/$mail$msg

Another option is for a non-operational message to be a specialization of a standard $msg. Here are the same two examples as above, but showing this specialization:

=drummond$text[$msg]*!:uuid:x-1[<#text>]<@0>/&/”Hi Markus”

=drummond$mail[$msg]*!:uuid:x-2[<#mail>]<*!:uuid:x-3>/&/”body-of-mail”

One problem with these options is that even operational messages can have multiple types, so it may not be a fundamental enough distinction.

A more fundamental distinction would be to use a different message entity name, e.g.:

=drummond[$xfer]*!:uuid:x-1[<#text>]<@0>/&/”Hi Markus”

Non-Op Message Link Contracts

Another consideration is that non-op messages are in fact requesting exactly one operation—the one operation inherent in all XDI messaging: the $set (or $add—we need to decide which is the precisely correct semantics) of the message itself.

This could be done with an abbreviated link contract. For example, to authorize non-op messages from a particular RA, the AA simply needs to set a non-$do message link contract using the following template.

(<--AA-->/<--RA-->)$do/$set/<--RA-->[$msg]{}

If the $msg specialization option is chosen, then the templates would look like:

(<--AA-->/<--RA-->)$do/$set/<--RA-->$text[$msg]{}

(<--AA-->/<--RA-->)$do/$set/<--RA-->$mail[$msg]{}

Or, using a blanket variable:

(<--AA-->/<--RA-->)$do/$set/<--RA-->{[$msg]}{}

The rules for such link contracts could be:

If a message is an op message, then it MUST reference an op link contract, otherwise it will be rejected.
If a message is a non-op message, then it MUST be covered by a non-op link contract, otherwise it will be rejected.
If a message is both op and non-op, then it MUST be covered by both link contracts.

Discussion

After a long discussion of the topic, including discussing how non-operational messages would affect message processing, Phil pointed out that the most fundamental distinguishing feature of XDI messaging is that it functions as operations on a standard semantic graph, and that creating a new class of message that breaks that rule would not add enough value to justify an exception.

There was a consensus that “non-operational” messages—and their various efficiency advantages described above—should not be a separate type of XDI message, but instead should be a standard XDI $set or $add message to standard collection.

#ACTION: DRUMMOND AND MARKUS to prepare a new proposal on how this should work for “XDI text” and “XDI mail” messages.

Messaging Channels

Directly related to the previous topic is the question of message channels and the potential need for a $channel dollar word. Drummond pointed out that such channels appear to only be needed primarily for messages designed to transmit human-readable content.

Although we had only a little time left to discuss this topic, Peter pointed out that in a pub/sub platform, a channel (also called a topic) is used to establish what subscribers can subscribe to. Drummond pointed to the analogy to categories and tags in blogging.

Peter said that it should always be the subscriber who determines how a message is treated, whether it is stored or not, how it is forwarded, etc. This can potentially be done with a link contract which subscribers can create for themselves (i.e. the subscriber is both RA and AA).

Peter also talked about the benefits of having both local and global vocabulary for defining channels/topics:

Global vocabulary is needed to establish common semantics across communities, systems, apps, etc. An example is common vocabulary around politics and elections.
Local vocabulary is needed to establish shared semantics needed only in the context of a specific community. For example, the current political issues and candidates in the State of Washington in the United States vs. the current political issues and candidates in Austria.

#ACTION: DRUMMOND AND MARKUS to include a proposal for how channels work as part of the action item above.

NEXT CALL

The next call is Monday June 1 at the new time (10AM PT).

xdi message