[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes: XDI TC Telecon Friday 2014-03-10
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)
Animesh Chowdhury
Andy Dale
Dan Blum
Drummond Reed
Markus Sabadello
Joseph Boyle
Les Chasen
Peter Davis
Matthew Sutton
Hubert Le Van Gong
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.
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
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)
None scheduled.
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
The next call is next week at the regular time.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]