[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: XDI TC Notes Unofficial Telecon Friday 2015-07-20
Following are the notes of 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.
Peter Davis
Markus Sabadello
Drummond Reed
Les Chasen
Joseph Boyle
Lionel Wolberger
Christopher Allen
Phil Windley
We welcomed Lionel Wolberger (XDI.org) and Christopher Allen (Respect Network) to the TC. Drummond also noted that 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.
Christopher made the point that “rootless” is more than just decentralized. A decentralized replacement of XDI name registry architecture could be like namecoin or other decentralized naming systems. But rootless is like a web-of-trust relative to each user. For example, you can have a relationship with the nickname “Drummond”, who has a relationship to “Drummond’s ChristopherA”, and ChristopherA has a relationship with “Terry” (Drummond’s ChristopherA’s Terry). There have been some past explorations of this idea in various crypographic systems such as SDSI/SPKI and nym, petname, and nickname efforts.
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 needed 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: a mutable XDI identifier that does not use the ! symbol to indicate persistence.
XDI number: a immutable XDI identifier that uses the ! symbol for persistence.
We had a long discussion about this proposal, how much these terms were needed, and whether this was necessary to complete the Core spec (to which Drummond’s answer was Yes). The final conclusion was to make XDI Name a synonym for XDI Mutable Identifier and XDI Number a synonym for XDI Immutable Identifier, e.g.:
XDI Identifier: a unique identifier for an XDI Graph Node
XDI Mutable Identifier: an XDI Identifier that does not use the ! symbol to indicate persistence. Also known as an XDI Name.
XDI Immutable Identifier: an XDI Identifier that uses the ! symbol for persistence. Also known as an XDI Number.
We discussed the need to highlight defined terms in a consistent way across all the specs—and also link them to the Glossary, which would be incorporated into Core (either as a first section or an Appendix).
#EDITORS: Recommend a consistent way to implement this requirement.
Christopher explained that he has been thinking about XDI numbers that have cryptographic properties that would be defined by XDI schemes. He gave some hypothetical examples (that do not yet reflect the restrictions on using XDI delimiters in a scheme name):
*!:mdigest[sha-256-bit58-check]:xxxxxxxxxxxx
*!:publickey:curve25519-xsalsa20-poly1305-bit58-check:7rXYBKi1Xf9g9nupb9f8u6MHbobEJCMK3r3sChjN5RmGN
Chris asked if an XDI scheme name could have a more structured ABNF, e.g.:
*!:scheme:optionalsubtype:\\:xxxx
Drummond explained that the ABNF for XDI scheme names already supported adding simple structure using dash and dot as delimiters, as illustrated in the scheme names for SHA hash types, e.g.:
*!:sha-256:xxx
Drummond said he’d follow up with Christopher to discuss this and see if the current XDI scheme ABNF will work.
We also discussed whether cryptographic scheme names should go into a separate spec. There was a rough consensus that this was a good idea, since it would not require changing Core frequently as new cryptographic scheme types are developed.
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.
The result looks like this:
=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
?? =!:uuid:x-3/$is$memberof/[#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
In discussion of this agenda item, Peter asked if the term “a” is what should be used (as it is in OWL). Drummond explained that the “a” relationship (and the inverse, “is a”) are already expressed by # and $is#, e.g.:
#cat/$is#/#animal
#animal/#/#cat
=peterd/$is#/#person
#person/#/=peterd
Peter agreed, and then pointed out that in OWL, the $has relation would be “memberOf”.
#DRUMMOND will investigate “memberOf” for this term.
We ran out of time to cover this topic but agreed to put it on next week’s agenda.
Peter suggested this topic for next week’s call.
We agreed that we need to start moving open XDI Core spec items into Jira so we can review open items and prioritize.
#CORE EDITORS to move open items into Jira.
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]