[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Agenda: XDI TC Telecon Monday 10:00 - 11:30AM PT 2015-07-20
Following is the agenda for the unofficial telecon of the XDI TC held on:
Date: Monday, 20 July 2015 USA
Time: 10:00AM - 11:30AM Pacific Time (17:00-18:30 UTC)
The TC operates under a standing rule approved 17 July 2008 under which the TC does not hold regular official meetings and conducts all business by electronic ballot only. Unofficial weekly meetings are held to enable discussion among members but no business is conducted nor actions taken.
THE LINK TO THIS AGENDA AND LIVE MEETING MINUTES IS:
https://docs.google.com/document/d/1t5Mx0ITqJdLwo8wM5GD9lcqehgbgnrhk-k2sERwc7J0/edit
Meeting number: 658 320 206
Meeting password: xdi
Join by phone
1-650-429-3300 Call-in toll number (US/Canada)
1-866-469-3239 Call-in toll-free number (US/Canada)
Access code: 658 320 206
Global call-in numbers | Toll-free calling restrictions
IRC Channel: irc://irc.freenode.net:6667/xdi
Lionel Wolberger (XDI.org) and Christopher Allen (Respect Network) have joined the TC. Dan Blum is taking a summer sabbatical.
Both Lionel and Christopher are involved with a new XDI.org project called the XDI.org Registry Working Group. The goal is to create a “rootless” XDI registry that can serve the public’s need for persistent, authenticatable XDI identification without requiring a centralized registry.
Several months ago Drummond asked on a TC call whether in the XDI Namespace Architecture section of the XDI Core spec we should call reassignable XDI identifiers "names" and persistent XDI identifiers "numbers".
The consensus at that time was that we should not use the term “number” for this purpose, as it might introduce confusion that an XDI persistent identifier did not actually have to be a number.
However since that time Drummond has noticed that in conversations about XDI addressing—which happen all the time because it's the heart of dealing with XDI graphs—the participants in the conversations invariably refer to some variant of "name" (e.g. "i-name", "XDI name", or "cloud name") and some variant of "number" (e.g., "i-number", "XDI number", or "cloud number") when referring to reassignable and persistent XDI identifiers. It's just natural, because the distinction between these two types of identifiers is so fundamental to the structure and traversal of XDI graphs.
Drummond also noted that the very widely used term "IP number" refers to Internet Protocol addressing strings that have never been strictly numbers, but hierarchical text strings. In IPv4, such strings consisted of numeric elements separated by dot, but starting with IPv6, they become alphanumeric strings (hex).
Because of the sheer utility of these terms, in preparation for drafting the XDI Namespace Architecture section of XDI Core, Drummond would like to resubmit a proposal to formally define two terms for the XDI glossary:
XDI name: an XDI identifier that does not use the ! symbol to indicate persistence.
XDI number: an XDI identifier that uses the ! symbol for persistence.
While working on XDI secure messaging, and in particular use cases where XDI authorities need to control XDI messaging by $channel, Markus and Drummond ran across the pattern where one XDI entity needs to be referenced in the context of another XDI entity, but where the referenced entity does not need to be an actual subcontext of the referencing entity.
For example, say the following XDI message entity...
=sender[$msg]*!:uuid:x-1
...needs to be sent “in” the following XDI channels:
=sender[$channel]*!:uuid:x-2
=sender[$channel]*!:uuid:x-3
=sender[$channel]*!:uuid:x-4
This means the same message is being sent in three different contexts (the channels). To avoid replicating the message, it needs to be referenced from all three channels. However, doing this with a standard $ref equivalence relation requires:
Adding the XDI address of the message as a subcontext of each channel.
Making this new subcontext a $ref to the original message.
This looks like:
=sender[$channel]*!:uuid:x-2=sender[$msg]*!:uuid:x-1/$ref/
=sender[$msg]*!:uuid:x-1
=sender[$channel]*!:uuid:x-3=sender[$msg]*!:uuid:x-1/$ref/
=sender[$msg]*!:uuid:x-1
=sender[$channel]*!:uuid:x-4=sender[$msg]*!:uuid:x-1/$ref/
=sender[$msg]*!:uuid:x-1
This is inelegant for two reasons:
The statements are much longer than they need to be because of redundant info in each statement (highlighted in bold).
From a semantic standpoint, each statement must be analyzed to see that the XDI address of the object is a subset of the XDI address of the subject.
Markus and Drummond realized that a more elegant solution would be an XDI keyword that expresses context-by-reference instead of context-by-value. Context-by-value is what is expressed by XDI contextual relations today:
=a#b//*c
*c/$is()/=a#b
This is “by value” since the parent context directly contains the child context. Note that because the context-by-value relation is expressed as the empty string, its inverse is expressed as $is().
Context-by-reference is needed in cases where the parent context does not need to directly contain the child context as a subgraph its own semantic tree, but instead needs to reference the child context as being a logical branch of its semantic tree.
As with many other XDI keywords ($is, $and, $or, $not), there is an English language grammar word that fits this semantic nicely: “has”. So Drummond proposes a new keyword, $has, to express context--by-reference.
=a#b/$has/*c
*c/$is$has/=a#b
When we apply this to the examples above where XDI messages need to be categorized by (but not actually contained in) message channels, the statements become much shorter and more intuitive.
=sender[$channel]*!:uuid:x-2/$has/=sender[$msg]*!:uuid:x-1
=sender[$channel]*!:uuid:x-3/$has/=sender[$msg]*!:uuid:x-1
=sender[$channel]*!:uuid:x-4/$has/=sender[$msg]*!:uuid:x-1
This helps make it clear that the purpose of an XDI channel is to serve as a semantic index for messages. With the $has relation, any XDI graph node can serve as an index of other graph nodes. Even generically, the $has relation can be used whenever an XDI subgraph needs to include another XDI subgraph by reference rather than by value. A common example is XDI signatures, where the signature needs to cover subgraphs outside of its own.
In addition, the $has relation can be used to formally defined the members of any +group. For example, to define the three members of a household:
[#household]+!:uuid:x-4/$has/=!:uuid:x-1
[#household]+!:uuid:x-4/$has/=!:uuid:x-2
[#household]+!:uuid:x-4/$has/=!:uuid:x-3
All of these can also be expressed in the inverse:
=!:uuid:x-1/$is$has/[#household]+!:uuid:x-4
=!:uuid:x-2/$is$has/[#household]+!:uuid:x-4
=!:uuid:x-3/$is$has/[#household]+!:uuid:x-4
Note that context-by-reference relations, similar to context-by-value relations, are also a way of nominalizing (making a relation into an entity) what otherwise can be expressed as a relation. For example, household membership could also be expressed as follows:
=!:uuid:x-1/#household/+!:uuid:x-4
+!:uuid:x-4/$is#household/=!:uuid:x-1
And a channel relationship could be expressed as follows:
+!:uuid:x-4[$channel]*!:uuid:x-5/$is$channel/=sender[$msg]*!:uuid:x-1
=sender[$msg]*!:uuid:x-1/$channel/+!:uuid:x-4[$channel]*!:uuid:x-5
On several recent XDI TC as well as XDI2 implementation calls, we have been working on a walkthrough for a "secure, semantic messaging" use case. This combines concepts from the XDI Messaging, XDI Bindings, XDI Policy, and XDI Connections specs. It also introduces the concept of “channels”. We will continue to add more details to the walkthrough and answer any questions.
https://wiki.oasis-open.org/xdi/MessagingWalkthrough
The next call is next week at the usual time (Monday 10AM PT).
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]