add enabled flag

bsip-0040.md

@@ -26,7 +26,7 @@ Any successfull hacking or phishing attempt on any of the web wallets that are p
 BitShares Blockchain is bad publicity. The user needs to be educated in account security, and this BSIP
 aims to ensure all technical possibilities are met while being flexible to allow many use-cases. 
 
-With this BSIP any user can create keys with specific purpose (everything else is prohibited). We list some possibilities below:
+With this BSIP any user can create additional keys with specific purpose (everything else is prohibited). We list some possibilities below:
  - 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)
@@ -37,11 +37,13 @@ With this BSIP any user can create keys with specific purpose (everything else i
 The above list of named keys is nothing that is known to the backend as the backend should have an abstract implementation.
  The UI could provide a button "Create Trading Key" that properly configures the respective custom active permission entry.
 
+Note: The user can still use the active authority just like used to, no change in existing behavior. The named keys only give an additional possibility. For example: The user can login the UI using the private key of such a named key. Then he only as access to the operations that this named key grants. He can still login with the existing password to gain full access (similar a local wallet can be created that only contains the named key).
+
 This BSIP will be split into three parts that will be voted on separately (see Milestones section). All of the above keys are possible with Milestone 1. Milestone 2 allows stateful restrictions (e.g. allow market orders up to some amount for every month), Milestone 3 gives finer control of how to combine restrictions. Milestone 2 and 3 will be put up for voting if Milestone 1 proves successful.
 
 # Rational
 
-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 `restrictions` 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 its required accounts. Check for every required account of the transaction if all its belonging operations have at least one positively matched `custom active authority` (match means its `authority` is granted through present signatures, same `operation_id`, now is within `valid_to` and `valid_from` and none of the `restrictions` is violated), and if so grant the active authority of the corresponding account. 
+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 `restrictions` 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 its required accounts. Check for every required account of the transaction if all its belonging operations have at least one positively matched `custom active authority` (match means its `authority` is granted through present signatures, same `operation_id`, now is within `valid_to` and `valid_from` and none of the `restrictions` is violated), and if so grant the active authority of the corresponding account.
 
 # Specification
 
@@ -56,6 +58,7 @@ custom_active_permission = {
     authorities = list of custom_active_authority objects
 }
 custom_active_authority = {
+    enabled,       // status of this authority, true or false. true when created
     valid_from,    // timestamp when this is active
     valid_to,      // timestamp when this is invalid
     operation_id,   // operation id of the target operation,
@@ -162,7 +165,7 @@ Normal accounts can only create custom active authoritites with a duration of ma
 ### Modification to the backend
 
 * Add a new index or extend the account object to store custom active permission are assigned to an account and contain 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
+* If the active authority of the account is updated, all custom active authorities are disabled and must be enabled again with using `update_custom_active_authority`
 * Provide operations: `install_custom_active_authority`, `update_custom_active_authority`, `delete_custom_active_authority` to allow changing the custom active permission (3 operation to allow custom transaction fees and avoid having to send the complete list of all authorities for every update)
 * Operation-specific authorities (if present) must be evaluated in incoming transactions
 * Remove expired custom_active_authorities on maintenance