Created On: 9/11/2018
Created By: Rob Andrews
Subject: Storing Business Objects and providing a Front End Business System inside BiblePay
Goals: User permissions, ACID compliance, GDPR compliance, Organization permissions, Symmetric encryption, proof-of-business object storage, garbage collection, RWAD permissions, UI lists, chain bloat.
A system is being designed to provide a proof-of-concept for BiblePay to function as a front-end-business system.
This page describes the technical mechanics asserted to accomplish the Goal.
First let us start with storing and retrieving a simple business object that is not encrypted: a user contact record. The contact record contains: The users public key, the users name, company name, receiving address, user type (church, user, vendor), and testimony URL.
A business object is stored either encrypted or unencrypted in a file-system data file. If unencrypted, the entire world may see the data. If encrypted, only users with the symmetric organization private key may see the record. Data is stored in JSON so it may contain the serialized field names and values. The actual data composition determines the SHA256 hash of the record. The filename is the SHA256 hash of the record. The business object is stored in IPFS.
Mechanics of Saving an Unencrypted Business Object:
A business-object-storage fee is charged to the end user (this is currently .0001 bbp per K, which is donated to the foundation). The transaction record will contain the business object primary key (this is the object type (CONTACT) plus the object owners public scriptpubkey and the IPFShash (the sha256 hash of the object)). When a record is instantiated with the same primary key as an existing record, if the scriptpubkey owns the record, the record overwrites the old record. In reality, this means a user may EDIT their business object and save the updates. Since the data is stored off-chain, the metadata in the chain is updated, and the actual business object will now contain a new hash and be stored under new hash in IPFS.
GDPR Compliance: Since GDPR regulations require the user to be able to hide or delete a record, BiblePay honors the wishes of the user to be compliant. When we receive a DELETE request, we empty the contents of the business object (resulting in a new hash), we save the record (as empty) with a new hash pointer. Subsequently, during garbage-collection, old records marked for deletion are physically deleted in IPFS. Therefore, a user may store public information in business objects in biblepay, with the ability to DELETE those records later.
Plan for Permissions: To allow BiblePay to be a useful front-end-system, it will be required to allow the creation of new organizations and user permissions within organizations.
When a user creates an org, a new business object is created with One organization owner (the pubkey of the creator). Organization names must be unique. Only the creator may edit the permissions list for users within the org. The org will contain a symetric keypair: One key for Encrypting business objects, and one Private key used for decrypting business objects. The owner of the org may change the keypair for the organization at any time (this is performed by BiblePay by checking the authenticity of the owners signature of the Org. If the owner check passes, BiblePay will generate a new Org symettric key. BiblePay will not store the Private key in chain. This allows the Org owner to revoke Read access to every member, by changing the keypair. The Org owner may assign: Read, Add, Edit and Delete permissions to Members of the org. Effectively, everyone in the world without Read permission that uses Biblepay will have NO ability to download or see an org-encrypted business object or view it. An Organization member (one whose public key has been added to the org) WILL have the ability to See a business object.
Mechanics of BiblePay Business Object Security for Viewing a document: Let us assume Catalina, who packages cat food, creates an organization called Catalina, and she has three biblepay users she invites to her org. User A: Snoop, User B: Hissy, and User C: Gordon. These three users public keys are added to the organization record with RAED abilities, except Hissy, who only gets R (as her job function does not allow Editing or Deletion of Catalina objects). During 2019, business is very smooth, and everyone has the ability to read Catalina's documents. Let us assume that Catalina creates a business object called inventory. Each time a user saves an inventory record, it will be encrypted with each member of Catalinas public org's keys so that three hashes have been created. Each individual user who has access to Catalina will download an encrypted business object record and decrypt the record with their private symmetric key. At the point in time where Catalina revokes access to Hissy, as she left the company, her public key is removed from the BiblePay organization. During the next Edit of an inventory document, Hissy will lose her ability to See any updates (as changes are stored with new hashes). The rest of the world (IE IPFS eavesdroppers) will not be able to decrypt any business object used by Catalina. (In the future we may write a forceful-update to trigger the eviction of Hissy immediately, by scanning the list of business objects and updating them in IPFS).