Wallet and identity standards: Progress towards launch

Developers
1

Problem

It is very difficult or impossible for:

  • New wallets to enter the ecosystem, as each dapp would need to integrate them individually. This makes it challenging to ask wallets like Metamask or Ledger to support connecting with ICP apps without established standards.
  • New ICP dapp developers to support all available wallets, since each wallet has a different method for connecting, requesting asset transfers, and making calls to other canisters.

Existing solutions

Artemis and connect2ic are two useful packages currently employed by some dapps. They provide simple methods for dapp developers to interact with wallets by individually wrapping each one. While these packages are valuable in the short term, a long-term approach with standardized solutions is still needed. This will allow for the scalability of new and existing wallets without placing additional burdens on toolkit package maintainers or dapp developers.

Standardized solution

  1. Standardize interactions between wallets and dapps: This will enable dapp developers to focus more on building useful features for users, rather than managing wallet integrations.
  2. Develop a comprehensive toolkit: This toolkit will abstract away the complexity of wallet interactions, allowing new wallets to be immediately usable across the ecosystem without requiring additional effort from dapp developers.

Progress

The Wallet and Identity Working Group has made a significant push over the last few months to complete the standards, of which there are 4 prioritized methods:

  1. icrc25_get_permissions: This is the initial method a developer would call to inform the user about the future actions the dapp will request. Given the complexity of permission management, this method is designed to be intentionally flexible.
  2. icrc34_get_delegation: This method will be most familiar to dapp developers who receive delegations from NFID Wallet and Internet Identity. Additionally, we have developed a secure delegation request method under the ICRC-28 proposal to protect users from malicious attacks that exploit delegations with the same principal across different dapps, preventing dapps from draining users’ funds.
  3. icrc27_get_accounts: This method may serve as an alternative to get_delegation for dapp developers who only need to check the user’s asset balances and request approvals for actions like transfers, purchases, and swaps. It will be familiar to dapp developers from other ecosystems. It can also be used after dapps request a delegation.
  4. icrc49_call_canister: This method allows dapp developers to invoke any method on any canister, making it particularly useful when users connect to dapps with a wallet address rather than a new anonymous principal, such as with Internet Identity (II).

Secondary standards priorities

  1. icrc28_get_trusted_origins: This method enables developers to securely request delegations with consistent principals across dapps, ensuring that a malicious dapp cannot drain the user’s assets.
  2. icrc39_batch_calling: This method allows developers to bundle multiple calls into a single batch, resulting in just one wallet prompt for the user to approve multiple signature requests simultaneously.
  3. icrc32_sign_challenge: This method allows developers to request signatures to prove the user is in control of the principal the dapp was given (i.e. through icrc27_get_accounts).
  4. icrc58_extend_delegation: This method allows developers to request additional targets that are not within their control to be added to a delegation chain.
  5. icrc59_shared_ecosystem_canisters: This standard exposes a list of types of canisters wallets can optionally blacklist from being added to a delegation without explicit user approval (i.e. via icrc58_extend_delegation).
3 Likes
2

Please join the second presentation on standards and toolkit progress next Tuesday June 4 at 16:00 UTC GitHub - dfinity/wg-identity-authentication: Repository of the Identity and Wallet Standards Working Group

1 Like
4

Thanks for the feedback

I made the point on X that security should always take precedent for a wallet standard. You define “flaw” not as a security issue, but a personal one in that you believe a competing marketplace could add itself as a trusted origin so they have fewer wallet approvals than your platform. I drafted ICRC-59 as a way to reframe that conversation and make this impossible while retaining the security guarantees of ICRC-28. It seems you are in favor of a standard that lets users provide an open delegation that malicious developers could use to drain users of their funds, with the only layer of protection being a “stern warning”, is that correct?

Regarding this, it’s the dapp that would request permission from the user to add an arbitrary target to the delegation. The user doesn’t request anything here.

Regarding whitelisting methods that don’t require wallet approval: what will protect users from deployed EXT canisters with malicious lock and settle methods?

6

A decent attacker would not immediately execute their attack, if they control the canister. They would slowly build trust, making users again and again confirm the consent message shown when interacting with these canister methods, losing focus. Then one day they would switch the logic on those methods to steal funds or do whatever the bad thing they wanna do.

And the same goes to any other use-case involving consent messages. You can always imagine a realistic scenario of how to execute an attack in that environment. Yes, some people will notice and save themselves, but many of them won’t. Especially if you time the attack to some crowdy rush hour event, like an airdrop or something.

I personally don’t believe that after these standards get stabilized and implemented the consent message bloat produced by it will do any good. Web3 is unlikely to reach global adoption if the user is responsible for things they are in no position to solve on their own, which is exactly how it looks when all the holes in our security model are covered with consent messages.

- Help me, I lost my money to this website! 
- Oh, you didn't know? They are a scammy website, you shouldn't have
allow them to call "icrc2_approve" on canister "ryjl3-tyaaa-aaaaa-aaaba-cai"!
- What is a canister? 
- Oh, you silly! You are not ready for crypto. It is your own fault!

Crypto is hard. Our job is to make it simplier, without any comprimise on safety. We need to seek a traditional banking grade UX (incl. safety) solving the weaknesses of traditional banking with decentralization and other web3 stuff.

By implementing to-be-stabilized identity standards, which allow sharing identities between dapps, we open doors to some attack vectors. By sticking with strictly separated identities, we prevent almost all of them.

It is better to keep identities separated, just like the II and some other wallets work now. And explore other ways of making interoperability work in this new environment, instead of downgrading to how it works everywhere else.

2 Likes
7

Just to clarify, overall I’m not a big fan of global delegations due to the large security implications.

Standards like ICRC-28 try to limit these security implications to at least canisters that the dapp controls.

Overall for most non fintech uses cases, the session delegation makes more sense. It’s not scoped to any specific canisters, but scoped per dapp instead.

Since the pros and cons between global and session delegations have been discussed in plenty detail before, the agreement back then is to make it a choice of the developer which delegation type fits their use case and standardized both.

As for vendor locked NFT asset canisters, this is rather unfortunate. Besides the delegation discussion regarding better UX flows, there’s also a bigger concern.

Building a dapp to manage an asset canister that doesn’t follow a public standard is a risk, the canister developer can decide to change the implementation at any time and without any warning.

To avoid this issue, the NFT asset canister should be standardized instead and adopted. Working around this issue in the signer standards instead is a large security cost I wouldn’t recommend.

Just to clarify the risk of global delegations and not managing targets securely:

Currently it takes less than a day to make a free NFT airdrop website that also stores the delegations and then 30 days later drains every single wallet that ever visited the website.

This is not an acceptable level of security in my opinion and something we should work towards moving away from in the WG.

1 Like
8

I understand your perspective—we should indeed strive to protect users from misunderstandings about managing their assets. However, achieving this without a service that can either provide final approval before execution or implement a rollback scheme after detecting fraud, both of which are those same centralized banking services you mentioned, seems nearly impossible. Additionally, “fraud identification” would require its own robust solution but is a much more likely near-term decentralized service that could help provide social proof of safety in addition to a wallet prompt. While zk-payments could be a potential avenue, they are still years away from practical implementation.

Assuming users retain control of their assets, which we both agree is required, the risk remains as soon as a service identifies the user’s asset address. Whether a user starts anonymously and later shares their asset address, the risk is essentially the same, albeit with added friction that could lead to user drop-off—a negative consequence in a competitive environment.

I agree that crypto is challenging, but not that our role is to act as guardians. Our responsibility is to create standards that enable the ecosystem to innovate and develop remarkable solutions. Currently, the ecosystem struggles to build DeFi, marketplaces, token-gated apps, and other applications requiring a clear understanding of asset and data ownership.

Agree here.

11

Just to clarify, the main goal behind the WG is standardizing the relying party ↔ signer communication, it’s up to the signer and relying party what and how to inform the end user (e.g. clearly indicating time). We’re primarily trying to standardize how communication works between the two, not how either should be designed and implemented.

If possible, this communication should always be as secure as possible without too much of a cost on either the relying party or the signer (e.g. manually typing over codes wouldn’t be a great spec).

So assuming you want to have global delegations as a possible feature, we all agree as far I understand that it should be scoped to a specific set of targets. I hope we can also all agree that giving out a global delegation without any user interaction wouldn’t be secure. On the other hand, giving out a session delegation doesn’t need any user interaction since it’s scoped.

ICRC-28 intention was to be able to skip the user interaction if we know absolutely certain the canister trusts the frontend, basically a backend that belongs to a specific frontend. This makes sense from an initial perspective, a user shouldn’t have to approve every action on a social platform in the signer, the platform’s frontend is calling it’s own backend.

But I do see the concerns regarding this being misused to vendor lock canisters other than backends e.g. NFT canisters to marketplaces. ICRC-58 tries to mitigate this by allowing you to request global delegation for canisters that do not trust your origin and asking the user to approve this action.

I’m not sure if this is going in the right direction or that there might be a better approach, since ICRC-58 seems to partially undo the security guarantees ICRC-28 has but at least it prevents a vendor lock.

Overall this issue is mainly coming from canisters that are both community property (e.g. NFTs) and marketplaces, here is a clear conflict of interest risk. If a canister is solely a marketplace, it’s probably more than reasonable that the corresponding frontend is more integrated than 3rd party frontends, similar to how web2 services have internal and external APIs.

So I’m not sure if the issue is actually within ICRC-28 and related standards or in the NFT with integrated marketplace standard (e.g. EXT) in question.

Keep in mind a developer in control of such a canister could possibly use other mechanisms besides global delegations to create similar vendor locks.

Maybe @skilesare has a perspective/opinion/ideas from ICRC-8 regarding this?

Regarding ICRC-28, the only idea that currently comes to mind to keep a level playing field is to ignore trusted origins from canisters that identify as community property e.g. an ICRC-7 token. This would force all dapps to have the same user experience with these canisters.

1 Like
12

I think this issue buts up against a number of crypto norms where the IC just fundamentally violates the status quo.(no commentary on if that is good or bad at the moment.)

I was thinking that the answer might be curated registries of wasm hashes where you would never (or maybe always) require individual confirmation of a delegation.(of course a rouge wallet could ignore that standard). But because IC canisters can host VMs inside of them it might not always be a guarantee of behavior.

The truth is that even a blackhole can be overridden by the NNS, so we just don’t have the kind of guarantees you need to assure a user that the canister they are interacting with will do what it says it will. It is always going to be a combination of code, controller, and config. In top of that the IC makes no real distinction between public utility, common contract(canister),and proprietary application.

The safe thing to do is to make people approve everything always and even then you could go further and track controllers, upgrade history, any config changes if we standardized that and then ultimately the user has to make an informed choice. This is very very hard in possible by world where you want scalability and ease of use.

I think there might be a solution where you have compilation subnets that pull open source code and compile it in a validated way such that audits exist that a canister admin/controller can’t alter behavior. But we have nothing like that at the moment(we suspect that azle might be able to compile some motoko contracts.)

ICRC-8 only works as a guarantee of market behavior if it is compiled on chain with open code and no back doors. It can be done, but the question is if we need to build that chicken before we have an egg of popular value that finances the work.

ICRC-8 will be nice for norm setting that the incestuous relationship between a market angle an NFT canister should be a non-starter.

Not a whole lot of answers here yet.

1 Like
15

This is an interesting point that I need to think about a bit.

When designing these standards it is effectively “our job” to makes sure the extreme is safe…or rather that the system is safe under ALL assumptions. There isn’t really room to say “oh this won’t matter if the asset size is small” if at some point the asset size could be large.

At the same time, I get the point. How do you transition dynamically, keep the user safe, and provide a seamless experience when a disjointed experience isn’t worth the safety it provides. That is a complex system and likely a wallet that solves it would do well, but there are likely as many configurations as there are users.

It may boils down to small differences between if standards should be used for interoperability and safety or if standards should be limited to interop wile safety should be a “best practices” zone.

Common sense comes into play and we’ve certainly done some things in the standards to help useability, but they also always have interop at the root.