The Identity and Wallet Standards working group is working on a standard to have a common interface for wallets to receive human readable consent messages for wallets to display.
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.
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.
See the full specification here: wg-identity-authentication/consent-msg.md at frederik/consent-msg · dfinity/wg-identity-authentication · GitHub
See here: wg-identity-authentication/consent-msg.md at frederik/consent-msg · dfinity/wg-identity-authentication · GitHub
This is a draft specification. We are currently in the process of getting feedback and finalizing the specification.
If you have feedback, concerns or questions, please share them here in this thread or directly on the PR: Add specification for canister call consent messages by frederikrothenberger · Pull Request #22 · dfinity/wg-identity-authentication · GitHub
- Receive and incorporate feedback
- This standard will definitely be discussed again also in the next session of the working group which is on May 2.
- Wait for the discussion to settle on a specific variant (i.e. for consensus to form)
- Propose as an official ICRC-X standard via vote in the working group followed by an NNS motion proposal
(See also the process description here.)
Looking forward to a lively discussion!
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 should be exposed via the HTTP interface instead. This would make it easier for wallets to integrate.
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.
How about this:
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.
Maybe instead of
time, use the wasm hash of the canister?
This would be a lot of update calls, where as in my proposed solution the tECDSA only needs to be called once per wasm version.
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?
I guess this is related to the RPC work that is underway by ICLighthouse and AstroX.
Could you elaborate on that?
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.