add wording and defition of match for authority

bsip-0040.md

@@ -60,13 +60,22 @@ 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.
 
+#### Wording
+
+A `custom active permission` contains a list of `custom active authority`. `Custom active authority` can match an operation of an incoming, signed transaction. The wording *matching* refers to:
+- `operationid` is equal to the id of the incoming operation
+- assigned account of parent `custom active permission` is in the required accounts of the operation
+- the `authority` of the `custom_active_authority` is given by the signatures of the transaction
+- `now` is within `valid_to` and `valid_from` 
+- all `asserts` pass positively
+
 ### Asserts
 
 The `asserts` is a list of `assert_objects` that are all together evaluated with `and` logic to evaluate a match
 ```
-asserts = list of assert_objects
+asserts = list of (argument_identifier, assert_object) tuples
+argument_identifier = // target unknown, can be argument of operation, or in a nested dictionary like struct
 assert_object = {
-    argument, // target argument of the operationid
     function, // functionid to do the assert 
     data,     // stores data specific to the chosen function
     state     // if this assert is statefull
@@ -132,11 +141,10 @@ custom active authority = {
        account_auth: []
     },
     asserts: [
-        {
+        (to, {
-            argument: to
             function: any,
             data: [B]
-        }
+        }) // this restricts the argument identified with "to"
     ]
 }
 ```
@@ -155,7 +163,7 @@ Furthermore, normal accounts can only create custom active authoritites with a d
 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 (match means its `authority` is granted through present signatures, same `operationid`,  now is within `valid_to` and `valid_from` and passes all `asserts`), remember that and stop iterating the authorities and continue until all operations are checked
+- if a `custom_active_authority` is found that matches , 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: