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 #4668 (comment)

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 f12077d

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

2. shallow objects [refactor]: Shallow objects in data_model #3921 should allow AccountId to be independent of DomainId

   struct AccountId(PublicKey);

3. multisig accounts Reimplement multi-signature #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),
   }