Why Internet Identity returns different Principal?

Developers Programs & Applications
1

Hi recently I found the II actually returns different principal when I auth different website, but Plug and Stoic principal is static. Could anyone explain to me why?

Meanwhile, could I enable user make payment by NNS default wallet? When user auth our website by II, they will get the different principal so basically made a new account. That’s tedious to prompt users to transfer the ICP from NNS to a new II account.

2

II returns a different principal per service to make it hard to track you across services, everyone’s least favorite thing in web2. This is sensible for II as a general authentication mechanism; the thing you’re observing is NNS using II’s principal for your account. Plug stores your key offline and Stoic has its own auth mechanism that accepts II to log in, but provides its own principals.

The general pattern for accepting payments in one of these services is to, rather than have one address that you look at the sender for each payment for (since users may be sending money from anywhere, not just the NNS), instead have an address per user, with the subaccount consisting of the bytes of the II principal you know. This is, for example, how you create a canister by burning ICP: you make an ICP transfer to the cycles minting canister, under the subaccount of the bytes of the principal who will become its new controller, and then you notify the CMC of the block index that the transaction took place in. (Specifically, the first byte of the subaccount stores the principal length, followed by the principal’s bytes, followed by as many zeroes as necessary.) You can calculate the correct account-ID based on the principal they are authenticating with, and display it in the frontend.

3 Likes
3

Hello @AdamS :wave:

I’ve run into a problem where the principal identity for our dapp changes unexpectedly. We use the Internet Identity (II) to let users log in and manage their data. This happens not just in different situations but also when I run the dapp locally versus in production. Both setups use the same login URL: https://identity.ic0.app/#authorize.

Here’s What I’m Wondering:

  1. Why the Change?
  • Why does the principal id keep changing in production from time to time if it’s supposed to be the same dapp? Am I missing something from your explanation above?
  1. Local vs. Production:
  • When I run the dapp locally, does the Internet Identity service think it’s a different version from the one in production? Is that why the principal id is different?

To add to the context, in the front end dapp I’m using "@dfinity/auth-client": "^0.21.4" to authenticate and once the user is successfully logged in I use the identity to the get the principal like this:

const login = () => {
    setInProgress(true);
    authClient?.login({
      ...options.loginOptions,
      onError: (err) => {
        console.error(err);
        setInProgress(false);
      },
      onSuccess: () => {
        updateClient(authClient);
        let id = authClient.getIdentity();
        setIdentity(id);
        setPrincipal(id.getPrincipal().toString());
        setAuthService("II");
        setInProgress(false);
      },
    });
  };
4

The principal you get from internet identity depends on the domain name connecting to internet identity.

So if your run a dapp locally it probably has localhost as domain instead of e.g. example.com, as a result internet identity will see it as a different dapp.

On another note if your local running dapp interacts with a local running canister with dfx, the authenticated identity returned by internet identity won’t work. You’ll also need to run the internet identity canister locally with dfx in that case.