Minutes: XDI TC Telecon Friday 2014-03-10

XDI TC Minutes

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

Date:  Friday, 7 March 2014 USA
Time:  09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)
ATTENDING

Animesh Chowdhury
Andy DaleDan BlumDrummond ReedMarkus SabadelloJoseph BoyleLes ChasenPeter Davis

GUESTS
Matthew Sutton
Hubert Le Van Gong
NEWS & UPDATES
None scheduled.
PRESENTATIONS/DISCUSSIONS
Reassigning XDI Context Symbols (The Great Symbol Shift)

See these two messages on the mailing list:

https://lists.oasis-open.org/archives/xdi/201402/msg00011.html

https://lists.oasis-open.org/archives/xdi/201402/msg00012.html 

Dan expressed concerned about XDI addressing not being URL-friendly. Peter and Drummond both pointed out “that horse left the barn” a year ago when the TC expanded the XDI addressing character set, and thus XDI addresses must be URL-encoded.

Joseph pointed out that some browsers do not do URL-encoding uniformly. He also asked about XDI messaging supporting HTTP GET. Drummond said that is orthogonal to the Great Symbol Shift issue.

Joseph suggested that in most other languages, square brackets are used on the members of a collection, not on the name of the collection.

Peter suggested that we separate that issue from the Great Symbol Shift.

Drummond then asked for consensus on the Great Symbol Shift, specifically:

Replacing @ with +.

Replacing + with #.

Replacing # with @.

DECISION: There is consensus to proceed to make this revision to the XDI Core spec.

XDI Signatures

Peter and Dan asked for this to be on the agenda so that they can make progress on the XDI Security Mechanisms spec. 

Peter reviewed a discussion with Andy held using Google doc comments. These comments relate to the need, from the TC perspective to:

Don’t constrain signature or hashing algorithms

Specify minimum recommended length but allow longer lengths now and over time

Note that mobile devices may require shorter key lengths with Elliptic curve algorithm for performance reasons

Additional signature metadata from X.509 required, e.g. signing mechanisms

Consider using PEM representation in the XDI graph as an alternative to binary

In other discussion, we noted it would be desirable to add

Clarification that any node or series of nodes in a graph could be signed

Detached signatures support, e.g. a message or a graph could contain a reference to its signature, stored someplace

Caching policies associated with the retrieval of public keys from the graph

Nonces to protect against replay attacks

General (non-normative) guidance on various matters, including MITM and replay protection

It is clear from the discussion that XDI TC will need a more general signatures spec than Respect Network; it is time to separate the documents. 

Action: Peter to create a draft XDI TC version of signatures spec by Friday March 14

Link Contract Addressing

Drummond and Markus have further discussed Link Contract patterns:

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

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

Drummond said the main thrust behind this proposal is the realization that inner roots are the standard way to reify relationships in XDI, and since every link contract by definition (and even by name, i.e., “link” contract) is a graph describing a relationship, we should be “eating our own dogfood” and using inner roots for all link contracts, just as we use them in XDI messaging.

Examples where we use inner roots today:

XDI Messaging - Simple Statement:

FIRST FORMAT (SHORT FORM)

=sender[$msg]!:uuid:1234$do/$set/(=alice/+friend/=bob)

	(equivalent to)

SECOND FORM (NORMAL FORM)

(=sender[$msg]!:uuid:1234$do/$set)=alice/+friend/(=sender[$msg]!:uuid:1234$do/$set)=bob

The end result of the above XDI message operation is that the following statement is added under the common root in the target graph:

=alice/+friend/=bob

XDI Messaging - Inner Root Statement:

This is how an inner root would be added to a target graph:

FIRST FORMAT (SHORT FORM)

=sender[$msg]!:uuid:1234$do/$set/(=charlie/+says/(=alice/+friend/=bob))

	(equivalent to)

SECOND FORM (NORMAL FORM)

(=sender[$msg]!:uuid:1234$do/$set)(=charlie/+says)=alice/+friend/(=sender[$msg]!:uuid:1234$do/$set)(=charlie/+says)=bob

The end result of the above XDI message operation is that the following statement is added under the common root in the target graph:

=charlie/+says/(=alice/+friend/=bob)

	(equivalent to)

(=charlie/+says)=alice/+friend/(=charlie/+says)=bob

RN “Guardian” Relationship:

[=]!:uuid:3333/+guardian/([=]!:uuid:3333/+guardian/[=]!:uuid:1111)

	(equivalent to)

([=]!:uuid:3333/+guardian)[=]!:uuid:3333/+guardian/([=]!:uuid:3333/+guardian)[=]!:uuid:1111

Example from Joseph’s XDI Core  WD 01:

(=example.1/+nominated)=example.2/+chair/@school+board

	WHY NOT this?

(=example.1/+nominated)=example.2/+chair/(=example.1/+nominated)@school+board

Example of new Link Contract Pattern from the LinkContractPattern/Discussion page:

(=alice/@acmebread)@acmebread+register$do/$get/=alice<+email>

	OR?

(=alice/@acmebread)@acmebread+register$do/$get/(=alice/@acmebread)=alice<+email>

	(equivalent to)

=alice/@acmebread/(@acmebread+register$do/$get/=alice<+email>)

Example: Acmebread’s Link Contract Template

<--TA--><--ID-->{$do}/<--operation-->/{$to}<--object-graph-->

@acmebread+address{$do}/$get/{$to}+home+address

Example: Acmebread’s Link Contract Governor

NORMAL FORM

(<--RA-->/<--TA--><--ID-->{$do})$do/$set{$do}/(<--RA-->/<--TA--><--ID-->{$do})({$to}/<--RA-->)<--TA--><--ID-->$do

(@acmebread/@acmebread+address{$do})$do/$set{$do}/(@acmebread/@acmebread+address{$do})({$to}/@acmebread)@acmebread+address$do

(@acmebread/@acmebread+address{$do})$do$if/$true/(@acmebread/@acmebread+address{$do})

	(equivalent to)

SHORT FORM:

@acmebread/@acmebread+address{$do}/($do/$set{$do}/({$to}/@acmebread)@acmebread+address$do)

Example: Acmebread’s Link Contract Specific Instance

(<--AA-->/<--RA-->)<--TA--><--ID-->$do/<--operation-->/(<--AA-->/<--RA-->)<--AA--><--object-graph→

NORMAL FORM

(=alice/@acmebread)@acmebread+address$do/$get/(=alice/@acmebread)=alice+home+address

	(equivalent to)

SHORT FORM:

=alice/@acmebread/(@acmebread+address$do/$get/=alice+home+address)

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.