ERC: Permission Contract

[3esmit]

EIP: <to be assigned>
Title: ERC745 Permission
Author: Ricardo Guilherme Schmidt <ricardo3@status.im>
Type: Standard Track
Category: ERC
Status: Draft
Created: 2017-10-20

Summary

Permissions are contracts that allow controlled actions from other addresses.

Abstract

ERC #725 Identity can contain Keys that performs actions over the Identity. In order to limit actions of authorized addresses in behalf of the Identity, the Permission contract would be crafted specifically for each dapp demanding control of Identity.

Motivation

The need of different types of permissioning for ERC725, that are unique for each use-case, are not scope of ERC725.
The standardization of the permissions would help wallets understand the agreements proposed by DApps, although, as in Identity and other standards, the source code of DApp must be trusted by users and this standards only help easier coupling between contracts and UI.
If a Identity is controlled by Permission contract then it could understand the options.
Other implementation under would be 'Account recovery','Dead man switch','Multisig', 'Daily-limit'.

Definitions

• Permission is a smart contract with arbitrary rules for execution with ERC725 identity. The contract bytecode needs to be trusted by identity holder.
  • Native Call Permission is a Permission implementation that allow certain native calls to certain addresses
  • ERC20 Approve-Call Permission is a specific permission implementation that allow transfer of ERC20 tokens safely by approve and call.
• Permission Manager is a smart contract that helps user activating permission contracts in a single call.
• Period Length is a value in seconds of length where Period Limit will reset.
• Period Limit is a value in wei/token of how much can be spent in that period
• Call Max Value is a value in wei/token the maximum each call to that function can contain

Other definitions are up to the use-case.

Specification

pragma solidity ^0.4.17;

contract ERC745 {

    event Authorized(address _destination, uint _maxValue, bytes4 _method, uint expiration);
    event Unauthorized(address _destination, bytes4 _method);
    event Executed(address _destination, uint _value, bytes4 _method);

    /**
     * @notice Authorizes call method `_method` to `_destination` with maximum value of `_maxValue` with expiration of `_expiration`;
     */
    function authorize(address _destination, uint _maxValue, bytes4 _method, uint _expiration) public;
    
    /**
     * @notice Unauthorizes call method `_method` to `_destination`.
     */
    function unauthorize(address _destination, bytes4 _method) public;
    
    /**
     * @dev executes into `_destination`.
     */
    function execute(address _destination, uint _value, bytes _data) public returns (bool result);
    
    /**
     * @dev reads authorization
     */
    function isAuthorized(address _trustedCaller, address _destination, uint256 _value, bytes _data) public constant returns(bool);

}

[3esmit]

Related to #662

[Arachnid]

This seems very similar to the authority pattern: https://github.com/ethpm/escape/blob/master/contracts/Authority.sol

[VoR0220]

Seems unnecessary for all non PoA chains.

[3esmit]

@VoR0220 I think you miss understood the reason of this. BTW, the propsed ABI is not fixed yet, I'll develop a some implementations of Permission for Identity (#725), such as DeadManSwitch, and MultiSig

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.