I think EIP-3074 actually does accomplish 1. To have a multisig, you could write an invoker that allows you to submit an artificial signature (hand picked r, s, v values), the members of the multisig, and the required threshold. The invoker would then not allow calls that use that artificial signature unless it is able to validate a multi-signature from the listed members.
Social recovery works similarly, except it doesn’t even need to be registered on chain. A user could sign a EIP-3074 authorization over N addresses and a threshold. The signature could be given to each member for safe keeping. If the user loses their private key, they could request that the members sign a EIP-3074 authorization to give control of the EOA to a new account the original owner controls. The multi-sig would be assembled and submitted on-chain with the original EIP-3074 authorization. The invoker could verify the threshold was met and allow the action to be executed.
The drawback to EIP-3074 access control policies is that you can’t revoke control of an EOA address from the private key. It can always circumvent the invoker.
There are two approaches to resolving these obstacles. The first involves a modification of AUTH at the time of the AA fork and an additional AUTH2 opcode. The second involves only a modification of AUTH in the current proposal.
Modifying AUTH during the AA fork
If we leave AUTH as it is now, we can in the future modify its behavior during the AA fork. The goal would be to disable secp256k1 ECDSA signatures for EOA smart contract wallets that have been upgraded. To do this, AUTH accepts the same stack operands and would continue to recover the signer of the EIP-3074 authorization. Before setting the authorized context variable to the recovered address, AUTH would call out to the recovered address using a standardized call interface to determine if contract allows authorizations via secp256k1 ECDSA signatures. If it does, it returns true. If it doesn’t, false. AUTH verifies the call returns true and then sets authorized to the recovered address. Otherwise, it fails.
To allow new cryptographic schemes to use EIP-3074 invokers, a new opcode AUTH2 would have to be introduced. Instead of performing any signature recovery (it doesn’t know what scheme was used), it just accepts the commit, the signature payload, and the authorizing address. AUTH2 would then call into the provided address to allow that contract to determine if the provided signature is valid. If the call returns true, AUTH2 would set the authorizing address as authorized.
Modifying AUTH now
The above proposal would require invokers to be redeployed to support the AUTH2 opcode. We could front run this by already defining AUTH to be the same as AUTH2 was defined above. This would cause EIP-3074 transaction flows to be more expensive today, but would allow us to avoid redeploying invokers in the future. To simplify things further until the AA fork, we could assume that AUTH recovers the signer as normal and ensures it’s equal to address passed to it. After the AA fork, it could call provided address to perform the recovery and validation.
(Thanks @SamWilsn for helping come up with these)