Web3 object privacy and dapps unique keys

[ricardo3]

Regarding ERCs of Signed Messages, is not exactly the case but more the keys you add to your identity.
I explained in the Identity topic, and will just quote it here…

@ricardo3

HD wallet key derivation for Identity keys

Status use HD wallets and we can derive a key for each dapp.
Currently including a key requires a transaction, however there might be some way of including a key off-chain and adding it on-chain by a signed message only when/if needed.
Users should be able to use Identity only if they want, a option to “disable/logout” and use directly the keys to interact should be an option.

After including any dapp name, as using Identity, would be nice to rotate the hash with status wallet + device number & identity as salt. Device Name -> Number can be saved encrypted by root hd wallet key in off-chain storage (swarm/ipfs/ server ) together with user global configs.

ERC725 Management Keys

We might have multiple managers, and Status could be added through a key created/imported in wallet.
We could use the status wallet & identity salted key “root” for MANAGEMENT_KEY , however if HD wallet is imported in other wallet than Status, it would need to request an Status Wallet to add that other wallet - or, this other wallet could be aware of status derivation key.

DApp ERC725 Keys for transactions

If needed for doing a transaction by Identity, this new key should be added to Identity as ACTION_KEY or user should be able to select a default/shared action key, then the call should be called through execute method - or if Dapp don’t requires an Identity, to use an key that contains ETH with an direct call.

DApps ERC725 Keys for off-chain

If needed for signing or reading messages, maybe it would be added as ENCRYPTION_KEY, but as Identity stores authorization to a hash of the Keys (not the keys itself), you need to pass your non hashed key to the network/interested nodes or to a server .
In this sense, if an user want to proof its Identity to a determined other user in Status Chat it could do so by providing a signed message coming from a key listed (hashed) in Identity as ENCRYPTION_KEY.
This can be useful, but I am not sure how, in some off-chain technologies like plasma, zero knowledgbe proofs or state channels, where the contracts can check for a Key in an identity refers with proof provided.

Keys for non ERC725

The class implementing the other standards should be able to derive the key as they need, being able to also specialize the keys for dapps, for off-chain and for management, but by default using all the a generic derivation method that assumes that one key per device for all dapps and management of identity itself.