Yes, I’m familiar with 6551 (I’m an author on it), but this EIP is specifically for non-web3 identifiers linking to web3 accounts for future claim via a controlled registry. The open question right now is how signing could be supported in such a design.
AA via an NFT doesn’t really make sense here (I’ve tried an implementation around it, and it’s far too clunky).
The pattern I’m thinking of at the moment is a scheme where authentication could be delegated to the contract factory. But thinking more about it, this may be impossible to validate, as how could one ensure that a given counterfactual address is indeed deployable by an indicated factory without simulation (which is what you’ve addressed via the multicall in your spec).
Off topic, but would appreciate further thoughts around security on this thread:
I’m not sure I understand the security concern here. The deploy data is leaked in the mempool, but the account creation verification is based on a registry’s configured signing key, so it wouldn’t really matter who ends up performing the transaction, as it would still assign the wallet to the appropriate owner.