add plugin permissions to ARC

ARCs/arc-0058.md

@@ -217,6 +217,10 @@ An Abstracted Account App that adheres to this standard **MUST** implement the f
 
 Plugins are applications that the Abstracted Account App **MUST** rekey to when `rekeyToPlugin` or `rekeyToNamedPlugin` is called. After a plugin has been rekeyed to, the abstracted account **MUST** be rekeyed back to the abstracted account application. When and how this rekey is done does not matter, but it **MUST** be verified by a call `verifyAuthAddr` as the last transaction in the group OR the last transaction in the group must be an explicit rekey transaction.
 
+### Plugin Permissions
+
+When adding a plugin, the the admin can specify an end time and a specific address that is allowed to call `rekeyToPlugin` for that specific plugin. Using the zero address will allow anyone to use the plugin. If `global LatestTimeStamp` has past the specified end time, the `rekeyToPlugin` call **MUST** fail. If the permitted address is not the zero address, the `rekeyToPlugin` call **MUST** fail.
+
 #### Named Plugins
 
 The admin can optionally add a named plugin to their abstracted account application. Any name that matches the regex `/^ARC\d+$/` **MUST** implement the interface(s) described in the respective ARC. The ARC number **MUST NOT** have any leading 0s.
@@ -232,6 +236,10 @@ There have similar propsoals for reducing end-user friction, such as [ARC-47](./
 ### Plugins
 Rather than constantly updating the approval program of the abstracted account application to add functionality, it is safer and easier to simply add additional apps that enable the desired functionality. This also gives the end-user more control over what various dApps can do with their account at any time.
 
+### Plugin Permisions
+
+A common use case for plugins will be end-users allowing specific apps to perform actions on their account. As such, implementing this in the Abstracted Account App allows for wallets and other ecosystem tools to easy display permissions to end users. The end time is also useful to ensure a user only enables a plugin for the time that it would be useful for them. The concept of plugins is similar to approvals on EVM chains and there have been cases where old approvals became an attack vector.
+
 ## Backwards Compatibility
 Existing Algorand accounts can transition to an abstracted account by creating a new abstracted account application and setting the address to their current address. This requires them to create a new account to act as the admin.
 
@@ -442,7 +450,9 @@ https://github.com/joe-p/account_abstraction.git
 TODO: Migrate to ARC repo, but waiting until development has settled.
 
 ## Security Considerations
-By adding a plugin to an abstracted account, that plugin can be called by anyone which will initiate a rekey from the abstracted account to the plugin app address. While the plugin must rekey back, there is no safeguards on what the plugin does when it has authority over the abstracted account. As such, extreme diligance must be taken by the end-user to ensure they are adding safe and/or trusted plugins. The security assumptions for plugins are very similar to delegated logic signatures, with the exception that plugins can always be revoked.
+By adding a plugin to an abstracted account, that plugin can get complete control of the account. As such, extreme diligance must be taken by the end-user to ensure they are adding safe and/or trusted plugins. The security assumptions for plugins are very similar to delegated logic signatures, with the exception that plugins can always be revoked.
+
+The security assumptions of plugins are also similar to EVM approvals, which are a common source of exploits and scams. Implementations of plugins Algorand should learn from the lessons of EVM approvals.
 
 ## Copyright
 Copyright and related rights waived via <a href="https://creativecommons.org/publicdomain/zero/1.0/">CCO</a>.