CAIP-25: Do wallets need their own namespace?

[rekmarks]

Ref: #138

Problem

Wallets may (and in fact do, see e.g. wallet_requestPermissions) implement their own RPC methods that have nothing to do with chains or CAIP namespaces as presently defined. There is currently no "wallet" namespace, so it's unclear how wallets would use CAIP-25 to restrict access to their own RPC methods.

Proposed Solution

N/A: we decided not to do anything about it. By the time the dapp is performing a CAIP-25 handshake (i.e. requesting the caip_handshake method), it is already communicating with the wallet by JSON-RPC. That being the case, the wallet can handle access control to its own JSON-RPC API by whatever means it deems necessary.

[kdenhartog]

I'd like to see us go with a wallet_* namespace for any calls that primarily rely on data which is stored off chain (e.g. private keys) and keep the eth_* namespace for any transaction that's primarily for interacting with data stored on chain.

Additionally, I think eth_sign should also be aliased to wallet_sign should within the wallet and eth_sign renamed, but I think we're past the point where it makes sense to do the renaming and eliminate ethsign and other `eth*` endpoints that were originally exposed via the node-based wallets.

[bumblefudge]

what about the VC stuff in #169 ? Early reviewers have said they find the directionality very confusing (the method names and spec don't really make clear who calls whom), and the idea of a separate creds_ namespace seems maybe messier than wallet_ (although the semantic directionality of a dapp calling a wallet with wallet_request_presentation, for example, is a little wonky?). To discuss at next RPC call, and/or next VC call...

[kdenhartog]

although the semantic directionality of a dapp calling a wallet with wallet_request_presentation, for example, is a little wonky

If these are meant to be APIs injected into a browser context for a website to interact with then this wallet_request_presentation seems like a good design. However, if this is meant to be a p2p API call that's made between two wallets interacting than yeah I could see how that's a bit wonky. However, I've not seen any wallets building with this architecture, so I'd be concerned that this would be an API designed without a use case.

[bumblefudge]

Just because you haven't seen them doesn't mean there aren't prototypes on private branches out there 😉