Update bsip-0040.md

bsip-0040.md

@@ -39,11 +39,13 @@ The above list of named keys is nothing that is known to the backend as the back
 
 # Rational
 
-The description here is more on a superficial level and no recommendation how it can best be implemented.
-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 a signed transaction arrives at the backend iterate the required accounts for each operations. If they have any one custom active authority that matches the given operation, signature and passes all asserts of the custom active authority, then the active authority of the required account is granted. This search can be stopped after finding one match.
+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. 
 
-### Custom active permission
+# Specification
+
+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
 
 A `custom_active_permission` looks like follows (in JSON for clarification, backend serializes and stores in a different way):
 ```
@@ -58,7 +60,7 @@ custom_active_authority = {
 ```
 Note: This assumes `custom_active_permission` is stored within `account_object`. Actual implementation details left to the implementer.
 
-### Possible asserts
+### Asserts
 
 The `asserts` is a list of `assert_objects` that are all together evaluated with `and` logic to evaluate a match
 ```
@@ -120,16 +122,29 @@ custom active authority = {
     ]
 }
 ```
-That has the consquence now that a a transfer transaction sending funds away from A can be signed with key K as long as the receiver is B.
+That has the consquence now that a transfer transaction sending funds away from A can be signed with key K as long as the receiver is B.
 
-# Specifications
-Requirements to modify the backend includes
-* 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
+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
 * Extend `account_update` or create a new operation to allow changing the custom active permission
 * Operation-specific authorities (if present) must be evaluated in incoming transactions
 * Additional committee parameters may be needed to limit the extend of usage of this feature
 
-Notes: The implementation must not differentiate the logic, all operations receive the same.
+Notes: The implementation must not differentiate on which operation the custom active authority is applied, all operations are treated in same fashion
 
 # Milestones
 We propose do split the implmentation into two milestones: