identify trigger as an account?

[s8sato]

I guess trigger will be able to be identified as an account.

I don't think it has been broken down into issues yet. If we want to support use cases where a trigger needs different permission than the registrant account (e.g. swap between two accounts, #1212), the trigger should reference its own account (or should be identified as an account). The ideas of system level triggers and technical accounts were suggested in as early as Triggers ADR. Similar concepts include Contract Address and Program Derived Addresses

_Originally posted by @s8sato in https://github.com/hyperledger/iroha/pull/4668#discussion_r1620176299_

In this way, trigger has authority different from the registrant and can manage transactions involving multiple authorities. Use cases such as locking assets could also be implemented by the trigger taking the assets

[s8sato]

One of the possible paths is as follows:

1. as of f12077d35

   struct AccountId {
       domain_id: DomainId,
       signatory: PublicKey,
   }

2. shallow objects #3921 should allow AccountId to be independent of DomainId

   struct AccountId(PublicKey);

3. multisig accounts #4373 should require AccountId to be like enum

   enum AccountId {
       Personal(PublicKey),
       Shared(RawId),
   }
   
   type RawId = Box<[u8; 32]>;

4. add a variant for triggers

   enum AccountId {
       Personal(PublicKey),
       Shared(RawId),
       Trigger(RawId),
   }