The trust here is established by group-consensus. We trust the validity of data by the virtue of it being accepted and hence stored by the Data-Managers (vaults). The way mutation flow is currently routed ensures this. An app can mutate data on the behalf of the owner and the app would not have owner's secret-sign-key to sign the data. Instead what we now have is owner/Authenticator going to its MaidManagers and telling them that if a mutation-request comes from app-pub-sigin-key then allow that mutation (except transfer of ownership request, which MaidManagers ensure only the account-holder (the owner) can do).
Now when app routes its request via the owner's MaidManager, the MaidManagers check if the app-pub-sign-key (from the incoming msg) is listed with them. The signature verification would have been done by routing before handing over the msg to vaults. These two combined ensure only the valid apps can have their mutation requests forwarded to data-managers.
Once it reaches the data-managers, who enforce that the request is coming from a group authority of MaidManagers, they use the
requester field which would contain the app-pub-sign-key (already validated by Maid-Managers) to verify if this requester (the app) has appropriate permissions to mutate the data.
There is explanation here too if it helps.
Change of ownership is still possible - infact there is already an rpc (request msg) corresponding to it. Currently the maid-managers enforce that only the owner can do it and the data-managers enforce that the group-authority forwarding the request is the maid-manager of the
requester field. These two combined ensure only the owner is allowed to transfer ownership.
We will further think whether to lift this restriction in certain scenarios like transfer of ownership is also allowed by someone else, say B, (who does not own the data) if the transfership request was signed by the owner. We might put a restriction that B is allowed this only if B himself is the new owner. But this is not being discussed for the current iteration and may or may not land in future.
Previously if A transferred ownership to B then A would keep himself in the prev-owners list and B in the owners field. After the transfer, any update of data by B would blank out the previous-owners field (the act of populating previous-owner-field indicated ownership transfer). Thus there was no permanent record of ownership transfers previously too - only till B did not update the data (or transfer it again). Also this however did not indicate that B accepted it - A could transfer to any B. Only if B updated the data and hence its signature present in the signatures field (and this act would blank out prev-owners-field) would mean that B truly accepts the ownership/owns it.