[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: XDI TC Unofficial Telecon Notes: Monday 2017-11-27
Following are the notes of the unofficial telecon of the XDI TC held on:
Date: Monday, 27 November 2017 USA
Time: 9:00AM - 10:00AM Pacific Time (16:00-17:00 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.
Drummond provide an update on the progress of the DID specification at the W3C Credentials Community Group, including a review of the DID Spec Hardening Proposal V3.
His main points were:
JSON-LD remains the "recommended" format for the DID Document, with the understanding that plain JSON developers with no RDF or LD background must also be able to work with the format. In addition, DID Documents can also be presented in different formats such as XDI or IPLD, which may have their own specific signing mechanisms.
Keys are defined by a single "type" field that encapsulates all information about the key, including algorithm, length, encoding, and usage. This reduces security risks and the potential for developer error that may typically occur if the key information is spread across different fields.
The format doesn't support multiple "endpoint" fields or multiple "keyref" fields per "service" block. But it is possible to have multiple "service" blocks of the same "type" and/or "path", but with different "endpoint" fields and/or "keyref" fields, in order to associate multiple endpoints and/or keyrefs with a given service.
The path and fragment parts of DID syntax are designed to be "web-compatible". A fragment directly following a DID is understood to identify a portion of the DID Document. A fragment following a DID and a path is understood to identity a portion of the service that is selected from the DID Document based on the given path.
Phil and Joseph agreed with these updates.
The increasing interest in blockchain-based self-sovereign identity (SSI) and how distributed SSI agents with DIDs can be used for both encrypted communications and decentralized key management. Drummond gav an update on the DKMS work that Evernym is performing for the U.S. Department of Homeland Security.
Markus asked where the private keys associated with the DID owner are typically stored. Drummond explained that the two DKMS options are "keys on the edge", i.e. on devices such as mobile phones or hardware tokens, or "keys in the cloud", i.e. hosted by services such as "agents" or "hubs" that act on behalf of the DID owner. It appears that depending on the use cases, both options (and additional variations) will be supported.
Drummond explained that Digital Bazaar is designing a "cloud wallet" that holds DID keys, and that users will have web browser plugins to access their wallet.
Evernym on the other hand is envisioning that:
The primary location of private keys will be wallets on the edge.
One important principle the DKMS design is following is "Never share private keys across wallets".
The role of cloud components will be to merely sync information such as "DID maps" across edge devices.
For adequate security, private keys must be stored using the "secure enclave" features of edge operating systems.
Evernym is currently working on a number of flows required in this architecture. This includes key recover, data portability, and others.
Drummond also reported that XDI or a similar technology is being considered to implement these key management scenarios, and that a "DKMS Technical Committee" may be formed at OASIS to pursue formal open standard specifications for DKMS.
Markus mentioned that some of his contributions to the Rebooting-the-Web-of-Trust workshops include XDI-based architectures for edge and cloud agents, e.g.:
Markus and Drummond both attended the Rebooting the Web of Trust conference in September in Boston. One of the highlights was an in-depth discussion of the object capabilities security model with Mark Miller, the world expert on the topic. Although we did not have time to go into it beyond a short discussion with Mark, we would very much like to explore XDI link contracts as capabilities, and see how much of the overall model that Mark has been advocating either has been or can be implemented by link contracts.
We did not have time to discuss this topic.
The next call will be the following week at the usual time (Monday 9AM PT). The link where agenda items can be posted for the next meeting is: https://docs.google.com/document/d/19oDl0lbb56Grehx2a5flZnhrgnua5l8cVvC_dJ8fTXk/edit?usp=sharing