Are there any plans to add support for ICRC-2 (and ICRC-3)?
Yes. Looking into ICRC-2 soon. But hasn’t started yet.
What you describe sounds very doable even without a Snap, it is very similar to step 1-3 in the flow I’m using. Signing a message with Metamask and using the hash of that signature to generate an Identity effectively means creating a delegate identity based on your Eth key.
In addition to the SIWE library I will also publish a npm package with a React Hook and Identity provider to support apps to maintain the delegate identity during the duration of the session.
I’ll have a look at your codebase and will also read up on Snaps - maybe there is some detail I’m missing here? Building a Snap would be cool but… not having to build one is even better.
What about another dapp requesting Metamask to sign the same message? It will get access to the identity. Is the UI displaying it in a way that informs the user about the risks or they are signing some unintelligible bits?
What to include in the message is up to the developer. This is the message I’m showing in the demo app.
But yes, relying on this method only is not the most secure approach. One additional issue is, as I describe above, that the Identity never expires. Doing the additional steps, the SIWE flow, adds a layer of security. That is not possible though in the wallet case as there is no backend canister other than the ledger.
Once vetKeys is launched, an app specific indentity seed can be generated by a SIWE enabled canister upon user login and sent securely to the client to be turned into an Identity.
Signing a message with Metamask as you do follows a certain “Sign with Ethereum” standard. The message is encoded, prefixed and hashed in a certain way. That format is not natively understood by the IC. Not for an ingress request nor for a delegation. And Metamask wouldn’t allow you to sign arbitrary data or an arbitrary hash because obviously that would be to dangerous. Metamask will only let you sign something that it understands and that it can display in the user interface. So you need a custom Metamask which is exactly what a Snap is.
Actually, MetaMask (and only MetaMask AFAIK) lets you sign arbitrary messages if you enable it, but definitely not a good strategy to target mainstream users.
I’ve created a PoC some time ago to demonstrate it: GitHub - domwoe/metamask-ic: Example project to explore signing with MetaMask on the Internet Computer
(Seems to be a bit broken now unfortunately.)
Yeah, reading about snaps now. Looks cool. An “IC snap” would be the thing to build, right? Not a “ICRC-1 wallet snap” but a snap that facilitates interaction with any IC app that supports the IC snap. Using
snap_getEntropy (salt = app domain) looks like one potential way to securely generate a seed for an IC identity.
The most generic Snap would be for login. It would sign a delegation to a session key created in the browser.
Here are two links (the second one was posted above already in this thread):
As @infu rightly pointed out, generating the identity fully in the browser, using the signatures as seed, is a security risk. A malicious app B could replay the same message to get the same identity to the access canister A and do foul stuff. Most Ethereum wallets provide some protection against this as signing a SIWE message from a domain other than the on you are currently visiting will produce a big red warning. But, relying on the wallets to provide 100% protection does not feel right.
Instead, for the ic-siwe library I will borrow some code from Internet Identity and allow canisters instead to create full signature delegations instead. More info
There is now NFID login and we have integrated OGY and GLDT as pre-defined tokens. So the wallet is ready for GLDT from day one as soon as that token becomes available.
The other changes are UI improvements and faster balance queries.
The wallet has been updated with an additional token pre-defined: GLDGov.
Moreover it is now possible to define for each token the desired number of displayed decimals. This can be set to a smaller number than the full decimals that the token offers. It is helpful for ckETH which, quite annoyingly, has 18 decimals.
Here are screenshots of the same balance with different settings and of the dialog where the limit can be set:
@timo I added support for SIWE to the ICRC-1 wallet .
See video here:
Let me know if you think it is an ok implementation. Adding another login method to the existing ones becomes a little bit messy, since SIWE works slightly different. For a super clean integration I would build a popup solution similar to the one II is using.
Nice. Thank you very much. It’s awesome.