ChainAgnostic / CAIPs

Chain Agnostic Improvement Proposals
https://chainagnostic.org
Creative Commons Zero v1.0 Universal
501 stars 148 forks source link

Supporting multiple chains with CAIP-122 #262

Open pedrouid opened 7 months ago

pedrouid commented 7 months ago

SIWx is a great standard but currently it only supports one chain per message signed

The multi-chain experience is now considered to be de facto standard for Web3 in general but SIWx is still designed for single-chain

This means that if you would like to authenticate yourself with SWIx for multiple chains then you need to sign multiple messages

The current Wallet UX does not support batch signing for messages and even if it did it would require a lot of inspection from users unless the UI would aggregate the common parts of the message

A much simpler approach would be to change CAIP-122 to support multiple chains

Instead of specifying a single chain per message then it could support a range of chains

This could be approach for example with the following options:

  1. We ignore chainId and just hardcode it to 1 then list chains in the resources as a ReCap
  2. We use an asterisk as a wildcard for chainId then list chains in the resources as a ReCap
  3. We use comma-separated values for chainId to list chains directly in the existing param

Each option has its own pros and cons:

  1. is backwards-compatible but then assumes its always Ethereum Mainnet
  2. is not backwards-compatible but it can be misused to assume all chains are valid
  3. is not backwards-compatible but its the only option that does not require ReCaps

Maybe there are options besides these ones above but I feel like something needs to be done address this

But the intended goal should be that if a user wants to authenticate for chain A, B and C then it should sign a single message rather than 3 messages

oed commented 7 months ago

This means that if you would like to authenticate yourself with SWIx for multiple chains then you need to sign multiple messages

Why is this the case?

Can you provide an example of the problem you are trying to solve here? "I want to sign in with multiple chainids at once" is not a problem, it's a proposed solution.

If I were to take a guess on what problem you are trying to solve I think you need to give dapps access to call rpc methods for multiple chains? However, I'm not sure why SIWE is relevant for that?

bumblefudge commented 7 months ago

"Just ignore" is always a dicey way of specifying behavior; perhaps the best solution is an extension spec that specifies exactly how to ignore or override CAIP122 behavior if X and Y conditions are met (presumably, resource array members, since that's basically the only open-ended part of the spec)? Even if that extension CAIP is only applicable to eip155, it might still be worth writing in a generic way and profiling in eip155/caipXXX.md in case some almost-evm compatible L1 wants to use it the same way with slightly different recaps or recap-equivalent capability expression format...