Re: [xdi] Minutes: XDI TC Telecon Friday 2014-08-01

["=Drummond Reed" <drummond.reed@xdi.org>]

Markus, I just wanted to say: great job with these minutes. They read very well.

I was also particularly happy with the two solutions generated on today's call. They seem clean, powerful, and consistent with XDI messaging, which IMHO is a good thing.

One note: at the end of the call, I proposed two topics to cover on next week's call (if not before in email):

1. Dan's request for feedback on governor contracts in the Policy spec.
2. Hubert's request for input on a number of the shorter JIRA tickets regarding clarification of topics in XDI Core.

Have a great weekend,

=Drummond 

On Fri, Aug 1, 2014 at 8:58 PM, Markus Sabadello <markus.sabadello@xdi.org> wrote:

XDI TC Minutes

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

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

ATTENDING

Peter Davis
William Dyson
Ning Zhang
Markus Sabadello
Drummond Reed
Eno Jackson
Joseph Boyle
Hubert Le Van Gong
Courtney Brown
Les Chasen

GUESTS

Matthew Sutton

REGRETS

Phil Windley

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

Peter reported that on the XDI editors subcommittee call, writing specs directly in Docbook has been found to be problematic. The consensus is for everybody to choose their own preferred editor, and then convert content to Docbook. For example, Dan had been writing his XDI Policy drafts using MS Word.

Peter also proposed to change the time of the XDI editors subcommittee call to Fridays 11:30am ET (i.e. directly before the XDI TC call), in order to avoid conflicts with the XDI2 project call. There was universal agreement to make this change, and it will be in effect starting next week.

XDI signatures

Continue to discuss XDI signatures:

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

https://lists.oasis-open.org/archives/xdi/201405/msg00030.html
https://lists.oasis-open.org/archives/xdi/201405/msg00020.html

At the beginning of the discussion about XDI signatures, Peter reminded us that this topic is linked to the “Automatic singleton/collection conversion” topic (see below). Under the current proposal, if a signature covers a singleton, but then the singleton is converted to a collection, the serialization would change and therefore the signature would become invalid, e.g in the following situation:

=peterd<#home><#email>&/&/"peterd@gmail.com"

change value:

(.../$set)=peterd<#home><#email>&/&/"peterd@gmail.com"

auto-convert into collection?

(.../$add)=peterd<#home><#email>&/&/"peterd2@gmail.com"

result after auto-convert into collection?

=peterd<#home><#email>/$ref/=peterd<#home>[<#email>]<!:uuid:1234>

=peterd<#home>[<#email>]<!:uuid:1234>&/&/"peterd@gmail.com"

=peterd<#home>[<#email>]<!:uuid:3456>&/&/"peterd2@gmail.com"

Markus proposed that in order to solve this problem (and others), the process of generating a normalized string for signature creation/validation should include behavior similar to that of $get operations. This means the signature could include:

#1. $get operations, to specify which parts of the graph are covered by the signature. If the signature does not include a $get operation, the default is to cover the subgraph the signature is in.

Example:

=markus/#friend/=peterd

=markus/#friend/=joseph

=markus/#friend/=animesh

Current way of “reifying” a relational statement for the purpose of signing it:

(=markus/#friend)=joseph<$sig>&/&/"..."

Proposed new way of specifying which statements and subgraphs are covered by a signature:

=markus[<$sig>]<!:uuid:1234>&/&/"..."

=markus[<$sig>]<!:uuid:1234>/$get/=a=b=c

=markus[<$sig>]<!:uuid:1234>/$get/=d=e=f

(=markus[<$sig>]<!:uuid:1234>/$get)=markus/#friend/=peterd

(=markus[<$sig>]<!:uuid:1234>/$get)=markus/#friend/=joseph

#2. Operation parameters such as $deref, which influence the result. This way, a signature could remain valid even after a singleton has been converted to a collection.

Example:

=peterd<#home><#email>&/&/"peterd@gmail.com"

=peterd<#home><#email><$sig>&/&/"...."

=peterd<#home><#email><$sig><$deref>&/&/true

result after auto-convert into collection?

=peterd<#home><#email>/$ref/=peterd<#home>[<#email>]<!:uuid:1234>

=peterd<#home>[<#email>]<!:uuid:1234>&/&/"peterd@gmail.com"

=peterd<#home>[<#email>]<!:uuid:3456>&/&/"peterd2@gmail.com"

If a $get operation is executed against the above graph, the result (given the <$deref> operation parameter) would still be:

=peterd<#home><#email>&/&/"peterd@gmail.com"

Question: Is the <$deref> operation on the signature really needed, or should it always assumed to be true? Should the default be true or false?

Peter will try to summarize these insights and include them in the next version of the XDI signature spec draft.

Automatic singleton/collection conversion

Peter described a situation where one would have an attribute singleton in the graph, e.g. <#email>, and then later decide that a collection [<#email>] would be needed to add additional attributes.

See the following thread and also recent TC minutes for more thoughts on this topic.

https://lists.oasis-open.org/archives/xdi/201407/msg00029.html

We further discussed the re-introduction of a $add operation and its behavior with regard to singletons and collections. We talked about the following ideas but did not reach a conclusion:

- When adding new members to a collection, either the client or server could generate member identifiers. One question is how a distinction should be made between ordered and unordered collections.

- If the server generates a member identifier, it could be returned as part of the message result. The rule could be that in the case of a $add operation, the message result would contain the modified graph structure, e.g. the result of a singleton->collection conversion, and/or a new member of a collection.

We recalled that at some point in the past we used variable for similar functionality, e.g:

(.../$set)=peterd<#home>[<#email>]{1}&/&/"..."

response:   {1}/$is/<!:uuid:4321>

Read-only / Append-only

In a message thread within Respect Network, the question has come up whether certain parts of a graph can be “read-only” or “append-only”.

See the following thread and also recent TC minutes for more thoughts on this topic.

https://lists.oasis-open.org/archives/xdi/201407/msg00035.html

We did not (much) further discuss read-only / append-only behavior.

Further issues

Drummond noted he would talk to Dan about outstanding issues related to the governor link contracts.

Joseph requested Drummond’s 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.

NEXT CALL

The next call is next week at the regular time.