[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: XDI TC Unofficial Telecon Notes: Monday 2016-04-18
Following are the notes of the unofficial telecon of the XDI TC held on:
Date: Monday, 18 April 2016 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.
Markus Sabadello
Drummond Reed
Markus Sabadello
Les Chasen
Phil Windley
Recent discussions about blockchain-based identity registries have reopened the subject of defining XDI bindings to connectionless protocols. One suggestion has been RAET (Reliable Asynchronous Event Transport):
https://github.com/saltstack/raet
Markus has begun experimenting with UDP-based delivery of XDI messages. He began by looking at the RAET protocol, which has a large number of headers. He then experimented with sending a plain UDP packet to send a plain XDI message and return a response. In his experiment, he limited the size of the XDI message to fit into a single UDP packet and sent the messages on a best efforts basis, i.e., he did not tackle reliability or acknowledgement. For larger XDI messages, a protocol would need to be developed for packaging each UDP message.
You can view Markus’ experiments with a simple XDI/UDP binding in a branch of the XDI2 codebase:
https://github.com/projectdanube/xdi2/tree/transport-udp
This helped Markus’ thinking about an XDI binding to a connectionless protocol. He found that it is similar to a Websocket binding insofar as there is no implicit correlation between an XDI request and its response. He said one solution to this would be to use what he currently calls “full response messages” (a term from the draft XDI Messaging 1.0 spec) that make the correlation between request and response messages explicit.
Markus believes that RAET is an example of a connectionless UDP protocol that adds these additional features, but he needs to look at it in more detail.
Joseph asked what “plain TCP” binding would look like. Markus said he expected that it would be similar to Websocket, only establishing and closing the connection would be different. However it might make sense.
Last week Drummond learned of a new IETF Internet Draft published by Phillip Hallam-Baker in March.
https://tools.ietf.org/html/draft-hallambaker-mesh-architecture-01
Called “Mathematical Mesh: Architecture”, this is how the introduction explains it:
The Mathematical Mesh is a user centered Public Key Infrastructure
that uses cryptography to make computers easier to use.
The Mesh uses cryptography and an untrusted cloud service to make
management of computer configuration data transparent to the end
user. Each Mesh user has a personal profile that is unique to them
and contains a set of public keys for maintaining the user's Mesh
profile.
This is very similar to how the XDI TC has been discussing how XDI architecture can address the issues of a Decentralized Public Key Infrastructure (DPKI).
We reviewed some of the key concepts of this Internet Draft to see how they intersect with our plans for the XDI Cryptography 1.0 spec, which defines XDI structures for cryptographic concepts, e.g., signatures, keys, hashes. Markus pointed out that we do not plan for the XDI Cryptography 1.0 spec to define a complete decentralized PKI, however it could be used as supporting material for doing that in a separate spec (from the XDI TC or others).
Because Markus was not on the last call, Drummond again reviewed what he wrote up on the following wiki page about semantic filtering to show that it is an orthogonal topic to either direct or group messaging.
https://wiki.oasis-open.org/xdi/SemanticFiltering
Drummond explained that there were two key insights represented in this writeup:
What we have been calling “channels”—and planning to define a $channel word for—are in fact just semantic categorizations (specializations) of [msg] collections. So, for that purpose, we don’t need a dedicated $word.
By contrast, the concept of message threading—the association of a set of messages with a specific subject/topic—does require an explicit $word. The wiki page proposes $thread for this purpose.
Drummond said that the work that still remains to complete this proposal is to define how to link threads to create rich, linked semantic conversations.
Markus asked about message ordering within a message collection—which applies no matter if the message collection is within a channel or a thread or both. Drummond replied that he has been thinking that messages, as an entity that includes a timestamp attribute, could always be ordered by that timestamp, and that this approach would not require an ordered collection. However an ordered could also be used.
Joseph asked about the case where a message is received that has an earlier timestamp than messages already in the collection. Drummond said that was not an XDI problem, but could be a UI problem. If an XDI subgraph has a policy for state changes, such as a message collection only accepting new messages with a timestamp later than the most recent message in the collection, that is an endpoint policy enforcement question.
Markus asked about timestamp authority, i.e., who adds the timestamp—the XDI agent (client) or the XDI endpoint (server). Drummond asked how the policy works in email. Markus said that each hop in the delivery path adds its own timestamp, and that we could do the same thing.
Returning to our work on group messaging, Markus has added more information and examples about link contracts and messages to the wiki page:
https://wiki.oasis-open.org/xdi/GroupMessaging
# ACTION ITEM: DRUMMOND to add example of a group having a group as a member.
We discussed the subscription statement in the push contract (the second statement in the example below, taken from the wiki page):
(+!:uuid:x-1/+!:uuid:x-1)$push$do/$push/+!:uuid:x-1[$msg]
(+!:uuid:x-1/+!:uuid:x-1)($push$do$if$and/$true)+!:uuid:x-1/$has/{$to}
(+!:uuid:x-1/+!:uuid:x-1)($push$do$if$and/$true){$msg}<$sig><$valid>/&/true
Drummond was puzzled about the second statement above, because it does not seem like a normal policy condition, but rather a way of specifying the subscribers to the push messages. By contrast, this was what we had discussed earlier as the “subscriber statement” in a push link contract:
(+!:uuid:x-1/+!:uuid:x-1)$push$do/$is()/{+!:uuid:x-1/$has}
If we used a statement like this (containing a relational variable), a full push contract would look something like this.
(+!:uuid:x-1/+!:uuid:x-1)$push$do/$push/+!:uuid:x-1[$msg]
(+!:uuid:x-1/+!:uuid:x-1)$push$do/$is()/{+!:uuid:x-1/$has}
(+!:uuid:x-1/+!:uuid:x-1)($push$do$if$and/$true)+!:uuid:x-1/$has/{$from}
(+!:uuid:x-1/+!:uuid:x-1)($push$do$if$and/$true){$msg}<$sig><$valid>/&/true
In this example:
The first statement defines the subgraph covered by the push link contract (i.e., the subgraph for which changes will be pushed to any subscriber).
The second statement defines the subscribers (either by a variable or by enumerating them directly).
The third and fourth statements are standard link contract policy statements that must be satisifed for the push link contract to be “fired”.
This discussion brought up the whole concept of “transformation policies”—policies that are applied to the processing of a message and not to the enforcement of a link contract. These are somewhat similar to “message policies” that Markus has been defining in XDI Messaging 1.0.
This link shows the section of XDI Messaging 1.0 that Markus has drafted for specifying conditions for execution of a message at an XDI endpoint. By contrast, transformation policies would govern is transformations to an XDI message that are applied if the conditions of a transformation policy are satisfied.
Markus pointed out this is essentially “applying an XDI message to an XDI message”, i.e., treating an XDI message (which is itself an XDI graph) just like any other XDI graph and making a set of changes to it as defined by another XDI message.
Drummond agreed, feeling that it was a very elegant approach. And that we already knew we would need XDI transforms to transform XDI data between one XDI dictionary format and another, much like CSS stylesheets can transform between one XML format and another.
Markus said that we already have an number of use cases that require message transformation, so tackling transformation policy is something we need to define anyway.
The next call will be NOT be next week due to Internet Identity Workshop and another conference on PIMS (Personal Information Management Services) in Paris. The next call will be May 2 at the usual time (Monday 10AM PT). The link to where agenda items can be posted for the next meeting is: https://docs.google.com/document/d/19oDl0lbb56Grehx2a5flZnhrgnua5l8cVvC_dJ8fTXk/edit?usp=sharing
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]