Allowing a delegation retrieved from Internet Identity on mainnet to sign messages in your local replica would remove significant hurdles for developers during local development, ci integration testing, etc. The requirement to deploy a local Internet Identity and NFID solution if you want to use those identity providers adds a lot of unnecessary complexity. On a recent project, I wasted several hours wrangling third party canisters and eventually opted not to use NFID for the time being. From what I hear, managing II has been significant hurdle for many of the Motoko Bootcamp participants over the past week as well.
I’m not deeply familiar with the technical mechanisms here, but @kpeacock has suggested that it would be as simple as making the local replica fallback to checking a signature against the mainnet public key if validation against the replica’s own key fails.
This seems to be an issue affecting IC developers of all seniority levels, and resolving it would reduce the burden for idp integration across all projects relying on II and it’s derivatives. I would love to see this prioritized, and I imagine I’m not the only one.
Could we please get a sense of the technical complexity and appetite to implement this from the local replica team? Thank you!
It has been a huge blocker during the recent Motoko Bootcamp.
The trouble (and cost) of getting more cycles that those from the faucet can be a blocker for students so mainnet should be avoided.
In the future, local development should be used as much as possible during the camp but at the same time it would be cool to be able to show students how to integrate with existing identity solutions; most of those identity solutions currently offers a poor local dev experience due to those limitations .
Hi there, this just came to my attention! sorry for the delay
We tried to make II integration as simple as possible by providing prebuilt canisters and instructions, but evidently we missed something!
Before we jump into making the local replica work with mainnet delegations – which I think may not be trivial – I’d rather understand the issue a bit better. In particular, it’s not clear to me which part of the integration is problematic:
(1) It’s not easy enough or documented to spawn II locally
(2) It’s not easy for a dapp to juggle between a local II URL and a production URL
In general I don’t think making it easy for local test setups to use the production II is a good idea; the production II would get a lot of test traffic and one-time test anchors would pile up. If indeed (1) above is the problem, then we should instead figure out why or provide e.g. https://identity-for-devs.ic0.test and we would indeed need to find a way to get external delegations to work locally. If (2) is the real problem then we need to think a bit more.
I’ve reached out to @Seb to get some feedback from the Motoko bootcamp; the only feedback I’ve had so far about installing II locally was from forum hero @peterparker however I fear that might not be representative
We have been working for a while on a toolset and platform (ICPipeline) that includes II deployment locally along with Ledger, Motoko Playground and eventually other canisters from the community … our hope is to go live in the coming weeks, and are going to kick off a Beta testing initiative next week … Looking forward to the working group today …
We discussed this in the identity working group today, thanks for that @nmattia! I appreciate the pushback with concern to security. I understand that implementing code in the IC that allows for the injection of a new root key has huge security ramifications. However couldn’t this change be limited to the local replica, without affecting mainnet code? I’m not familiar with local replica architecture, but I imagine there might be other examples of code that runs on local replicas which could/should never be run on mainnet. I’m not quite ready to retire this line of inquiry just yet!
We also discussed dfx pull as a potential solution, since it might make it trivial for any project (II, NFID, etc) to provide a local integration path that takes just a few cli commands. Let’s find the latest update and link it here.
Edit: looks like dfx pull is coming in an unreleased version of dfx DFX Updates This Week
So far dfx start runs a real replica, with some settings changed - not a differently compiled instance. While I do see the benefit of local-only code, it will also make local and mainnet environments even more different than they are already, which will make local testing less reliable.
Mainnet delegations signing localnet messages is also perhaps not a complete solution to IDP integration for local/ci development. If you need to call the IDP canister from one of your local canisters, this will fail, since they would be on different networks. Leaning more and more to this idea being a bandaid/flawed and dfx pull being the solution
While I do think dfx pull is a good solution for development with a local/ci replica, it still seems that there’s a good case to be made for the replica to be updated to fallback to the canonical IC chainkey during signature verification.
The IC chainkey is a well-known public key. Relying on it as a fallback seems like a reasonable thing to do. A general mechanism for “fetching root key” within the IC is obviously a security concern, but a strict mechanism to fall back to this one specific public key seems lower risk.
What happens when there’s an altnet, such as badlands, etc.? It seems preferable that II on mainnet could act as the identity authority instead of altnets needing to spin up their own II/IDP.
This would allow developers to integrate an IDP into their local projects with basically zero friction on the setup side. One or two dfx pull commands is pretty simple, but reducing friction (particularly for new developers) can make a big difference in developer adoption.
