XDI TC Notes

Following are the notes of the unofficial telecon of the XDI TC held on:

Date: Monday, 17 August 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.

ATTENDING

Lionel Wolberger

Peter Davis

Markus Sabadello
Drummond Reed
Christopher Allen
Les Chasen
Peter Davis

REGRETS

Phil Windley

XDI Variables Section of XDI Core

Drummond is currently working on this section and would like to close on the issue formerly known as “Named Variables”. See https://wiki.oasis-open.org/xdi/XdiVariables

Drummond reviewed the updated content on this wiki page that will go directly into the Variables section of XDI Core.

Christopher asked about the scope of an XDI query using a variable and whether it revealed any information beyond the authorization of a link contract. Drummond and Markus explained that the response would be limited to the scope of the subgraph(s) authorized by the governing link contract. There would not be any indication of additional information available unless the authority for the graph wanted to add such indications within the scope of the authorized subgraph.

Lionel suggested to add to the table some verbiage regarding the examples in the table. For example, where the table now says {$from}- matches a specific reserved class, rewrite this to spell out the example, i.e., “{$from}- matches a specific reserved class, e.g. in this example, matches the reserved class ‘from’”.

We also talked about whether in RDF there is an equivalent to XDI variables. Peter said there was no variable notation in RDF, but the same concepts existed. Peter also said that the purpose of XDI variables is to constrain the allowed structure of a graph, which in RDF would be done using RDF Schema and OWL. Markus felt that the XDI equivalent to RDF Schema and OWL was definitions, not variables. Probably the closest equivalent to XDI variables in RDF can be found in the query language SPARQL.

Drummond asked whether SPARQL was itself expressed in RDF. Markus clarified that this was not the case. Lionel then asked whether it made sense that XDI messages are themselves expressed in XDI. Drummond and Markus argued that the advantages of this approach are that XDI messages can themselves use all the features of XDI such as global addressability, versioning, link contracts. For example, XDI messages can be stored in an XDI graph and shared later. Also, cryptographic operations such as signatures and encryption can be applied to XDI messages in the same way as to any other XDI (sub-)graphs.

XDI Definitions Section of XDI Core

Drummond reviewed the updated content on this wiki page that reflects the star shift and relativity symbol. See:

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

Christopher asked whether we have defined any concrete schemas, e.g. for profiles. Drummond said no, but there was concrete work happening now to define a profile schema. We talked about the schema.org effort to define ontologies for RDF. Christopher asked whether we can re-use such definitions. Drummond explained that this was the case.

Christopher wondered about potential symbol collisions (e.g. the _ underscore) if schema.org / JSON-LD identifiers were used in XDI. Drummond explained that this should be no problem, since in XDI the _ underscore only has a special meaning at the beginning of an identifier and can be used as a normal character inside an identifier. Christopher asked about how XDI syntax and $words related with JSON-LD. What is the meaning of _ underscore in JSON-LD?

#DRUMMOND will find the appropriate reference.

[Editor’s note: the reference is http://www.w3.org/TR/json-ld/#syntax-tokens-and-keywords. The only syntax used by JSON-LD is @words. RDF itself uses underscores to identify blank nodes. See http://www.w3.org/TR/json-ld/#identifying-blank-nodes. ]

Christopher also asked if bang (!) be used in the middle of an XDI identifier (i.e., after it would appear as the immutability symbol).

[Editor’s note: The answer is no, it can only be used as the immutability symbol.]

Drummond went over example definitions and explained global vs. local definitions, and various combinations that are possible.

Messaging Walkthrough and XDI Channels

Markus showed this presentation:

https://www.oasis-open.org/committees/download.php/56299/Message%20Forwarding.pdf

The presentation covers cases where an XDI message sent from one peer to another peer results in one or more additional messages sent to further peers. Three different approaches are described: 1. Forwarded message, 2. Proxied message, 3. Nested message.

The following is a list of examples of 3 levels of specifying the origin and sender of a message: 1) just from the sender, 2) from a sender and the sender’s peer root, 3) from a sender and a sender’s peer root and a peer subroot:

(=markus)/$set/=markus[$msg]*!:1234

(=markus)(*!:uuid:3333)/$set/=markus[$msg]*!:1234

(=markus)(*!:uuid:3333)/$set/(=markus)=markus[$msg]*!:1234

(=markus)(*!:uuid:3333)/$set/(=markus)(*!:uuid:3333)=markus[$msg]*!:1234

We talked about different uses cases, where sometimes a receiving peer root should “see” the full trail and properties (including signatures) of an original message, whereas in some other use cases a receiving peer should only “see” part of that information. This may require modifying/transforming the message as it propagates through one or more intermediate peers before reaching its destination.

While going over the presentation and the above examples, Markus felt he didn’t yet understand well enough the exact behaviors of an XDI sending peer root, receiving peer root, and sending entity.

Markus mentioned that he liked to use the analogy of TCP/IP to describe the process of sending XDI message via a number of peer roots. In this regard, XDI peer roots fulfill a similar role as IP addresses, and concepts such as IP routing, NAT, or even advanced functions such as anonymizing proxies or onion routing could be realized for XDI messages. Drummond suggested that perhaps a “message transformation language” could be supplied as part of a link contract that controls the next step in a routing process.

Christopher brought up the topics of message trails and auditing (e.g. for HIPAA compliance). Christopher mentioned that in SMTP, you have message headers that can be used to trace a message’s path, and that therefore XDI should have a similar capability. Markus felt that such “routing” information can be useful both as a log after a message has been sent, but also potentially as pre-supplied instructions to influence the routing process while it takes place.

Christopher also brought up the topic of cryptographic XDI numbers, zero-knowledge proofs, and how such advanced concepts can influence XDI messaging.

With regard to Markus’ presentation, Peter warned that it would be better to have complete examples that also include authentication and link contracts, in order to make sure that no important security-related details are missed. Markus agreed and pointed out that in his presentation, these topics were left out intentionally in order to focus fully on addressing and routing aspects.

NEXT CALL

The next call is next week 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

xdi message