This thread is about the current application level IC identity crisis.
I will start by explaining the situation we are in, review it, and then offer better solutions.
Legend:
For all intents and purposes. identity = wallet = private key holder
User-owned identity
- Hardware
- Software
- Canister
There are no perfect software identities. The most user-owned one is the hardware wallet. Software wallets - if they can be updated by a third party massively within one hour with any code, one which can fetch the private keys - like extension wallets, they aren’t really user-owned, just appear as such.
User-owned canister identity (something new) - you can think of them like self deployed Internet Identity backend and frontend which serves only one user - the owner.
The most secure user-owned identity can be achieved with the Glacier Protocol - which has a 74-page manual that requires you to burn your laptop after using it for private key generation. That’s not really web3 material.
Application-owned identity
Application-owned identities use similar to the normal web paradigm. User registers and can use their registration to log in. The identity doesn’t work anywhere else but this one app. The user has to register in each application. If one application and its identity get hacked, other apps won’t be affected.
The easiest way to do it right now: Each application deploys its own Internet Identity backend and frontend (actually the frontend can be a component, not a new site)
Third-party owned identity
When a third party holds the keys or can update the software and fetch them at any moment.
The problems with these are that user assets are now controlled by 3rd party, which can use that as a platform to grow and steal the functionality from the applications which use it. Already happening with DEX & NFTs.
You can clearly see above where all the value is and why identities and wallets are getting heavily funded and growing in numbers. On the IC community side, pretty much 50% of the development goes to 3rd party wallets and identities.
In FunnelFi It matters also who owns it and what the connections do.
Internet Identity gives each application a different temporary private key. The application takes the key and has to protect it from extensions having full read/write access, supply chain attacks, injection, XSS, etc. A lot of security work is required, but still, it’s possible to achieve. If one application gets hacked, the rest won’t get affected. It also works well with games, because you don’t really want to sign every transaction on every move you make (think Chess).
Internet Identity is also governed by NNS with ICP. NNS can decide to grow II into a wallet + swap + NFT marketplace → and become a full-featured Binance-like themepark, but that is highly unlikely. It will be killing its hosted apps this way, which already pay it for computations & security.
Then we have the 3rd party identities which only give to apps signed transactions with one key. That makes them convenient for developers because currently there is no system for linking identities. One of the reasons why hackathon projects predominantly use extension wallets.
Let’s rate and order these solutions
User-empowering and decentralized ones first → third-party centralized ones last
(1) User-owned identity ← (2) Application-owned identity ← (3) NNS owned identity (Internet Identity) ← (4) some DAO owned identity frontend ← (5) browser extension identity (Plug) + privately owned database (Stoic)
All community developers working on identity solutions are now working on (4) and (5) because that’s where the money is, but it will also create a weak centralized application layer controlled by few entities. Currently, the frontend layer is at the mercy of two guys, who probably together own 70% of the keys used on the IC. And if you think that’s shocking, well - probably 90% of ETH keys are owned by one guy - the owner of Metamask. So we are going in the right direction, just need to put more effort into it.
Dfinity works on (2 - II is an open source project anyone can deploy) and (3 - NNS deployed II) and the ones working on (4) and (5) don’t like it, because it’s the better solution. They feel like the foundation is taking over their business.
The thing is - this shouldn’t be a business at all. This should be a crypto-illegal business the same way as drugs are. In the same way as drugs - it’s giving a short-term benefit while destroying the future. It’s basically making money centralizing things and racketeering small dapps, while the whole value in IC comes from decentralizing.
What we should be doing is working on (1) and (2), but these require community awareness. That’s why I am posting these articles.
Conclusion so far: The ultimate solution for users, applications, and the network as a whole
Every user deploys their own identity canister (frontend+backend) and they are the only controller. Whenever an app requires identity, the user enters a URL. The dapp connects to it on a frontend level and asks it for a temporary private key or to sign transactions. It works like a hardware wallet, but it’s on the chain and uses Webauthn. Works on mobile + desktop and doesn’t require installation of software or purchase of additional hardware. Users manually select which upgrade they want to install and it’s not auto updating. NNS is used to approve software upgrades, so nobody can racketeer apps by taking their functionality like DEX, marketplace, ads, one step closer to the user.
Now, let’s check how to get there.
We will need a Frontend-to-Frontend identity protocol (F2FI).
It will use PostMessage Window.postMessage() - Web APIs | MDN
Has 97.03% global coverage (canIuse)
It allows one website to open another in a window or iframe and talk with it securely. That’s used in Agentjs and Internet Identity. It’s also used to connect dapps to extension wallets.
NFID for example doesn’t use its own client js library, it uses Dfinity’s Agentjs. So we pretty much have some kind of protocol going on. It’s currently a spec covering one of the use cases.
II Spec here: internet-identity/ii-spec.md at main · dfinity/internet-identity · GitHub
As far as I can tell it can currently provide temporary keys, but can’t sign transactions, messages, etc.
Let’s see what the F2FI should be about:
- provide temporary keys like II
- sign message after user approval
- provide public key
- sign transactions after user approval
- sign batch transactions after user approval (Note - it’s not very user-friendly, checking digits to make sure it’s all good)
- provide advanced swap visual interface (optional, but improves security by visualizing what’s really happening inside the batch transactions). It will look something like this. The user doesn’t sign a batch of transactions but signs the whole offer (This interface has been used in games for 30 years) Basically the same in every game allows trading between parties that don’t trust each other.
It’s can be token type&standard agnostic. The backend for this is - Swapper - Swapper. Atomic swap | multi-token | multi-standard | multi-type NFT / FT
It can also supports F2FI interactions with soulbound tokens - proving to one app using one identity that you have proof of humanity or awards in another app using another identity. So there isn’t much you can’t do with a visual interface like that.
My latest project started with that mockup UI above and I didn’t know where it will lead at the time. Now in this post, all pieces get connected for the first time. I could just do it in a way to cowboy code finish the project and make something work, but I prefer fixing the problem at its root in a way that will improve the whole network.
The F2FI protocol can be used by all identity solutions. It will remove the need to install individual js libraries for every wallet/identity one adds to their app.
At some point, wallets holding soulbound tokens will also want to connect to other wallets, because transferring things is not an option.
The F2FI protocol will allow one site to use one library and interact with all identity/wallet providers and gradually transition to better more secure and decentralized solutions.
(1) User-owned identity ← (2) Application-owned identity ← (3) NNS owned identity (Internet Identity) ← (4) some DAO owned identity frontend ← (5) browser extension identity (Plug) + privately owned database (Stoic)
Currently, it looks like only I am working on this with a holistic approach. It will be great if more join so we can get it done faster.