Sorry for being unspecific - yup setting up auth wallets without transferring funds to them is what I meant.
jup that’s exactly what I meant with
The downside is that the standard reverse resolution of common node packages is no longer applicable. However, the relevant logic can be implement quickly - so this is would only be a small sacrifice.
I think this delegated reverse-resolution registration would warrant an own EIP (or ENSIP?) though as the applications may go beyond the one here. So it might be worth discussing it in a broader context. I could also see it being implemented as an extension to EIP-181 (ENSIP-3) replacing the registrar for addr.reverse with a revised one that supports something like setNameFor(address for, bytes calldata sig, address owner).
This way the standard ENS tooling can again be reused and it the authing scheme presented here would again be fully built on top of ENS.
I think adding extra behaviors to some names like “auth”, or “sign” or other common words seems like it could cause some annoyances in the future “Why can’t I name my subdomain ‘auth’ you say? Oh, some people in 2022 used it for their protocol and now things would randomly break if I do it”.
How about a different name with less chances of clashing like eip5131-auth.myname.eth?
ENS is working on a subdomain registrar (compare e.g. https://twitter.com/BrantlyMillegan/status/1408551428566753292) that allows issuing 3LD domains (or any nesting level actually) from 2LD that you don’t have access to / can not reclaim (similar to how 2LDs are issued under .ETH).
This will introduce situations in which a (new) owner of a second level ENS domain can potentially not control/reclaim auth.* subdomains of their ENS.
And it even allows for bad actor trades like setting up authN.* domains just before accepting an offer to a 2LD on a marketplace.