I want to ask a question regarding the II connection to Uniswap in today’s demo. In particular, how is the signature key generated to make the update call to the canister?
In the demo, I think we are signing a payload for a function called key in this canister at the beginning. (There doesn’t seem to be a candid file).
In the case of usual delegation by II, I think the key pair of ed25519 is stored in browser’s local storage.
However, when I looked at uniswap frontend on ICP, there was no session key pair in browser’s local storage.
Please tell me how the key pair that signs the payload is created. Or did you change the location of the session key storage?
What demo are you referring to? Sounds interesting, can you share a link?
it is the usual II delegation and it’s stored in the local IndexDB. The signing canister uses the principal of the caller as the derivation path for the key. Thereby each caller gets its own Ethereum address.
This is a straightforward integration and the goal is just to showcase what’s possible and inspire others to build more elaborate canister-powered wallets for end users as well as a management infrastructure for DAOs with smart contracts on other platforms.
Thank you. Will all other dapps’ session keys also be migrated from the local storage to the indexdDB?
I assume that until now, session keys have been stored in local storage for all apps.
It depends on which version of agent-js dApps are using. Since version 0.13.0 the auth client uses IndexDB instead of LocalStorage (see changelog).
What about the security of this system?
Is it safe to assume that canister signatures are as secure as what is done with Internet Identity? Is there anything you can assume that would be of concern?