XDI TC
Notes
Following are the notes of the unofficial telecon of the XDI TC held on:
Date: Monday, 13 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.
ATTENDING
Peter Davis
Markus Sabadello
Drummond Reed
Dan Blum
Les Chasen
Joseph Boyle
REGRETS
Phil Windley
Procedural Notes
First, Drummond noted that Respect Network has now joined OASIS, and Drummond has moved his affiliation from XDI.org to Respect Network. Les C
hasen
has also rejoined the TC as a representative of Respect Network.
Second, Joseph has rejoined the TC has a representative of XDI.org.
Thirdly, based on feedback from our TC Admin Chet Ensign, we have clarified both on the TC home page and in these notes (see above) the procedure under which the TC operates unofficial meetings.
Drummond and Markus explained that we can always hold an official meeting by providing 15 days notice to all TC members. Otherwise, all official TC decisions must be made by electronic ballot using the Kavi voting system.
The rules for voting membership in the TC are as follows:
Any TC Member qualifies to become a Voting Member (if they wish) 60 days after joining the TC as a Member.
All Voting Members MUST vote in 2 out of 3 consecutive ballots or they lose their voting rights and must wait another 60 days.
Lastly, Chet clarified that OASIS does not allow non-members to participate in OASIS-affiliated TC meetings (official or unofficial)—an “invited expert” must be an OASIS member.
Recap on the Taxonomy of Instances
Since not all TC members were able to attend the last meeting (two weeks ago), this agenda item is to quickly recap the consensus reached on the last call that all @, *, =, and + namespaces represent instances (and all $ and # identifiers representing classes). This means all @, *, =, and + nodes that are immediate child nodes of a collection represent members of the collection.
This means, for example, a [#friend]collection can now explicitly include people:
=drummond[#friend]=markus
=drummond[#friend]=les.chasen
=drummond[#friend]=windley
And on the business side, a [#partner]collection can now explicitly include organizations:
+example-company[#partner]+example-company-2
+example-company[#partner]+example-company-3
+example-company[#partner]+example-company-4
In short, a collection can contain any set of instances of @, *, =, or + identifiers.
#CONSENSUS
#ACTION ITEM: Drummond and Joseph to update the next XDI Core Working Draft accordingly.
Recap on + Namespace Definition Refinement
Again, because not all TC members were able to attend the last meeting, this agenda item is to quickly recap the conclusion reached on the last call that we narrow the definition of the + namespace to apply o
nly to
groups of natural persons—whether or not that group is explicitly a separate legal entity. This means the + space does not apply to any other type of entity. Product names and any other type of entity identifier that is not: a) a natural person, or b) an entity representing a group of natural persons are in the * space.
#CONSENSUS
#ACTION ITEM: Drummond and Joseph to update the next XDI Core Working Draft accordingly.
Discovering XDI Names from XDI Numbers
Markus brought up the use case that an app frequently needs to discover a preferred XDI name (human-friendly
identifier) from an XDI number (machine-friendly identifier). This use case is common in account maintenance and personalization.
Peter said this is a classic “reverse lookup” or “reverse mapping” function, which is common in DNS. Drummond agreed and noted that this type of mapping from a human-friendly identifier to a machine-friendly identifier (and vice versa) has also evolved in email. For example, the standard format used in the address line of Gmail message is:
Drummond Reed <drummond@respectnetwork.com>
This use case of discovering the human-friendly identifier associated with the machine-friendly identifier has a number of special considerations:
The human-friendly identifier is not an attribute of the entity being identified, but a reference to it.
There may be multiple such references, so you may need to know the preferred reference (or an ordered set).
The preferred reference (or preferred ordered set) may vary by the context of a specific relationship.
Because it is an active reference, it may change over time, and an old reference may become invalid).
Markus mentioned a page on the XDI2 wiki describing the process of discovering cloud names:
https://github.com/projectdanube/xdi2/wiki/Discovering-cloud-names
We started with some of the examples from that page that suggest solutions to the problem.
=!:uuid:x-1/$is$ref/=alice
=!:uuid:x-1/$is$ref/=alice.example
(=!:uuid:x-1/$public)($do/$get)=!:uuid:x-1/$is$ref/{}
Say Bob is =!:uuid:x-2
Bob sends the following XDI message to request the list of Alice’s cloud names:
(=!:uuid:x-2[$msg]*!:uuid:x-3$do/$get)=!:uuid:x-1/$is$ref/{}
An alternate policy would allow discovery of only a particular clou
d name
mapping:
(=!:uuid:x-1/=!:uuid:x-2)($do/$get)=!:uuid:x-1/$is$ref/=alice
This would solve the problem of contextual control of who can see this mapping.
An associated question is how Bob decides to identify Alice, for example in Bob’s own address book. More generally, the requirement is: how can Bob control the human-friendly identifier he uses for Alice on a per-context basis.
Drummond proposed that the solution use inner graphs as follows (Bob is =!:uuid:x-2 and Alice is =!:uuid:x-1).
(=!:uuid:x-2/=!:uuid:x-1)=!:uuid:x-1/$is$ref/=alice
(=!:uuid:x-2/#home=!:uuid:x-1)=!:uuid:x-1/$is$ref/=babs
(=!:uuid:x-2/#work=!:uuid:x-1)=!:uuid:x-1/$is$ref/=alice.example
The question of ordering relations arose. Drummond suggested that inverse references could be ordered by adding an ordering context, e.g.:
=!:uuid:x-1/$is$ref@0/=alice
=!:uuid:x-1/$is$ref@1/=alice.example
=!:uuid:x-1/$is$ref@2/=babs
Markus mentioned that we have discussed ordering of relations before, in the context of message operations, but did not recall immediately how we proposed to do ti.
Drummond pointed out another “simple solution”, which is to record the human-friendly identifier as an well-known attribute of the entity (by using existing XDI dictionary vocabulary). For example, XDI discovery and dictionary syntax could be used:
=!:uuid:x-1<$xdi><$label>/&/”=alice”
The advantage of the attribute approach is that is provides all the benefits of attributes, i.e., context, collections, priority, etc.
=!:uuid:x-1<$xdi><$label>/&/”=alice”
=!:uuid:x-1<#home><$xdi><$label>/&/”=babs”
=!:uuid:x-1<#work><$xdi><$label>/&/”=alice.example”
Markus noted that something feels strange about putting an XDI address into a literal. Drummo
nd
agreed that it feels “unpure”—a reference should still be treated as a reference.
Markus suggested that, using reification, the original $is$ref statements can be express as a context, which can then have its own attributes:
(=!:uuid:x-1/$is$ref)=alice<#preferred>/&/true
(=!:uuid:x-1/$is$ref)=alice.example<#preferred>/&/false
Drummond agreed that this approach has promise, but he didn’t see yet how it meet all the use cases. However we were out of time, so we agreed to continue to think about it and put it on the agenda for the next meeting.
NEXT CALL
The next call is next week at the usual time (Monday 10AM PT).