Update bsip-0040.md

bsip-0040.md

@@ -46,7 +46,12 @@ This BSIP will be split into three parts that will be voted on separately (see M
 
 # 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` 
+(see Specifications for definition of "matching"), and if so behave as if the active authority of the corresponding account is present (recursive authorities are excluded, see Examples).
 
 # Specification
 
@@ -153,10 +158,10 @@ When a signed transaction arrives and before the backend evaluates if all necess
 - iterate over `required accounts`
   - iterate over all `operations` (child operations of proposal are not included) within the transactions that require the active authority of this account
     - iterate the `custom_active_authorities` of this account, and if it matches, remember that and continue with next `operation`
-  - if a `custom active authority` match was found for every operation in the loop, grant the `active authority` of this account
+  - if a `custom active authority` match was found for every operation in the loop, behave as if the `active authority` of this account is present for the correspoding operations
 
 Note:
-- A `custom_active_authority` can only grant the `active authority` of the corresponding account, nothing more
+- A `custom_active_authority` can only grant the `active authority` of the corresponding account for the matching operation, nothing more
 - The actual active authority of a required account can still be given as before, existing behavior is not to be changed
 - This for illustration, not actual implementation instructions
 
@@ -237,6 +242,27 @@ The transaction contains a transfer from A to account D. Required active authori
 - Signed by L and C: Denied. The custom active authority of B does not match, only applies for transfers with B as sender 
 - Signed by K: Accepted, basically bypassing multisig. This is intended, as the multisig needs to approve the installment of the custom active authority in the first place
 
+#### Recursive active authority
+
+Suppose Alice has a custom active authority with key K for transfers to Charlie. Bob has Alice as his active authority account. Suppose a transaction containing two operations
+
+1. transfer 1 BTS from Alice to Charlie
+2. transfer 1000 BTS from Bob to some other account
+
+Cases:
+- Transaction is signed by K
+   - Operation 1. requires Alice as active authority, and there is a matching custom active authority, thus this operation would be allowed to execute
+   - Operation 2. requires Bob as active authority. Even though Bob has Alice as active authority, K can NOT grant recursively the active authority of Bob
+   - The whole transaction is denied
+- Transaction is signed by K and A
+   - Operation 1. requires Alice as active authority and is also directly present, is allowed
+   - Operation 2. requires Bob as active authority, which is indirectly present through A, execution is allowed (existing logic)
+   - The whole transaction is denied because too many signatures are present (existing logic)
+- Transaction is signed by K and B
+   - Operation 1. requires Alice as active authority, and there is a matching custom active authority, thus this operation would be allowed to execute
+   - Operation 2. requires Bob as active authority and is also directly present, is allowed
+   - Transaction may execute
+
 #### Example: Either or
 Assume account A, B and C and asset X and asset Y. The custom active authority should now achieve
  that a transfer transaction sending funds away from A can be signed with with active authority of account B if 
@@ -326,7 +352,7 @@ The incoming transaction now contains `transfer 100 asset X from A to D, signed
 The required accounts (meaning required active authority) for the transaction is Account A. 
 Backend would start considering `custom active authority 1` and check if active authority of account B is present through signatures. 
 It is not, thus continue by checking if authority of `custom active authority 2` is present, which it is. 
-Acive authority of Account A is granted and normal authority checks are continued. 
+Behave as if active authority of Account A is present for the matched operation and continue with normal authority checks.
 Since the required accounts is Account A, and the given accounts is also Account A through `custom active authority 2`, 
 the transaction is executed.