Are there any plans to add support for ICRC-2 (and ICRC-3)?
Yes. Looking into ICRC-2 soon. But hasnāt started yet.
1 Like
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.)
1 Like
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):
1 Like
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 
We have merged a PR with some updates into the repo: GitHub - research-ag/wallet
And also updated the frontend deployed here: https://e4hv6-7yaaa-aaaao-a2ida-cai.icp0.io/
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.
1 Like
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:
PR:
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.
Live website:
2 Likes
Nice. Thank you very much. Itās awesome.
2 Likes
We have released today an alpha version of the ICRC-1 wallet, hosted on: https://wallet.ic0.info/
The wallet aims to be a versatile tool for advanced users that allows full and fine-grained control over your assets. This includes for example:
- adding custom assets for which you know the ledger principal
- controlling the full subaccount space that ICRC-1 offers by either using enumerated subaccount indices (0,1,2,ā¦) or raw 32 byte indices or by embedding principals into the subaccount index
- setting up allowances for others (with expiration, from any subaccount, etc.)
- finding allowances from others for you
- managing contacts and subaccounts of contacts
- providing a wide range of login mechanisms (II, NFID, SiWE, mnemonic)
- providing a watch-only mode without any login
Some of these features are unique and cannot be found in any other wallet.
The goal was to explore how these advanced features can actually be embedded in an easy-to-use interface.
The wallet will be particularly interesting to developers who are often the first to need access to these features to test their backends. However, the wallet should still be easily usable by new users alike.
The code is open-source and available at GitHub - research-ag/wallet.
We will explain all features one-by-one in a series of small tutorials. We are starting today with managing assets and, in particular, adding custom assets:
If you have any feature requests please let us know. Have fun!
8 Likes
This is really great! I did get this unsafe error from metamask:
Looks like maybe it is not using the custom domainā¦which leads to another question:
What happens with SIWE? If I try to log into another site with a different app, do I get the same wallet? Or is there something going on in the canister and my assets are tied to the canister hosting this application?
Or put another way, If I deploy the wallet code elsewhere, and log in with SIWE, will I see my assets?
Fixed it. Thanks for pointing it out. Yes, the issue was indeed as you say, that the siwe provider canister needed the custom domain. It seems that simply upgrading the provider canister was not enough to change the domain/uri in it. I now did a reinstall instead of upgrade of the provider canister and now it works.
It used to be that you always get the same principal with siwe regardless of where you log in. Itās always the principal derived from your Ethereum address. But I think siwe has evolved and introduced an option to include the frontend uri in the derivation. See Changelog for version 0.6.0 here.
What I donāt know about siwe is how to make the warning that you saw go away in both situations, when the user logs in on the custom domain and on the canister domain. It seems I can only configure one domain in the siwe provider. So for now when you go to the raw canister domain instead of wallet.ic0.info then you would get that warning again.
Here is a blog post with the instructions for managing subaccounts: ICRC-1 Wallet Tutorial: Managing Subaccounts. In particular, how to access the full 32-byte subaccount id space.
As another update, we also added TCYCLES and the legacy OGY tokens as assets.
1 Like
The wallet had ICRC-2 support for a while. But we have now upgraded it so that you can also grant allowance to a spender with a non-zero subaccount. In the ICRC-2 specification a spender can not only be a principal, it can also be a principal plus subaccount. In other words the spender is actually structurally the same as an ICRC-1 account. Hence, when creating an allowance you can now paste in an ICRC-1 account into the Spender field.
This has no application for allowances granted to other persons. But it has applications for allowances granted to canister services. Because the service can distinguish its users by the information encoded in the subaccount.
Here is the blog post with the instructions on using allowances: ICRC-1 Wallet Tutorial: Transactions and Allowances
1 Like