Access control

Phase1

As a decentralized database, it is very different from a centralized counterpart, even if they seem to function similarly. For the centralized database, only a few authorized users control the access management of a centralized database, usually the employees of a data service provider, and the final authentication only needs to be executed in one gateway.
On the other hand, a decentralized DB can be accessed permissionless, and anyone can attempt to write any malformed data. The confirmation of data ownership and accessibility is more complicated.
Nowadays, our access control primarily concentrates on ensuring data ownership and usage transparency. The general idea of access control is similar to trusting a third party or delegate. Clarifying the relationship between DID identity and the data helps confirm data ownership. Dapp's cross-account programming logic is maintained in a smart contract running on DVM. The code is transparent and open to every user of the dapp.

Two scenes

The access control in our Phase1 development primarily concentrates on two scenes:
  1. 1.
    Ensuring the data's ownership of every user: the owner could access and query it anytime; the data owner could delete authorization at any time; users access the data in a method run_sql_by_owner
  2. 2.
    Ensuring cross-account convenience: the cross-account dapp logic could be implemented after the smart contract gets the permissions of multiple users. The code logic in the smart contract is on-chain in a very transparent way. User grants authorization to a delegate or a smart contract in a method createNsAndAddDelegate
The role and concept of access control are here;

Phase2

In phase 2, the next questions we should answer are how the user can safely trust a delegate or a third-party and how the delegate executes the read/write in a responsible way. Furthermore, we will release more access rules and granular permissions for the different dapp use cases. There are different methods to deal with varying differentiation scenarios, like data sharing, collaboration, teamwork, or other multi-user, data-driven dapp features.
For example, considering the UX experience and database performance, the user can select a more optimized mode to trust the delegate; The other scenes like email or patient medical data need more encryption in a high-level security demand.