feat(caip-222): multi-chain wallet authentication

[ganchoradkov]

Updated CAIP-222 to support multi-chain authentication.

Added ability to

• request signatures for multiple chains in a single request
• specify supported signing types via signatureTypes request parameter
• respond with a list of signed CACAOs

[oed]

So if I support both eip191 and eip1271 I can just not define this field and get either?

[bumblefudge]

yeah that's a good question. does not setting the parameter mean you have no preference and will TRY to verify anything?

We should define explicitly how to interpret the absence of an array, i think

[bumblefudge]

i think wildcards are kind of unsafe and likely to lead to bad UX deadends; better for dapps to have to explicitly list which kinds they support, I would think.

[ganchoradkov]

The v1 (merged version) is very optimistic that the sender application would be able to validate the returned signature without knowing the signing type especially now that you could request non-evm signatures. This parameter lets you specify exactly which types you're supporting. Whether you can omit it, its up for debate. I've set it as optional to reduce devex friction.

[bumblefudge]

OK added a sentence to the definition above, take a look

[arein]

should this be optional and the wallet can just respond with any of those it supports?

[ganchoradkov]

The rationale is that the dapp would request signatures for all chains included in the chains parameter and the wallet would respond with signatures for those it supports as outlined here

The wallet SHOULD ignore all unsupported chains and SHOULD NOT auto reject the request if there are supported chains to sign without explicit user rejection.

In v1, chainId is required parameter so it makes sense to preserve that to an extended.
Additionally, setting chains to explicitely empty [] array is valid and kinda allows to not set any chains already.

[bumblefudge]

i think chainIds is the dapp telling the wallet which kinds of addresses it WANTS exposed (and implicitly, has use for). it might even be worth mentioning (in ### Security Considerations, if nowhere else) that a wallet COULD return addresses not on any of the requested chains (or choose which addresses to return if chains array was empty), but this is unspecified behavior and may lead to confusing UX.

my thought on an empty chainId is that it kinda translates to "any EVM keypair, I don't care" if combined with a set of signatureTypes that are all EVM-equivalent ( "eip155":{'eip191', 'eip1271'}, "polkadot":{'moonBeamSign'}", ... ). if emptyChainId but also un-specified signatureTypes.... I would just drop as a wallet, there's no way of knowing what that means.

not sure all this is worth putting INTO the spec, but it's the corner cases that come to my mind so far.

[bumblefudge]

I'm still wondering if it makes more sense for the multi-CAIP222 to be CAIP-248 or CAIP-222; would love input from potential or early implementers.

[ganchoradkov]

I'm still wondering if it makes more sense for the multi-CAIP222 to be CAIP-248 or CAIP-222; would love input from potential or early implementers.

@bumblefudge imho, it should be an update as it complely encapsulates the merged CAIP-222. Additionally, having them as different standards would cause conflics if one attempts to implement them at the same time in their current form forcing implementers to choose one OR the other

[bumblefudge]

OK added a sentence to the definition above, take a look

[bumblefudge]

i think chainIds is the dapp telling the wallet which kinds of addresses it WANTS exposed (and implicitly, has use for). it might even be worth mentioning (in ### Security Considerations, if nowhere else) that a wallet COULD return addresses not on any of the requested chains (or choose which addresses to return if chains array was empty), but this is unspecified behavior and may lead to confusing UX.

my thought on an empty chainId is that it kinda translates to "any EVM keypair, I don't care" if combined with a set of signatureTypes that are all EVM-equivalent ( "eip155":{'eip191', 'eip1271'}, "polkadot":{'moonBeamSign'}", ... ). if emptyChainId but also un-specified signatureTypes.... I would just drop as a wallet, there's no way of knowing what that means.

not sure all this is worth putting INTO the spec, but it's the corner cases that come to my mind so far.