...
Currently custom permissions are not supported in the SDK. As a result, if an account owner was to modify the permissions and then import the private key to a wallet, chances are that wallet would not be able to interact with the FIO Chain properly.
...
Implementation
Modify SDK to:
Properly initialize account from loaded private key. Currently public key is hashed to account and that account is used as actor
Fetch permissions from chain using get_account
Use the returned permissions to properly determine what actor, permission, and signing key should be used to process transaction.
Allow the developer to specify separately:
The target account - will be used as the account which executes the action and will be inserted into actor field inside specific action call (data field) and authorization → actor of call
The target permission - will be used as the account which executes the action and will be inserted into authorization → permission of call
The signing key - will be used to specify which user’s private key needs to sign the call
...
The primary difficulty with implementing this change, would be the coordination required to have integrators start using a different call to fetch the encryption call vs. the sending key.
Recommendation
Create a new FIP which will propose implement:
Addition of new field (or FIP-15 coding standard): encryption key to each account
Addition of new action (if FIP-15 coding standard not used) to modify encryption key
Addition of new getter to return encryption key (if FIP-15 coding standard not used) for a FIO Address
Migration process and backwards compatibility process
...
FIO Chain does not support a EOSIO transfer action, which takes account name as payee, and in turn requires the use of trnsfiopubky action, which requires a FIO Public Key. If one wanted to send FIO Tokens to a specific account, there is currently no easy way to get the FIO Public Key which hashes down to the account name. The key could be fetched from fio.address->accountmap table, but it requires complex table query logic. A more user friendly approach would be to create a custom getter which returns FIO Public Key for supplied account name, if one exists on chain. An alternative could be to support tokens being sent to an account.
Recommendation
Create a new FIP which will propose and implement:
Addition of new getter to return FIO Public Key for an account name
...
"We need the ability to create an account with a separate owner and active key. When creating accounts, we create the owner key and offer the backup sheet to safely store it - and then establish an active key locally on the device. The UX would break if we then had to create subsequent transactions to alter the permissions into this scheme and would also require the user paying fees."
...
Implementation
Create a new FIP which will propose and implement:
Addition of new action (or enabling of existing newaccount action) to create an account with custom permissions. The action would carry a new fee.
Lift limit on number of public keys allowed in custom permissions
...
"We need multiple active keys in our current configuration. Our account recovery process revolves around two options during recovery: first the ability to remove all active keys and set a new one (establish a new sole device), and the second being to add a new active key (which allows the addition of a new device)."
...
Implementation
Create a new FIP which will propose and implement:
Removal of the restriction which only allows one FIO Public Key in updateauth
...
This enhancement would extend the FIO Chain permission scheme to enable granting of permissions in those cases.
Recommendation
Explore options to best achieve this and create a new FIP which will propose and implement the solution
Options contemplated:
Option 1: Add specific calls to allow domain owner to set address registration permissions on specific domain
Option 2: Create new FIO-specific permission scheme which would allow another account to execute FIO specific actions without customizing permissions on the call and while still acting as thei own account and pay their own fees. In other words more generic Option 1.
Option 3: Current EOSIO permissions hack to allow the owner of a Domain to specify permission using updateauth and have regaddress action inspect that permission when someone is trying to register a domain. For example:
Account A owns Domain D
Account A wants to let Account B register (and pay for) FIO Address on Domain D
Account A executes updateauth with
permission: readdress-DomainD
actor: AccountB
Account B executes regaddress on DomainD (using its own standard permissions) and regaddress checks standard EOSIO permissions to see if above entry is present for Domain D and allows the registration even though domain is private