Open newbreedofgeek opened 1 year ago
Because ERC725
is implementing an Ownable interface, there is one variable for the original owner called owner
(the one that deployed the identity contract via the identity factory in our case).
We then added another variable called additionalOwners
where we keep track of the added and removed additional owners.
Owners in this variable are treated the same way as the one in owner
.
This original owner can also be changed by calling the function transferOwnership
in the Ownable interface.
@0xpeho
The issue is if AddrA is the original owner which deployed contract, but this wallet was later breached/hacked.
Can AddrB, AddrC...AddN (additionalOwners
) be able to vote AddrA out or at least "quarantine him" so he can't participate anymore in adding claims or voting owners out etc?
Yes, one can implement something like this. Let's discuss.
As per our offline discussion today, here are some ideas for thought...
let's look at possibility of making the Owner
more like a Deployer
and removing logic based on Owner
. Also, if we do this we need to prevent transferOwnership and renounceOwnership and any other migration of the identity contract from the interface..
We then don't need additionalOwners
, this concept just becomes owners
We can also just push the Deployer
into owners
so they inherit the same "vote out" method in case a breach happens.
If the "owner" of identity gets breached (maybe "Addr A" was the owner and is now breached)...
So if removal is not possible, then we will need some way to "quarantine" him if we cannot remove "Addr A" altogether. Like a virus in a computer that CANNOT be removed but put into quarantine so it can't do anything