ICRC-27/49: Clarify permission check (#207)

* ICRC-27/49: Clarify permission check

Clarify the permission check step in message processing to be
aligned with the 3-state permission change previously made in
ICRC-25 (see #185).

* Add reference to ICRC-25 permission states

topics/icrc_27_accounts.md

@@ -101,8 +101,9 @@ None
 
 1. The relying party sends a `icrc27_accounts` request to the signer.
 2. Upon receiving the message, the signer first checks if it can process the message.
-    - If the relying party has not been granted the permission to invoke the method,
+    - If the relying party has been denied the permission to invoke the method,
       the signer sends a response with an error back to the relying party.
+      If the permission state is `ask_on_use`, the signer must prompt the user to either accept or deny this invocation. See [permission states](icrc_25_signer_interaction_standard.md#permissions-states) for more details.
 3. The signer MAY prompt the user to select which accounts to share.
     - If the signer prompts the user, it SHOULD do so for each request so that the
       relying party can offer the user the option to update / change the selection.

topics/icrc_49_call_canister.md

@@ -106,8 +106,9 @@ An ICRC-25 compliant signer must implement the [icrc25_supported_standards](./ic
 
 1. The relying party sends a `icrc49_call_canister` request to the signer.
 2. Upon receiving the request, the signer validates whether it can process the message.
-    - If the relying party has not been granted the permission to request the action, the signer sends a response with an error back to the relying party.
-        - The sender must make sure that the request complies with additional scope restrictions defined by the signer (if any), such as limitations on the target canister id or the sender principal, etc.
+    - If the relying party has been denied the permission to invoke the method,
+      the signer sends a response with an error back to the relying party.
+      If the permission state is `ask_on_use`, the signer must prompt the user to either accept or deny this invocation. See [permission states](icrc_25_signer_interaction_standard.md#permissions-states) for more details.
 3. The signer tries to retrieve and verify the consent message according to the [ICRC-21](icrc_21_consent_msg.md) specification. If the target canister does not support ICRC-21 consent messages for the given canister call, the signer may proceed in one of following ways:
    * The signer rejects the request and sends a response with the error code 2001 back to the relying party. Step 4 is skipped.
    * The signer displays a warning, tries to decode the arguments by itself and displays raw canister call details. If the arguments cannot be decoded, a strong warning must be displayed.