[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: XDI TC Notes Unofficial Telecon Friday 2015-09-21
Following are the notes of the unofficial telecon of the XDI TC held on:
Date: Monday, 21 September 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
Les Chasen
Markus Sabadello
Christopher Allen
Joseph Boyle
Phil Windley
Drummond Reed
Drummond has uploaded the latest draft:
https://www.oasis-open.org/committees/document.php?document_id=56520&wg_abbrev=xdi
The new section is the Namespace Architecture section of XDI Addressing.
The main sections remaining for Drummond to draft are:
Internationalization
Canonicalization
IRIs
XDI Schemes
Versioning
We reviewed Drummond’s new “Namespace Architecture” section. We realized that the matrix at the beginning of the section is a summary and introduction to the following sections. Joseph suggested that the head rows could show the appropriate syntax characters (i.e. ! for Immutable and ~ for Relative).
On line 1986, Markus felt that the meaning of “the default form of XDI identifier” may not be clear enough, however Markus also doesn’t have a suggestion how to improve this text.
We discussed the relationship between the Absolute/Relative and the Rooted/Nested sections and noted that a rooted identifier is always an absolute identifier. Joseph suggested there should be an example of an address that has two consecutive relative arcs. We wondered if that would be considered an absolute or relative address. Example:
//+group
+group//+~subgroup
+group+~subgroup//=~joseph
common
root +group +~subgroup =~joseph
( )---------( )---------( )---------( )
Markus said he thinks this is still an absolute (and rooted) address, since it starts with an absolute identifier (+group).
We then talked about the Public/Private section and realized this section was somewhat different from the previous ones, since the distinction between public and private doesn’t seem to be a property inherent to the identifier itself, but rather a property of what you can discover about it and do with it.
Joseph also noted that the same identifier could have a public or private character depending on the context it is in and the discovery process that results from it. For example =markus in the context +respect=markus may be more or less private than =markus in the context +xdi.org=markus, since an XDI discovery agent may be able to discover different data about =markus. This confirmed our feeling that what makes an identifier “public” or “private” is not something inherent to the identifier itself. Despite this, we still feel comfortable about this section of the spec and do not propose to change it.
Joseph asked if the discovery process should be explained in this section, since it impacts public/private characteristics of identifiers. Markus responded that the discovery process is already covered in the earlier “Peer Roots and XDI Discovery” section.
Markus said he thinks the following text on line 2097 is slightly incorrect:
“a public link contract, i.e. a link contract that does not require the requesting authority to have permission to access the subgraph.”
Markus proposes to change it at follows:
“a public link contract, i.e. a link contract that grants any requesting authority permission to access the subgraph, without authentication.”
In preparing to write the Identifier Canonicalization section of XDI Namespaces, Drummond proposes that the TC adopt the following rules for “extreme canonicalization” XDI identifiers because this will ensure the fewest false positives and false negatives in identifier matching:
Only allow digits, lowercase letters, and three symbol characters (dot, dash, and underscore) in native XDI identifiers in the ASCII range. Uppercase characters MUST be escape encoded (thereby preserving uppercase letter matching for systems that need it).
Characters above the ASCII range MUST apply the most stringent form of Unicode normalization (as specified by Joseph).
IRIs used within XDI addresses (in parentheses) MUST be normalized according to their scheme.
Joseph’s feedback was that usually it is best to do canonicalization in clients (lower levels of a system), and that servers don’t necessarily have to enforce it. Les said maybe instead of defining a canonicalization process, it might be best to just say XDI names are case insensitive.
Christopher asked about the state-of-the-art in domain names. Les explained that DNS is ASCII-only, and that in order to register international domain names there is a process to encode them to ASCII (Punycode). Les said that unlike domain names, XDI names have full UTF-8 support.
Markus asked where the canonicalization logic is needed and when it is enforced. Drummond said this should be applied before identifiers go into a graph, and then applied again (the reversed process) when identifiers are taken out of the graph. Joseph also wondered which parts of a system should enforce this. Drummond’s feeling is that it should be enforced any time identifiers are introduced into the system.
Markus wondered if the following XDI names identify the same node in an XDI graph:
=markus
=m&0061rkus
Joseph had a few suggestions about the details of the above proposed steps (e.g. maybe it is not a good idea to encode upper-case characters). Joseph and Drummond agreed to discuss this further on the list.
So far, we have been using XDI variables to act as placeholders for (one or more) XDI context nodes. Markus has come across a use case where we may want to also use XDI variables for literal nodes (e.g. in link contract instantiation). The challenge here is that XDI variables are themselves context nodes, not literal nodes. Markus will explain further and ask for feedback on a proposed solution.
Markus gave an example of a (simplified) link contract template, a connection request, and a link contract instance. This illustrates the use of variables as placeholders for context nodes::
#test1{$do}/$get/{$get}
(#test1{$do}$if$and/$true){{$msg}}<$sig><$valid>/&/true
=bob[$msg]!:uuid:1234$do/$connect/#test1{$do}
=bob[$msg]!:uuid:1234$do$connect{$get}/$is/=alice<#email>
(=alice/=bob)#test1$do/$get/=alice<#email>
(=alice/=bob)(#test1$do$if$and/$true){$msg}<$sig><$valid>/&/true
Markus then gave a second example where a variable is used as a placeholder for a literal node (in this case, a message digest as part of a link contract policy):
#test1{$do}/$get/{$get}
(#test1{$do}$if$and/$true){{$msg}}<$digest>/{&}/{<$digest>}
=bob[$msg]!:uuid:1234$do/$connect/#test1{$do}
=bob[$msg]!:uuid:1234$do$connect{$get}/$is/=alice<#email>
=bob[$msg]!:uuid:1234$do$connect{<$digest>}/&/"xxxxxxx"
(=alice/=bob)#test1$do/$get/=alice<#email>
(=alice/=bob)(#test1$do$if$and/$true){$msg}<$digest>/&/"xxxxxxx"
There was consensus on the call that the use of a {&} relational arc seems to be a good solution for a variable as a placeholder of a literal node.
Markus has finished his “change of address walkthrough” and is now working on completing the original “messaging walkthrough”. See:
https://wiki.oasis-open.org/xdi/MessagingWalkthrough
https://wiki.oasis-open.org/xdi/ChangeOfAddressWalkthrough
Markus gave an update that the “Change Of Address” walkthrough was complete, and that the “Messaging” walkthrough was almost complete. Markus explained that an interesting aspect of the walkthrough is the “invitation”, i.e. =romeo is inviting =julia to send a connection request back to =romeo. This is useful for establishing a bidirectional connection where both parties have link contracts for each other. To enable this, a link contract in =romeo’s graph can authorize a single very specific message from =julia, using an XDI policy based on the hash value of that specific message.
We then had a brief discussion about the expiration of link contracts. Some link contracts are designed to be used only once (i.e. to only authorize a single message). Other link contracts are needed only for the duration of a single session, WebSocket connection, etc. Drummond is in favor of defining the necessary XDI constructs for various link contract expiration scenarios. Markus said maybe the use of a link contract should trigger an “action” that could use XDI messaging functionality (similar to a stored procedure in a relational database), although this approach may be too complex and/or vulnerable to attacks.
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]