Last edited · 5 revisions   


Secure Data Storage WG Agenda - Thu Jan 14th, 2021

Current Spec



  1. IPR Reminder
  2. Introductions and Re-Introductions
  3. Replication (Use Cases and Threat Models) 
  4. Issue Review


Intro's / Re-intro's and announcements

  • Zokama - Introduced himself
  • Kaylia - New job now the ecosystem director for the linux foundation for public health

Revisited the naming question

- Group chartered as the Secure Data Storage WG and as per the vote in the WG we have renamed the current work item to Confidential Storage, there are appears to be some confusion about this relationship it was clarified during the call.

- Adrian proposed for the spec to be renamed to EDV (encrypted data vaults) and to remove the hubs section from the current spec because there is a legal distinction between EDV and hubs.

- Chris in reference to Adrians argument re-raised the point about hubs having access to un-encrypted data, Dmitri asked Chris to create an issue to capture this if it does not already exist.


- Dmitri explained how we got to this topic: authorization model -> how do we refer to resources (identifiers) -> how do we replicate these resources between provider instances.

- The conversation around replication was framed in the context of the use cases document

- Adrian G gave some examples about how he would like replication to occur, citing an example use case involving drop box and a password manager

- Chris W asked for clarification on the sharing data usecase, "is that sharing everything or only a subset?". Dmitri clarified that the current usecase is very general and the granularity of sharing is dependent on the authz model.

- Adrian asked whether backup is related to replication and whether it exists at just the hub level. Orie said he believes replication is at the EDV (CS) level.

- Dave asked whether replication is invisible to the client or co-ordinated by the client? I.e is replication achieved by the client co-ordinating it, or is it something two EDV servers do together without the client.

- Dave proposed "client-controlled replication"would be a potential feature for the spec, "server-controlled replication" would not be.

- Daniel B proposed what properties he would like to see from replication which is that Alice can have multiple instances of her hub that when a change is sent to one, it is broadcasted to all meaning if one provider fails she has appropriate redundancy.

- Dmitri clarified what he called a difference between client visible vs client controlled replication citing Orie's example of couch db, which is replication that is client visible but server controlled, where as another option is for replication to be client visible and client controlled.

- Orie made the point that not all replicas may be equal citing that some replicates due to storage requirements or bandwidth might not be able to hold an entire dataset.

- Dave clarified further about client controlled replication, asking is it the client setting a setting on the EDV or is it actually performing the copy. He also pointed out that when the server instances are responsible for syncing differential replication (partial replication) would be difficult, as the server has no access to the plain text data.

- Orie pointed out that encrypted indexes could offer a solution to achieve differential replication (partial replication) between two server instances. Dave agreed that we could explore a solution based on this. Chris agreed but was not convinced about dynamic filtered based replication.


  • Dmitri¬†Zagidulin
  • Tobias Looker
  • Kaylia Young
  • Daniel Buckner
  • Adrian Gropper
  • Chris Were
  • Dave Longely
  • Derek Trider
  • Juan Caballero
  • Leah
  • Michael Shea
  • Robbie Jones
  • Sze (Z) Wong
  • Troy Ronda
  • Zokama
  • Jim StClair
  • Kristina Yasuda

Recording (Zoom)

Transcript (