Some real-world feedback here for Internet Identity after helping Yumi with the launch of an NFT collection. These issues have likely been there since the start, but when you start to include more “general” users they become more glaring. Many of the users that were confused are IC friendlies, but not necessarily crypto-natives. We got to see some “wallet” abstractions play out where they meet the real world and really fall on their face.
Funding Interactions
The “new principal for each domain” is great for privacy and a fantastic long-term choice, but it falls flat on its face at the point of implementation. When a user has 100 ICP in their NNS wallet that they’ve signed into with II, they think they have 100 ICP in their account and are incredibly confused when they log into another app and that app tells them that they don’t have any funds. It is a “full stop” - “this thing doesn’t work” moment for most people that don’t have a deep understanding of how II works(so maybe like 100 people actually know what is going on.)
How the II team can help:
Can we have an isII(principal) : Bool query on the II canister that will let us identify if the principal is an II principal. This will let dapp devs identify that they have an II user and that they may need to give them II specific instructions. ie “We noticed you are using Internet Identity. Please click here to fund this dApp from your wallet”
We need a workflow for funding that maintains privacy. Once I know you have an II principal I’d like to able to initiate a workflow that funds my dapp in a privacy-preserving and clearly useable way. I’d like to be able to open an new window with nns.ic0.app/wallet/?to_principal={users_dapp_principal}&sub_account={subaccount}&amount={e8s}&redirect={optional_redirect_once_item_transaction_is_done&behavior={notify_opener or redirect}&source_domain={dapp_domain}.
This link would allow me to tell my nns wallet to present the user with a screen that lets them select their NNS account they want to send from, and specify if I want the screen to try to notify a parent opener(in the same way that II works now), or redirect the user to a page on my dapp.
The screen should maybe use II somehow to verify that the principal and subaccount that I’ve submitted actually belong to the dapp that is making the request.
The above would allow a dapp to 1. Sense that the user was using II and 2. Offer a funding mechanism when they want to do something that requires ICP.
I suspect there are some privacy gotchas in there somewhere, but this workflow would really help give dapp devs the ability to provide a more useable experience to their developers.
Usually dapps show a “wallet” icon with info:
This would allow them to show something more useable if they detect II like “Fund from NNS” instead of Transfer. A few words and narrative her and there can really help a user out.
I would prefer it if sites couldn’t tell which identity provider I was using, but you can probably track it anyway based on things like which button people interact with to initiate auth.
Yes, in the meantime users can use any number of wallets on the IC. With the Bitfinity wallet , you can use a single identity (even your II) across multiple websites.
Thanks a lot for the feedback. We appreciate that a lot!
To address point 1: due to the way principals are calculated, there is no way (even for II) to tell for a principal, whether it was generated by II. However, you can tell this by looking at the public key of the delegation. So if you want to be sure that a principal is an II principal you can just require that the client needs to send the delegation along with the canister call. This is safe, as the delegation cannot be used without the corresponding private key.
On the receiver side, you can then do the following checks:
Check that the delegation is valid (example here).
Check that the caller matches the delegation, i.e. caller() == Principal::self_authenticating(&delegation.pubkey)
Extract the canister id from the public key, see an example here.
Check that the canister id is indeed the II canister (rdmx6-jaaaa-aaaaa-aaadq-cai).
As for the second point:
We are unfortunately still tied up in other features (the II domain migration), but we definitely want to expand the way dapps can interact with each other. The Identity & Auth working group has multiple different approaches in the works, where the attribute sharing flow is the most fleshed out so far. We are always happy to get contributions & developer feedback there so feel free to join in and voice your opinion there as well.
(We will of course incorporate your feedback there anyway, but you could also take a more active role in shaping the upcoming standards.)
So, expect additional flows / tools for developer next year. While it is unfortunate that we are not ready yet with better solutions, we are really looking forward to improving the situation for everyone and we believe that we have some nice and effective improvements in the works.
@skilesare@paulyoung yes NFID is an option but truly maintaining privacy will require mixing services, which we won’t have for some time.
@frederikrothenberger would he be able to differentiate between an II public key vs NFID public key?
In any case Austin if the user’s authenticated with NFID (or even simply if they have one, regardless of whether they’re authenticated with it), you can ping the requestTransfer endpoint to let users fund their Origyn account from an account of their choice.
I think the point that the dapp should be able to predict the II via the login selected is a good point.
The bigger issue is the funding of the account. As sweet as NFID is we ran into a number of folks that entered through the NNS/DFINITY pathway and have their funds on the NNS wallet. Getting those to a place where the dapp can use them is the rails that need to be greased. Some kind of invoice funding flow that I described would be helpful. It looks like that is what you all have implemented in NFID and I think that is the right way to do it. Unless the NNS wallet goes away we’re going to still have these issues across dapps…really any wallet that implements its paradigm need this kind of funding mechanism.
Makes sense. Users can pay from their NNS account if they connect their II with NFID (you can see my paltry .853547 ICP in the 2nd screenshot), but of course that may not be something all your users will want to do.
Huh…I’d imagine this was the case for most casual crypto people that glance off the IC. Don’t most of the getting started tutorials point people in this direction?
