Users should see a clear, concise and contextually relevant message when signing canister calls / transactions in their wallet regardless of which canister they are interacting with. The information displayed should be understandable for non-technical users and (ideally) be available in multiple languages to match the users preferences.
Proposed Solution
Standardize a common canister interface (similar to how serving HTTP requires implementing specific methods). This canister interface can then be used to fetch consent messages for canister calls / transactions to be signed by the user.
Just a reminder: We will discuss this proposed standard and the next steps forward in the next session (on Tuesday) of the Identity and Wallet Standards working group.
The consent message needs to be certified. There is currently no widely supported mechanism to do this on the HTTP layer. Some drafts do exist, so I would consider this an avenue for future extension.
The standard specifies a signing canister with a known tECDSA pubkey. Canisters can send any arbitrary string to this signing canister, who returns sign(caller canister ID, message). The canister HTTP interface returns (message, signature) so that the external caller could verify the signature.
@0kenx: One important thing to note, is that the time is also relevant for the wallet to check. Otherwise, especially in the cold wallet use-case, wallets could be tricked into displaying outdated consent messages.
Also, wallets need an understanding of canister calls either way, in order to check the relation of the consent message to the canister call to be signed. So I’m not sure this would lift a lot of complexity from wallet implementers. On top of that, wallet implementers are also free to deploy a proxy canister on the IC that translates this consent message canister call interface to HTTP.
So in the interest of keeping the spec as small as possible (and not interfere with unrelated functionality a canister might have), I would prefer to not include HTTP in the spec.
Are there any other arguments, why this would be beneficial?
Also, please join the working group meeting linked above if you’d like to contribute more to this spec.
Now that I think more about it both time and wasm version don’t work for a cold wallet. A cold wallet can’t check the wasm version of the target canister, and it might not have access to a RTC.
The consent message is dependent on the arguments of the call that is being signed, so it is not static per wasm hash. Also it handles user preferences (currently only language, but might get expanded later), which adds another dimension.
So yes, it adds a lot of update calls, but the IC should be able to handle that. The long therm plan is to move it to replicated queries (once supported by the IC), which should be cheaper than update calls.
Why does the consent message need to be dynamic? Can’t it just include all parameters in all languages, and the wallet frontend can display accordingly?
Yes, the community is looking to build an Ethereum-compatible RPC into the IC, so that Metamask could be used to interact with the IC network directly.
