Built-in sign/verify/recover signer functionality for canisters

[atengberg]

While the IC is designed to be a distributed computing platform for blockchain technologies, the other half of the equation is P2P and E2E use cases. Additionally, with the direct integration of Btc, Eth, etc it would greatly help IC adoption if canisters (particularly Motoko) had built-in/standard set of functions to sign, verify and authenticate/recover who signed (such as these from Metamask or Solidity's erecover).

For some discussion of what this means, see this forum thread.

I imagine it could also be used to double as a way to delegate certification in a way that would extend to wallets not just exclusively belonging to the IC.

This is already something that has been asked about, and as more web3 devs from Ethereum head over, will become more important. Providing this functionality 'by default' in a canister would open up a lot more possibilities.

[iclighthouse]

It is recommended to implement EIP712 signature verification function and promote EIP712 signature in the front-end.
There are several reasons for this.

1. EIP712 signatures have human readability support and support application scenarios that require security.
2. Mainstream wallets (e.g. MetaMask) have implemented EIP712 signature and signature verification.

[domwoe]

Here's a PoC using "Sign-in with Ethereum" (ERC-4361) implemented in siwe-rs. which itself uses ERC-191 (Signed Data Standard) over EIP-712 (Ethereum typed structured data hashing and signing) https://github.com/domwoe/siwe_authz/blob/main/src/identity_proxy/src/lib.rs

There's no Motoko implementation yet, but shouldn't be too hard given https://github.com/tgalal/motoko-bitcoin, so I'm not sure if we'd really need a new system API for this.

[atengberg]

Thanks @iclighthouse and @domwoe.

While there is overlap with encryption standards and specifications, I believe it would be worth it to formalize as part of the "official canister set of methods" (perhaps just in Motoko, or there could be a standard "Wallet" API used in both Rust and Motoko canisters) even if it is just "semantic sugar" as it would provide a point of reference already familiar to Web3 developers from whatever chain they may be coming from or building a canister for. I wonder if it could also double as part of how certification can be delegated if it could be used to elevate the functionality of something like dfx sign/verify into a canister, for instance.