1. Topics
  2. Personal Datastore Requirements

Personal Datastore Requirements

Adrian Gropper
 

I took up the challenge at the end of today's call and answered each of Daniel's checkboxes https://hackmd.io/qClYLUPkQ7uf0r3_4O7BUQ?view in terms of an EDV feature. 

  • Add support for DID Auth and encryption/capabilities based on the pub key refs in a DID Doc.

    • Allow Alice to purchase an EDV account using a DID instead of an email address and password as her identifier. Either way, Alice needs to send the EDV host a payment such as a credit card.

  • Multi-instance masterless operation, with active/active replication between instances.

    • Two EDVs can reach eventual consistency if they are connected, aware of each other’s service endpoint, and have a filter in place. 

  • The ability to differentially replicate subsets of the logical whole dataset across different instances.

    • Two EDVs can do filtered replication based on a scope schema.

  • Three modes for data: public plaintext data, shared encrypted data, private encrypted data.

    • An EDV document or database entry can be 

      • unencrypted

      • pointer can include the decryption key (hashlinks-style)

      • decryption key is passed out of band

  • Multi-writer ingest, with the ability for the owner of the datastore to authorize any entity to write that they choose.

    • EDV access authorization supports Alice-to-Bob use-cases where Alice and Bob are different DID controllers using different clients or user agents.

  • Ability to limit writes/reads by external entities. An example of this would be Alice, the datastore owner, being able to limit writes and reads of objects she specifies to Bob and others, in keeping with access and permissioning criteria she sets.

    • EDV access authorization supports arbitrarily fine-grained scopes. 

  • Ability to keep private objects out of public circulation.

    • All EDV access is protected by a policy enforcement point (don’t count on encryption alone to keep objects out of public circulation).

  • Support for both Last-Write-Wins complete replacement of objects and objects that can be seamlessly merged via conflict-free replicate data mechanisms.

    • EDVs must support a notification mechanism that allows p2p replication conflicts to be adjudicated by a user or the user’s agent.

  • Implementations that can run in Web platform, native/mobile app, and remote server environments.

    • EDV accounts are substitutable across multi-tenant cloud hosts and native, occasionally connected mobile device hosts. 

    • EDV accounts do not presume or benefit from access to a HSM or IntelSGX infrastructure.

  • The ability for authorized parties to listen for new changes (via feed, pub/sub, etc.) on public objects and encrypted objects (individually or sets) they are authorized to have.

    • Authorized parties (Bob) that own their own EDV account somewhere can use the filtered replication feature of EDVs as a way to listen for changes to Alice’ EDV.

  • An API that provides inferential queries on semantic data can be directly addressed and fetched via type or a set of well-known metadata values (e.g. an HTTP GET that “Gives me all of Alice’s public https://schema.org/SocialMediaPosting objects”).

    • An authorized user can search against an EDV index.


      - Adrian
1 - 1 of 1