XDI TC Notes
Following are the notes of the unofficial telecon of the XDI TC held on:
Date: Monday, 3 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
Markus Sabadello
Drummond Reed
Joseph Boyle
Les Chasen
Phil Windley
Christopher Allen
REGRETS
Peter Davis
JIRA Task list for XDI Core 1.0
Drummond now has his new JIRA login and is ready to add JIRA entries for each of the major tasks remaining for XDI Core 1.0 to go to Committee Draft vote. However this weekend he discovered that his new JIRA account was not yet authorized for the XDI TC JIRA project. So he wasn’t able to add any of the tasks yet.
That authorization happened this morning, however Drummond still doesn’t have permission to add new JIRA issues yet. As soon as Peter can assign this permission, Drummond will begin to adding the new tasks.
Drummond also said that he’s trying to arrange to have an entire week (the last week of August) to dedicate to finishing all of his sections for XDI Core 1.0. This would solve the problem of “drip feeding” the remaining sections of the spec and let us go into September with a full draft against which we can just work issues to complete it for a Committee Draft vote by the end of September.
Phil strongly endorsed this approach and again emphasized the importance of completing specs at least to Committee Draft level so that implementers can be confident they are stable.
Messaging Walkthrough and XDI Channels
Markus did an early demo of an XDI-enabled mobile app called “XDI Ninja!”. Screenshots:
Step-by-step explanation of the walkthrough:
XDI Ninja! app starts and is not connected (has no link contract with a personal cloud).
User types cloud name =markus, XDI Ninja! discovers cloud number and URI of the authorization service.
Browser app is launched with an XDI connection request sent to the authorization service. User authenticates to personal cloud.
Authorization service displays the XDI connection request. User approves it.
Browser app redirects back to XDI Ninja! app, which receives the new link contract that is the result of the XDI connection request.
XDI Ninja! app is now connected.
XDI Ninja! app can interact with personal cloud, e.g. read profile using $get request.
Using a “Cloud Manager” tool, user can view and delete the XDI Ninja! app link contract.
In Markus’ demo, one question that came up is how to explain the permissions that are being requested for a new connection. In the case of Markus’ demo, this was just permissioning an app to access a person’s XDI graph within a personal cloud.
Phil explained that this is perhaps the most significant UX problem related to XDI connections and link contracts. Phil did some work last year on a simple policy declaration language that could turn policy requirements into valid XDI link contract policy statements. See:
https://github.com/kynetx/PolicyLanguage
https://github.com/projectdanube/xdi2-pixel
Phil speculated that it could work in the opposite direction too, i.e., that there could be a standardized rendering of link contract policies into UX elements so that the user can provide informed consent.
Markus also raised the question of whether each app instance needs a unique XDI number. There was agreement that every app instance should have a unique XDI number, but that it would be optimal that the connection request also include an XDI type statement about the relationship of the app instance to the app, so that an XDI endpoint can provide guidance to a user as to whether they are installing a new instance of an existing app or a different app.
Christopher also pointed out that connecting an XDI client agent app to a XDI endpoint (personal or business cloud) is only the first step in creating a full end-to-end encrypted messaging channel. Drummond and Markus agreed. Markus explained that the purpose of the work he is concentrating on right now is to implement every leg of his overall demo scenario so that all the use cases and requirements are covered by the necessary specs, which besides Core, include Messaging, Bindings, Connections, and Policy (and in certain cases Discovery).
Switching to Zoom for Meetings
On behalf of Respect Network, Drummond volunteered that the TC meetings could start using Zoom for webconferencing, since it is easier to use, higher definition, and more flexible than Webex. (For example, today Markus was able to show a live screen demo from his Android phone.) Provided Peter agrees, Markus will set up a Zoom Room to start using for future meetings.
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