🚀 Announcement: identity.ic0.app & identity.internetcomputer.org → id.ai (Internet Identity 2.0)

It is not mandatory to make any changes.

You may keep your entire app as-is.

The suggested changes (i.e., switching to the new id.ai domain) are just a recommendation, and developers may do this either before Jan 26 or after (or decide to never make the switch for whatever reason). However, we do recommend switching, as we’ve observed that some end users associate more trust with the id.ai relative to, e.g., identity.ic0.app.

Thanks for the feedback. Please note that in id.ai, even an unverified recovery phrase is active, i.e., it can be used to recover the respective identity; the UI will just indicate that it hasn’t been verified yet.

I would argue that putting the extra effort into verifying a recovery phrase is worth it for most users, as otherwise those who write their recovery phrase by hand - which id.ai encourages - are risking not being able to recover due to a spelling mistake. Besides, I think I made about 24 clicks (the same number one would need to verify a recovery phrase) just while typing and editing this reply. :slight_smile:

:laughing:

Get your point. I’m always thinking of as less friction as possible when dealing with an UX (not the same as when you type an answer: your mind works in a different way even if answering is more complex).

Great. Will however try migrate ASAP. Right now

const identityProvider = (ENV as any).II_URL
    ? String((ENV as any).II_URL)
    : "https://identity.ic0.app/#authorize";

so I guess this changes to https://id.ai (presume the authentication handshake is now handled directly) hence

async function loginWithII(authClient: AuthClient): Promise<void> {
  const derivationOrigin =
    (ENV as any).DERIVATION_ORIGIN && String((ENV as any).DERIVATION_ORIGIN).length > 0
      ? String((ENV as any).DERIVATION_ORIGIN)
      : undefined;

  const identityProvider = (ENV as any).II_URL
    ? String((ENV as any).II_URL)
    : "https://id.ai";

  await new Promise<void>((resolve, reject) => {
    authClient.login({
      identityProvider,
      derivationOrigin,
      maxTimeToLive: DELEGATION_MAX_TTL_NS,
      onSuccess: () => resolve(),
      onError: (err) => reject(err),
    });
  });
}

While also at env level implement

export const ENV: ICPPEnv = {
   HOST: “https://ic0.app”,
   NETWORK: “ic”,
   II_URL: “https://id.ai”,
   DERIVATION_ORIGIN: “https://tuaah-oaaaa-aaaai-atxxx-yyy.icp0.io”,
}
2 Likes

If you want to show extra guidance UX for existing users that have an identity number, I’d recommend to change it to:

identityProvider: "https://id.ai/?feature_flag_guided_upgrade=true"

Feel free to try it with and without the flag to see the difference :smiley:

2 Likes

Great. Seems sensible advice.

Just implemented the changes. Migrated https://icpp.tech and it works perfectly :wink:

Is the IDENTITY_PROVIDER_DEFAULT in the @icp-sdk/auth library also scheduled to be changed to https://id.ai (or the version with a feature flag) around Jan 26?

I plan to update the default identity provider URL in ic-auth-client-rs in synchronization with the JS SDK.

I’ve upgraded my identity. On my phone now i have the old nns app and the new id.ai app. My question is am I going to have the same functionality in Id.ai as in the old nns.app, meaning the staking, voting etc… etc… or the internet identity 2.0 is only for logging in to apps?

Just wanna keep my II1.0 :slightly_smiling_face:

Hi @aterga, thanks for your guidance. With the help of @quint - and a bit of chatgpt - I sorted out the upgrade.
IN SUMMARY

  1. Go to https://id.ai/
  2. Sign in, top right of screen
  3. Select “Use another identity”
  4. Select: “Continue with passkey”
  5. Select “Upgrade” bottom right
  6. Menu appears “Upgrade your existing identity to the new experience in two steps
  7. Enter anchor number of Internet Identity 1.0, hit “Continue”
    DONE

I notice that my old 1.0 and new 2.0 now simply co-exist and I understand that they are additive, meaning 2.0 is linked to, does not replace the legacy 1.0.
NNS and OISY seem to also keep using my old 1.0 anchor only. That is fine. The well functioning of both is my current main focus to secure my assets.
Hence my remaining questions

1/ Will NNS and OISY for now continue to use the old 1.0 II only and how/when will they migrate?
2/ Since II 2.0 does not yet support Ledger HW can you guarantee that access to my NNS account secured by a Ledger HW wallet will continue to function flawlessly?

Hey folks! :waving_hand:

With everyone upgrading to Internet Identity 2.0 / id.ai, now’s a great moment to simplify your frontend auth + data fetching.

If you’re building with React, ic-reactor v3 makes login ridiculously easy thanks to createAuthHooks — it handles session restore, the II popup, agent updates, and reactive state behind the scenes. You basically just call login() when the user clicks, and everything works.

Quick Installation (important: include auth package!)

npm add @ic-reactor/react@beta @icp-sdk/core @icp-sdk/auth @tanstack/react-query
# or pnpm / yarn equivalents

Super Simple Setup

  1. Create your ClientManager (one time, e.g. in a context/provider file):
// clientManager.ts
import { ClientManager } from "@ic-reactor/core";
import { QueryClient } from "@tanstack/react-query";

export const queryClient = new QueryClient();

export const clientManager = new ClientManager({
  queryClient,
  // Optional: try the new experimental feature for automatic env detection!
  // Great for @icp-sdk toolchain / icp-cli dev servers (reads ic_env cookie)
  // ⚠️ Experimental — may have issues with localhost update calls
  // withCanisterEnv: true,
  // Or use: withProcessEnv: true  // classic dfx / env vars detection
});
  1. Generate auth hooks:
// authHooks.ts
import { createAuthHooks } from "@ic-reactor/react";
import { clientManager } from "./clientManager";

export const { useAuth, useUserPrincipal, useAgentState } = createAuthHooks(clientManager);
  1. In your component:
import { useAuth } from "./authHooks";

function LoginButton() {
  const { login, logout, isAuthenticated, identity, isAuthenticating } = useAuth();

  if (isAuthenticating) return <div>Signing in...</div>;

  if (isAuthenticated) {
    return (
      <div>
        Welcome {identity?.getPrincipal().toText().slice(0, 8)}...!
        <button onClick={logout}>Logout</button>
      </div>
    );
  }

  return (
    <button
      onClick={() => login({
        // Default to `https://id.ai` For already live apps with legacy II users:
        identityProvider: "https://id.ai/?feature_flag_guided_upgrade=true"
      })}
    >
      Login with Internet Identity
    </button>
  );
}

The useAuth() call automatically:

  • Restores existing session on mount
  • Switches to authenticated agent
  • Keeps TanStack Query in sync (invalidates on identity change)

Bonus mention: the new withCanisterEnv: true option (experimental) auto-detects your dev environment from the ic_env cookie when using modern @icp-sdk tools/icp-cli — super handy for seamless staging ↔ mainnet switching without manual host config. Just be cautious on localhost update calls for now.

Saves tons of boilerplate compared to raw actors.

Try it out during this II 2.0 wave — feedback very welcome!

:link: Full announcement & docs: [v3 Beta Announcement] IC Reactor: The "Missing" Data-Fetching Library for Internet Computer
ClientManager ref: ClientManager | IC Reactor
Auth hooks overview: createAuthHooks | IC Reactor

Happy coding & smooth upgrades! :rocket:

Is there a page online that goes through the process for users and one separate one for apps?
I’m still not clear on what I need to do as a user as the posts are usually intertwined with information about apps.

We will update the library a bit later after the 26th since we want people to explicitly switch the guided flow (not implicitly by updating a library).

Yes, when you sign into the NNS through id.ai (instead of identity.ic0.app), you’ll have the same NNS functionality as before.

They’ll also migrate at the latest on January 26th.

1 Like

PLEASE add locking and unlocking seed phrases ASAP. The flaw with ii2 is that if someone dropped their security key on the street, without even knowing their anchor number, an attacker could simply go on id.ai and hold the security key up to their device and have full access, AND RESET THE SEED PHRASE. Forcing users to upgrade to access their NNS Wallets without even having lockable seed phrases is not right, and needs to be addressed before it becomes forced on users!!!

2 Likes

Not to mention, if someone’s icloud, google, or microsoft accounts get compromised, the attacker can again instantly reset the phrase. We need a hot fix for this like the one password proposal ASAP :folded_hands:

Anchor number+seed phrase=perfect store method

Yeah, sucks that they are removing the anchor number and making it so that you can no longer lock your seed phrase (making it so that it can be reset with simple access to the account)

Anchor number are still used on backend, but hidden from users.

anyway, its a pity to remove anchor numbers and force users upgrade to II2.

When logging into my NNS wallet using II 1.0, I do not require the HW wallet, just to view all assets and even vote on neurons. The HW wallet is required when moving assets, or similar actions like disbursing etc.
My understanding is this means that I am NOT using the ledger HW wallet as passkey with II.
So is my correct path of action as follows?

  1. upgrade to II 2.0;
  2. continue using II 1.0 to log into NNS till Jan 26th, automatically switch over to 2.0 after that for NNS login;
  3. once logged into NNS, at all times interaction with HW wallet remains unchanged.

That’s indeed correct.

Sea snake will you please reply to my post about locking seed phrases? I am extremely concerned for the security of my funds as a result of the new update. Thanks.