[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: XDI TC Notes Unofficial Telecon Friday 2015-08-24
Following are the notes of the unofficial telecon of the XDI TC held on:
Date: Monday, 24 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.
Lionel Wolberger
Peter Davis
Markus Sabadello
Drummond Reed
Christopher Allen
Les Chasen
Phil Windley
Christopher Allen posted this change request to change the relativity symbol from underscore to tilde. So far the response from TC members has been uniformly in favor. We will check to be sure we have consensus.
Peter noted that readability of XDI addresses is now a low priority and so the readability of tilde vs. underscore is a minor issue. Peter expressed some concern that every change slows progress and should only be made if necessary.
Drummond reiterated that if tilde is used, we MUST reserve it for this use in the ABNF—that is one of its prime advantages over underscore.
#CONSENSUS - we will make this change in the ABNF.
We need to discuss the format of variables that contain a variable. These are needed for templates. Example link contract template:
+respect#full{$do}/$all/
(+respect#full{$do}$if/$true$and){{$msg}}<$sig><$valid>/&/$true
(+respect#full{$do}$if/$true$and){{$from}}/$is/{$from}
Markus has been experimenting with {$~from} instead of {{$from}}. He explained that his instinct is to not break the symmetry of only allowing one set of brackets for any XDI context role. Variable syntax would be the only bracket that allows one level of nesting.
We discussed how this is handled in other programming languages. Typically it is a dollar sign or brackets added to the variable. Christopher did some research and found that other JSON templating approaches such as Tempo use percentage signs to enclose the variable inside squiggly brackets, e.g.:
(+respect#full{$do}$if/$true$and){%$from%}/$is/{$from}
However we noted that the percent sign is currently reserved for escaping of Unicode characters, so it would be dangerous to overload it.
We also discussed using backslash, e.g.:
(+respect#full{$do}$if/$true$and){\$from}/$is/{$from}
Peter noted that we should avoid any character that has a special meaning in JSON.
At this point it appears that enclosed variables, e.g., {{$from}}, are the simplest and most consistent approach.
This week is “XDI Core 1.0 Immersion Week”. We reviewed Drummond’s first update to the XDI Core 1.0 draft:
https://www.oasis-open.org/committees/document.php?document_id=56341&wg_abbrev=xdi
This draft contains revisions to all the sections up through the Definitions section that reflect the reclassification of = and + identifiers as XDI instances. It also includes new versions of the peer root and inner root conceptual diagrams.
The only section on which we focused discussion was the introductory portion of the Instances section. Drummond explained that the table that lists XDI context symbols used to keep “instances” and “authorities” separate, and that this was changed to consider authorities as instances too, so now the table lists “person”, “group”, “thing”, and “order” as instances. They each have their own chapter in the spec to define them in more detail.
Drummond noted that he is now using $iri instead of $uri in the spec everywhere. Christopher said that there are likely more “internationalization issues” to take care of, such as normalization. Joseph said that best practice was to use “composed normalization form”, and that maybe we should discuss the set of Unicode characters that are allowed in XDI names. Peter and Joseph added further details about the “homographic problem”. In the context of ongoing discussions about decentralization, Peter argued that registries are a good thing, since they can deal with attack surfaces based on names (e.g. distinction between similar characters ç and c). Peter suggested this was out of scope for the XDI TC and should be a task for individual registries.
Markus observed that the introductory “instances” section mentions link contracts and asked whether that term is further defined in the Core spec. Christopher said that the Core spec should just contain a pointer to the Policy spec, where link contracts are defined.
We had a longer discussion about the legal ramifications of link contracts and did some editing of the text to reflect that they will be discussed in the XDI Policy specification. One position was that things (expressed by the * context symbol) can have link contracts, but they are not legally binding, since things are not authorities. Peter suggested that things are owned/controlled by authorities, who have legal responsibility. Therefore, perhaps a thing should always be in the context of a legal authority (person, group), in order to be part of a link contract? “You can’t sue a thing, only someone who controls the thing”. Peter also argued that the XDI TC should not talk about law. Peter and Christopher continued to discuss issues of accountability, arguing that link contracts can have two basic functions: 1. access control, and 2. legal document.
Les was concerned whether we propose that things cannot accept/create link contracts. Drummond clarified that this was not what was being discussed. Specific communities such as Respect Network may define that things MUST always be in the context of an authority.
Markus then asked if the term “unordered” was still being used in the spec. Drummond said that the section on “Order” defines both ordered and unordered instances. Drummond said he added language to the spec that ordering using the @ context symbol can be expressed in a non-default way (the default being numeric, i.e. @0, @1, etc). In this case, an XDI scheme may be defined that has a different concept of ordering (e.g. alphabetic).
Peter once again said that for cryptographic operations such as signatures, it is important to be able to serialize an XDI graph into a string in a deterministic way, which includes the problem of ordering the graph’s statements. Drummond explained that “explicit ordering using @” and “graph statement ordering” are two different topics, with the latter one happening at a lower level. We asked which spec would define “graph statement ordering”. We also asked whether the “Cryptographic Profiles” spec should be called “Cryptographic Mechanisms”. Markus asked about the boundary between “Cryptographic Profiles/Mechanisms” and “Security Mechanisms”.
Per our decision several weeks ago, we will hold special XDI TC telecons at 10AM PT Tuesday, Wednesday, Thursday, and Friday this week. The schedule Drummond proposes:
Tuesday: Review Variables section.
Wednesday: Review Core Relations section.
Thursday: Review ABNF section.
Friday: Review XDI Addressing section
Markus continued to talk about “message routing”, using this set of slides/diagrams:
https://www.oasis-open.org/committees/download.php/56309/Message%20Forwarding%20v2.pdf
Markus again discussed topics around “forwarding vs. proxying” and maintaining a “past” and “future” routing path in messages as they travel through an XDI network. E.g. in a scenario where an message is sent from Markus’ device -> Markus XDI endpoint -> Animesh’ XDI endpoint -> Animesh’ device, how much information is visible in the message at each hop? Christopher jokingly introduced the term “man-in-the-middle as a service”. Les noted that we should probably be talking about apps rather than devices having an identifier in the XDI network.
We noted some cryptographic challenges, e.g. if a message is sent to three of Animesh’ devices, do they each have to be encrypted separately (as it is in iMessage for example), and if so, is it necessary to maintain and query a list of such devices.
Drummond’s summary is that we need to define all the “primitives” of messaging (“here is how a peer sends a message to another peer”), and that then these primitives can be applied and profiles for various concrete use cases.
This is XDI Core Immersion week, so we will hold a special call at 10AM PT. Logistics:
Join from PC, Mac, iOS or Android: https://zoom.us/j/146396591
Or join by phone:
+1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
Meeting ID: 146 396 591
International numbers available: https://zoom.us/zoomconference?m=Q1SIPjUUAWsAtR_0Lmycrk3Ja5cqdVFx
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]