chore: update spec (#176)

Co-authored-by: Zer0dot <zer0dot.dev@gmail.com>

Author: howydev

standard/ERCs/erc-6900.md

@@ -45,7 +45,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
   - **Execution functions** execute custom logic allowed by the account.
   - **Hooks** execute custom logic and checks before and/or after an execution function or validation function. There are two types of hooks:
     - **Validation hook** functions run before a validation function. These can enforce permissions on actions authorized by a validation function.
-    - **Execution hook** functions can run before and/or after an execution function. A pre execution hook may optionally return data to be consumed by a post execution hook function.
+    - **Execution hook** functions can run before and/or after an execution function. Hooks can be attached either to a specific execution function selector, or a validation function. A pre execution hook may optionally return data to be consumed by a post execution hook function.
 - A **native function** refers to a function implemented by the modular account, as opposed to a function added by a module.
 - A **module** is a deployed smart contract that hosts any amount of the above three kinds of modular functions.
 - A module **manifest** describes the execution functions, interface ids, and hooks that should be installed on the account.
@@ -246,8 +246,8 @@ struct ValidationDataView {
     bool isSignatureValidation;
     // The pre validation hooks for this validation function.
     ModuleEntity[] preValidationHooks;
-    // Permission hooks for this validation function.
-    HookConfig[] permissionHooks;
+    // Execution hooks to run with this validation function.
+    HookConfig[] executionHooks;
     // The set of selectors that may be validated by this validation function.
     bytes4[] selectors;
 }
@@ -272,14 +272,9 @@ interface IModularAccountView {
 
 #### `IModule.sol`
 
-Module interface. Modules **MUST** implement this interface to support module management and interactions with MSCAs.
+Module interface. Modules **MUST** implement this interface to support module management and interactions with ERC-6900 modular accounts.
 
 ```solidity
-struct SelectorPermission {
-    bytes4 functionSelector;
-    string permissionDescription;
-}
-
 /// @dev A struct holding fields to describe the module in a purely view context. Intended for front end clients.
 struct ModuleMetadata {
     // A human-readable name of the module.
@@ -289,11 +284,6 @@ struct ModuleMetadata {
     // The author field SHOULD be a username representing the identity of the user or organization
     // that created this module.
     string author;
-    // String desciptions of the relative sensitivity of specific functions. The selectors MUST be selectors for
-    // functions implemented by this module.
-    SelectorPermission[] permissionDescriptors;
-    // A list of all ERC-7715 permission strings that the module could possibly use
-    string[] permissionRequest;
 }
 
 interface IModule is IERC165 {
@@ -492,7 +482,7 @@ Validation installation MAY be deferred until a later time, such as upon first u
 During validation installation, the account MUST correctly set flags and other fields based on the incoming data provided by the user.
 
 - the account MUST install all pre validation hooks required by the user and SHOULD call `onInstall` with the user-provided data on the hook module to initialize the states if required by user.
-- the account MUST install all permission hooks required by the user and SHOULD call `onInstall` with the user-provided data on the hook module to initialize the states if required by user.
+- the account MUST install all execution hooks required by the user and SHOULD call `onInstall` with the user-provided data on the hook module to initialize the states if required by user.
 - the account MUST add all selectors required by the user that the validation can validate.
 - the account MUST set all flags as required, like `isGlobal`, `isSignatureValidation`, and `isUserOpValidation`.
 - the account SHOULD call `onInstall` on the validation module to initialize the states if required by user.
@@ -503,7 +493,7 @@ During validation installation, the account MUST correctly set flags and other f
 During validation uninstallation, the account MUST correctly clear flags and other fields based on the incoming data provided by the user.
 
 - the account MUST clear all flags for the validation function, like `isGlobal`, `isSignatureValidation`, and `isUserOpValidation`.
-- the account MUST remomve all hooks and SHOULD clear hook module states by calling `onUninstall` with the user-provided data for each hook, including both pre validation hooks and permission hooks, if required by user.
+- the account MUST remomve all hooks and SHOULD clear hook module states by calling `onUninstall` with the user-provided data for each hook, including both pre validation hooks and execution hooks, if required by user.
 - the account MUST remove all selectors that the validation function can validate.
 - the account MUST emit `ValidationUninstalled` as defined in the interface for all uninstalled validations.
 
@@ -573,7 +563,7 @@ For all non-view functions within `IModularAccount` except `executeWithAuthoriza
 
 If the caller is not the EntryPoint or the account, the account MUST check access control for direct call validation.
 
-Prior to running the target function, the modular account MUST run all pre execution hooks that apply for the current function call. Pre execution hooks apply if they have been installed to the currently running function selector, or if they are installed as a permission hook to the validation function that was used for the current execution. Pre execution hooks MUST run validation-associated hooks first, then selector-associated hooks second.
+Prior to running the target function, the modular account MUST run all pre execution hooks that apply for the current function call. Pre execution hooks apply if they have been installed to the currently running function selector, or if they are installed as an execution hook to the validation function that was used for the current execution. Pre execution hooks MUST run validation-associated hooks first, then selector-associated hooks second.
 
 Next, the modular account MUST run the target function, either an account native function or a module-defined execution function.