Status Identity Support
Status would use Identity to enhance user experience in Status Network and other DApps.
For Status having an Identity is an optional that upgrades from a simple key account to a contract account that provide additional methods.
Status Wallet would support making transactions for the Identity (by user held keys) in any dapp (even if they are unaware of Identity), could be displaying certain badges (claims), Account Tab would managing identities (editing keys, claims), could support user-to-user claims.
Abstract Identity and Claims
ERC725 is just one of many options of contract account interfaces Status might want to supports, maybe some users want to start using Gnosis/Consensys Multisig Wallet, or Gav Wood/Foundation Multisig, that have different features.
ERC735 is just one of many badges/certifications interface Status Wallet might want to support, maybe some users want to start using the Claim Registry contract and a simple key.
The Claim Registry obviously is a singleton instance that would be used by the Identity objects of this other type of claim system.
Therefore, making Status be able to support any type of Identity implementation, as needed.
ERC725 & ERC735 initial support
Status should start supporting only ERC725 and ERC735, but the architecture of its implementation should think about future porting multiple types of interfaces for multisig and claims.
One way of doing this is by Application implementing its own abstract class of Multisig and Wallet and having a more specific concrete classes for ERC725 and ERC735, initially used by default (as is the only supported).
If later we see demand for other types of Multisig and Claim interfaces, we can extend the client and add a selector or auto detect based on contract code analysis.
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.
Gas Relay Wallet Interface
When using Identity, and Identity is Gas Relay enabled, user would be able to sign a message instead of a transaction to make a call, and select what token to use in gas price. This would make the call cost funds held by Identity, making keys not needed to hold any funds.
Friends Recovery Wallet Interface
After creating a new Key in Status, user could request the recovery of an Identity. The Secret would be a hash of a bio-metric data, and as bio-metric sensor returns many different results, UI will hash against recovery secret hash, where when found it would be able to select user friends to sign the recovery approval.
Friends would receive a notification in Status, and would have to check with user to see if request is valid, and then authorize by pressing a button.