With the rise of SIWE, using and properlysecuring your self sovereign identity is more important than ever. However these two things seem at odds with each other.
With the following setup, I’d be free to SIWE on any dApp without putting my ENS name and other cold storage valuables at risk to a malicious contract/request:
Hold (Registrant) and control (Controller) my ENS name in cold storage along with my valuables
Resolve my ENS name to my cold storage address (Address)
Use a hot wallet to SIWE, Sign messages, mint NFTs etc. (Primary Name)
I attempted to implement this, but couldn’t. The impediment being that the Primary Name can only be set by the address in the Address field. I think this would work if the Controller had Primary Name privileges? But it doesn’t. I suppose I’m attempting to delegate my Primary Name?
I’m sure there’s a million reasons why this is a bad idea, but it also seems like a valid use case. It’s also very possible I’m misunderstanding something fundamental to the protocol. What am I missing?
I think I understand what you are saying. I’m a little bit confused about your ‘cold storage’ valuables being in the mix. I don’t think that keeping what most would consider valuable; on this chain --in the mix with your registrant or controller address(es) will be considered cold storage anymore. Just keep anything that you don’t want to risk in cold storage. Merely having valuables attached to a public account is enough to expose some degree of vulnerability as it is more information presented. if that makes sense.
Setting the primary name for a wallet address can be done by the wallet or any wallet which has been delegated to, so this part is not the problem. The problem is that the full reverse resolution process
requires that a forward resolution is completed and the addresses must match. If the eth address is set to a vault, then the address won’t match when logging into a site with a hot wallet.
What you are really describing is wallet delegation, which has to be handled by the dapp using a service like https://delegate.cash.
@accessor.eth The definition of cold storage hasn’t changed, what has changed is that people want to share cold wallets publicly and prove ownership of cold wallets using hot wallets.
Another way of explaining of what I’m (and many others) are trying to accomplish is:
Protect my NFT collection (including ENS name) in cold storage
Share my collection with people by simply providing my ENS name
Identify in Web3 as my ENS name without putting my cold storage assets at risk
As @Premm.eth points out, 1 and 2 are possible, 3 is not. Secondary registries (like delegate.cash) popping up is evidence of demand for this use case. Doesn’t ENS want to be the registry?
What if, as an example, we carved off an exception for a specific subdomain like delegate, and delegate.yourname.eth always resolved to the Parent’s address instead of the address in the address field. Then I could point the address field of delegate to my hot wallet so it could set my Primary name.
Throwing in more resources as examples of how others are linking wallets.
eternalproxy
“EPS is a way of linking together ethereum addresses. It allows you to interact with applications and smart contracts as one wallet address, while proving you own assets at another address, and have new assets delivered to an address you decide.”
The idea is to be able to login to a dapp, with a hot wallet and be able to have reverse resolution of that hot wallet address to your name that you hold in a vault and direct the forward resolution eth address to the vault as well.
One way to do this would be to add a step in the reverse resolution process, so that instead of just checking to see if the eth address is the same as the hot wallet logging in, it would be possible to check a delegation registry, where another address is trustlessly delegated to.
This is basically the same thing as delegate.cash, except we would be telling all the clients that they need to change the way they do reverse resolution, instead of just adopting a delegation service voluntarily. Using delegate.cash it is totally possible to delegate an individual ENS name to another wallet address.
It would be great if there was more info on this on the delegate.cash website and docs. If anyone wants to work on this, I am sure that delegate.cash would be happy to receive a pull request to their repo with information on how to delegate a name from a vault to a hot wallet and use it when doing reverse resolution.
Yes, but delegate.cash is a public good with a lot of attention on it from developers. Delegation always requires the owner of an asset to attest the validity of the delegated address. It could also be done with a signature that is submitted by the hot wallet though.
Does anyone know of any delegation systems that use a signature instead of a transaction on the part of the delegator?
Yes, but it would just be a competing delegation system, that happens to use ENS.
I don’t own a ledger or hardware wallet device as I do not use crypto as a store of value, currently. The way I perceive the definition and or classification of cold and hot walleting is that; the moment you connect your cold storage device to more than one other service for transfer of asset(s), essentially compromises the storage classifier. In that case cold storage loses it’s classifier as a cold storage and becomes a hot wallet, permanently. Once hot it can never go cold.
In light of recent events regarding CEX failures, I believe it is important that we should take up presenting the general public with education material. Teaching proper security procedure would be a great benefit to onboarding new ENS users. Teaching security through use of ENS will onboard more people than a speculative marketplace is capable of, predictively.
That being said, I would like to work with someone creating workflow diagrams so that there is less confusion and particularly illustrates security configurations that involve using ENS, registrant and controller assignees in conjunction with cold storage and hot wallets. If anyone is interested in talking about this in voice call, send me a PM.
