Current implementation
Whenever a service needs tokens to be transferred it calls the TokenHandler telling it to transfer an arbitrary amount from the source (from) to the recipient (to).
Target implementation
Phase 1
The TokenHandler no longer accepts amount-from-to requests, but instead a TokenTransfer object is introduced. A TokenTransfer is a object has more or less then same information (an id and an array of (from, to, amount, token)s), but the TokenTransferis no longer directly passed to theTokenHandler. Instead the TokenHandler is aware of the InstanceandTokenTransfers are stored in the instance instead. The TokenHandler now only accepts a transferid` as an argument to execute a token transfer.
When a service needs to execute a token transfer is first creates the TokenTransfer object and stores it in the InstanceStore. Then to execute the transfer, the service initiates the transfer by providing the id to the TokenHandler. The TokenHandler will then look up the transfer instructions in the InstanceStore and execute the transaction(s).
This implementation removes the possibility of an attacker executing an arbitrary token transfer (think open allowance to the TokenHandler) by calling the TokenHandler with a very large amount. Only prepared TokenTransfers can be executed.
And furthermore, the storage of the TokenTransfer allows the outside world to inspect a pending transfer before its being executed (assuming the product is implemented in a way that, e.g. policy creation and transfer of the tokens do no happen in a single transactions).
Security considerations
TODO: This section probably needs some more thoughts to ensure it cannot be maliciously used to execute arbitrary token transfers.
Its important that TokenHandlers do not blindly execute TokenTransfers, but ensure that only the TokenHandlers of the component that created it can execute it. So it's necessary to also store which TokenHandler is allowed to execute a transfer described by the TokenTransfer object. Also its required that the insertion of TokenTransfers into the InstanceStore is secure and no unauthorized entity can just do that (the address of the authorized TokenHandler needs to be double checked during insertion to ensure if from the currently active component).
Phase 2
This concept can be taken a step further by introducing signed TokenTransfers. The user can now inspect the pending TokenTransfer before its executed and sign it. The product would then be required to allow the signature as an attribute to the transfer call. The TokenHandler can now verify this signature and only execute the TokenTransfer if the signature matches.
A quick doodle of the concept - probably not 100% correct (to be replaced)

Current implementation
Whenever a service needs tokens to be transferred it calls the
TokenHandlertelling it to transfer an arbitraryamountfrom the source (from) to the recipient (to).Target implementation
Phase 1
The
TokenHandlerno longer acceptsamount-from-torequests, but instead aTokenTransferobject is introduced. ATokenTransferis a object has more or less then same information (an idand an array of (from,to,amount,token)s), but theTokenTransferis no longer directly passed to theTokenHandler. Instead the TokenHandler is aware of theInstanceandTokenTransfers are stored in the instance instead. TheTokenHandlernow only accepts a transferid` as an argument to execute a token transfer.When a service needs to execute a token transfer is first creates the
TokenTransferobject and stores it in theInstanceStore. Then to execute the transfer, the service initiates the transfer by providing theidto theTokenHandler. TheTokenHandlerwill then look up the transfer instructions in theInstanceStoreand execute the transaction(s).This implementation removes the possibility of an attacker executing an arbitrary token transfer (think
open allowanceto theTokenHandler) by calling theTokenHandlerwith a very large amount. Only preparedTokenTransfers can be executed.And furthermore, the storage of the
TokenTransferallows the outside world to inspect a pending transfer before its being executed (assuming the product is implemented in a way that, e.g. policy creation and transfer of the tokens do no happen in a single transactions).Security considerations
TODO: This section probably needs some more thoughts to ensure it cannot be maliciously used to execute arbitrary token transfers.
Its important that
TokenHandlers do not blindly executeTokenTransfers, but ensure that only theTokenHandlers of the component that created it can execute it. So it's necessary to also store whichTokenHandleris allowed to execute a transfer described by theTokenTransferobject. Also its required that the insertion ofTokenTransfers into theInstanceStoreis secure and no unauthorized entity can just do that (the address of the authorizedTokenHandlerneeds to be double checked during insertion to ensure if from the currently active component).Phase 2
This concept can be taken a step further by introducing signed
TokenTransfers. The user can now inspect the pendingTokenTransferbefore its executed and sign it. The product would then be required to allow thesignatureas an attribute to the transfer call. TheTokenHandlercan now verify this signature and only execute theTokenTransferif the signature matches.A quick doodle of the concept - probably not 100% correct (to be replaced)