- Witness Key: Only allows update signing key and publish price feed
- Trading Key: Only allows limit orders (arguments restricted to desired markets), update margin position and transfers (arguments restricted to certain accounts)
- Proposal Update Key: Approve proposals (2FA comes to mind)
Custom active permission is a list of `custom active authorities`. A `custom active authority` contains an `operation_id`, an `authority` (just like with active permission) and `asserts` than can be used to restrict arguments and is only valid a certain time period (`valid_from` and `valid_to`). When handling incoming signed transactions, the backend checks for each operation if there is a `custom active authority` for any of the required accounts. If all operations within the transaction have a matching `custom active authority` (match means same `operationid`, now is within `valid_to` and `valid_from` and all `asserts` pass), then active authority of the corresponding account is granted.
All descriptions in this section are on a pseudo/prosa level and no recommendation how it can best be implemented or serialized. They are meant to facilitate the understanding.
### Custom active permission and custom active authority
Note: This assumes `custom_active_permission` is stored within `account_object`. Actual implementation details left to the implementer, as long as every `custom_active_permission` can be assigned to exactly one account.
All asserts apply to `int`, `string` and `object_ids`. There is no type converstion, incompatible type means assert failure. Any more sophisticated data types are not included yet.
#### `any`
Stateless assert, all argument types. Value of argument must be equal to one of values in the list
#### `range`
Stateless assert, only `int` type arguments. Value must be inbetween `min` and `max`, inclusive. One of the bounds can be empty to indicate unlimited.
#### `length`
Stateless assert, only `string` type arguments. Length of string (or encrypted string in case of memo) must be within `min` and `max`, inclusive. One of the bounds can be empty to indicate unlimited.
#### `limit`
Statefull assert, only `int` type arguments. When the authority is created, `interval_began` is set to `valid_from` from its custom active authority and `max_cumsum` to `0`. Incoming operations are first tried to match all stateless asserts,
and if all passes continue with statefull asserts. If `now > interval_began + interval_in_sec`, then set `max_cumsum = 0` and set `interval_began = now`.
The assert that needs to pass is now `current_cumsum + incoming value <= max_cumsum`. If all asserts are passed, update `current_cumsum = current_cumsum + incoming value` of all involved statefull asserts.
Statefull assert, only `int` type arguments. Analogue to `limit`, but `interval_began` is initially set to `month(valid_from)` and set to `month(now)` on update, additionally the time assert is `month(now) >= interval_began + interval_in_months` (include logic for month overflow when year changes).
Note: This is just an illustration of a possible serialization, not a specification of the serialized format.
### Outline of handling incoming transactions
When a signed transaction arrives and before the backend evaluates if all necessary authorities are present through the signatures, do the following:
- iterate over required accounts and for each account, iterate over all operations within the transactions that require the active authority of this account
- iterate the `custom_active_authorities` of said account
- if a `custom_active_authority` is found that matches (same `operationid` and passes all `asserts`), remember that and stop iterating the authorities and continue until all operations are checked
- if the account has a `custom active authority` match for every operation in the transaction that requires it, then grant the `active authority` of said account. If no match is found, treat as if no authority was given
Note:
- A `custom_active_authority` can only grant the `active authority` of the corresponding account, nothing more
### Modification to the backend
* Extend the account object to store custom active permission that includes a list of custom active authorities. Multiple custom active authority entries are possible for one operation
* If the active authority of the account is updated, all custom active authorities need to be confirmed in the update. Every unconfirmed one is deleted otherwise
Bad publicity in terms of security can have very negative effect on the BTS value. This BSIP allows that traders can e.g. use a trading key, witnesses can use their witness key and a faucet can use a faucet key. If then for some reason the key or witness/faucet server becomes compromised, such a key can do little harm to the account holders, minimizing the risk.
This BSIP opens up a lot of use-cases as presented in Motivation section. The intention is to not alter any existing logic of the permission system, which reduces the risk of malfunctioning.
