Mingela
commented
1 year ago I've thought of an additional idea (which is just a potential improvement for the future, shouldn't be definitely considered within the issue) to prevent unauthorized data access by a node owner. The permission mentioned in the example might be treated as a sort of "encryption". Given that, will it make sense to allow a data owner specifying the encryption public key, which is used to encrypt the data related to the user (either on client or node side)? With that anyone can retrieve the data but only ones who have the private key to decrypt the data could read the actual content. The data owner could be also allowed to reencrypt the data using new keypair to 'reset' access. Though in that case some proof of data unchangeability might be required (referring to the medical records example, I doubt the user should be able to rewrite that in more regards than allowed).
Ofc there are cons (or at least gaps) in this approach, e.g. it's still possible to get a historical state content once an outdated keypair is acquired.
Again, that is not a technical solution proposal, just a quick glance for a direction for a feature I find really attractive for the example from the description (privileged data).
Erigara
Feature request
We add a new instruction
Instruction::RetrieveData(QueryBox, ...)the permissions for which are tracked separately from the regular query execution. Its execution can have side-effects defined by the executor, and the event system should be made aware of the events that result when specific information is retrieved.Consider implications for #3527.
Motivation
Some data stored even in public blockchains, can be privileged. As such, knowing who retrieved the data, recording the time of retrieval, and controlling the conditions of the retrieval attempts is is an important use case that Iroha should support.
The idea with this implementation is that the blockchain operator disallows all queries for all accounts by default. Privileged information is retrieved with the given instruction, but the success/failure of a data retrieval instruction is subject to arbitrarily complex logic on the executor side.
Example
Blockchain contains a collection of people's medical records. Both patients and their doctors are accounts on the blockchain. The patient can mint a token to the M.D. of their choosing and using that token the M.D. can retrieve data of that patient once, which burns that token. If further updates are needed, the patient mints the token again. But if the doctor is no longer the medical professional handling the patient, and doesn't have the token data retrieval is no longer possible.
If this were handled through queries, the permission should have been granted, and revoked based off of complex logic that would not necessarily correspond to anything meaningful. A lot of automation is impossible, because the automatic burning of the token has to be done elsewhere given the restrictions placed by #3717.
Who can help?
@DCNick3 @appetrosyan @arjentix @mversic @Erigara