From e145ede26a88f0383d8b064074ad7a6a9caa97fe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20Schie=C3=9Fl?=
 <stefan.schiessl@blockchainprojectsbv.com>
Date: Mon, 30 Jul 2018 07:50:58 +0200
Subject: [PATCH] add wording and defition of match for authority

---
 bsip-0040.md | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/bsip-0040.md b/bsip-0040.md
index 31e8885..d33f5ca 100644
--- a/bsip-0040.md
+++ b/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: [
-        {
-            argument: to
+        (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: