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

Developers internet-identity
,
1

Developer TL;DR;

Please consider switching your app to the new II domain (https://id.ai) at your earliest convenience.

Users of apps that haven’t yet switched to the new II domain by Jan 26 will automatically get the new interface, and will be prompted to upgrade their old identities. So your existing apps will continue to work even if you don’t switch by the date above.

User TL;DR; :backhand_index_pointing_down:

https://id.ai
https://id.ai1300Ă—982 50 KB

https://id.ai
https://id.ai1300Ă—982 63.8 KB

We’re announcing the upcoming deprecation of https://identity.ic0.app and https://identity.internetcomputer.org in favor of our new Internet Identity experience: https://id.ai (also known as Internet Identity 2.0).

This change represents a major step forward in usability, flexibility, and ecosystem compatibility for both users and developers.

Why id.ai? (What’s new and improved)

Internet Identity 2.0 (https://id.ai) brings several significant improvements over the legacy Internet Identity experience:

:white_check_mark: A better experience for users

  1. No more anchor numbers
    Users no longer need to remember or manage anchor numbers to sign in.

  2. More sign-in options
    In addition to passkeys, users can now sign in using:

    • Google
    • Apple
    • Microsoft

  3. Seamless upgrade from legacy II
    Users can keep their existing accounts and app relationships from legacy Internet Identity by completing a simple upgrade flow.

    • This process adds a new passkey for the id.ai domain.
    • No app accounts are lost.
    • Existing recovery phrases work as before.

  4. Numerous UX improvements
    The new product includes many usability and polish improvements compared to the legacy experience.

:technologist: Benefits for developers

  1. Compatibility with existing id.ai users
    Upgrading your app to use id.ai allows users coming from newer apps like Caffeine to access your app using their existing Internet Identity accounts, without fragmentation.

  2. Onboard web2 users
    With the additional sign-in options, your applications can reach more users with lower friction.

Guided upgrade flow for legacy users

There is now a guided flow that helps users upgrade their existing Internet Identity to id.ai.

To enable this today, applications need to set the following in their AuthClient config:

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

Your users will see the popup below:

https://id.ai/#authorize
https://id.ai/#authorize601Ă—720 46.7 KB

https://id.ai/#authorize
https://id.ai/#authorize601Ă—720 41.3 KB

With this enabled:

  • Users signing in with a legacy identity are automatically guided through the upgrade.
  • Their existing app accounts continue to work after the upgrade.

Timeline & upcoming change on legacy URLs

The Identity team will propose the following on January 23:

:alarm_clock: What this means

  • We recommend all Internet Identity users to upgrade before January 26 at https://id.ai.
  • After this point, users accessing II via legacy URLs will see the new product and will be required to go through the upgrade flow before they can continue.

Call to action for community developers

Given the timeline, we ask all community developers to:

  • Upgrade apps to use https://id.ai, see the “Guided upgrade flow” section above.
  • Report any concerns ASAP

Early feedback is critical to ensuring a smooth transition for the entire ecosystem.

If you have questions, concerns, or run into issues while testing, please reply in this thread.

Thank you for helping us make Internet Identity simpler, more powerful, and more accessible for everyone. :raising_hands:

12 Likes
2

And if Users refuse?

3
  • After this point, users accessing II via legacy URLs will see the new product and will be required to go through the upgrade flow before they can continue.

They’ll be asked to upgrade before they can continue to sign in.

Keep in mind Internet Identity is a decentralized product, this means in practice that users will be able to upgrade long term if they haven’t heard about this announcement.

As mentioned in the post:

The old domains will continue to function to serve this purpose of enabling users to upgrade long term, given that passkeys are domain bound.

1 Like
4

Hi @artega, thanks for the information.

I’m unclear on the migration process. Can I simply replace https://identity.internetcomputer.org by https://id.ai/?feature_flag_guided_upgrade=true and this URL will support authentication for both legacy and upgraded identities? Do I understand correctly?

I’m asking because I have absolutely no intention of displaying two separate “Sign in with Internet Identity” buttons in my applications.

I feel like less than two weeks notice is too short for a non-priority task. I’d prefer a bit more time (say e.g. 1 month) to include this in a proper release rather than having to deploy on mainnet a patch just for Internet Identity updates.

Particularly if the version of Internet Indentity deployed in PocketIC will also be upgraded as it will also need upgrading test suite. And btw. if yes, will it support Google authentication, or will those options be hidden in that particular environment?

2 Likes
5

Developer TL;DR;

You don’t need to change anything. Users will just get the new interface, and will be prompted to migrate their old identities. So you can keep the old idp links (e.g. https://identity.ic0.app).

Migration TL;DR; :backhand_index_pointing_down:

Screenshot 2026-01-13 at 13.27.25
Screenshot 2026-01-13 at 13.27.251300Ă—982 50 KB

Screenshot 2026-01-13 at 13.27.31
Screenshot 2026-01-13 at 13.27.311300Ă—982 63.8 KB

5 Likes
6

HI Arshavir, is this the “upgrade flow” that you refer to? Unlike what suggested in this guide, on id.ai there does not seem to be a button “Upgrade from legacy identity”.

Will it ensure that my legacy II continues to work (i) in combination with a ledger HW wallet (for NNS) and (ii) with OISY?

7

Hi - we’re currently updating the support pages; this reply from @quint above demonstrates how to reach the upgrade flow in the current UI.

8

Thanks for the TL;DR, I’ve borrowed it (almost as-is) for the top section of the post.

1 Like
9

Yes, that’s correct.

1 Like
10

Please note that it is safe not to take any actions before Jan 26.

We will update PocketIC and DFX to support the new product by default.

Excellent question. Google and Microsoft authentication will be supported for local testing; to my knowledge, Apple doesn’t support localhost-based development at this time.

11

Yes, though if you’re using the ledger HW wallet as a passkey with II, you’ll need to create a new passkey using another method during the upgrade since the ledger HW wallet does not support discoverable passkeys at this moment.

https://identitysupport.dfinity.org/hc/en-us/articles/40276570234132-Internet-Identity-upgrade-FAQ#:~:text=Confirmed%20to%20have%20issues%20with%20Internet%20Identity%202.0%3A

https://support.ledger.com/article/12350325732893-zd#:~:text=Does%20the%20Security%20Key%20app%20support%20resident%20keys%3F

Regarding using a ledger HW wallet in the NNS directly, this remains unchanged.

12

Thanks for the answers, sounds great in general!

It’s safe not to take any actions, but it’s advised to take one on Jan 26 if one cares about the UX of the upgrade, do I get it right?

In that case, that’s IMO one more reason to provide more buffer between the announcement and the “disruption” than less than two weeks.

Nice! I guess I won’t miss the announcement, but when you do so, would you mind pinging me? This way I can upgrade the internet-identity-playwright plugin accordingly.

Oh that’s cool, really curious about this. I wonder if you’re gonna mock the flow or handle the Google and Microsoft credentials in some way to avoid shipping those. Anyway, not part of this thread.

13

The Google and Microsoft OAuth 2.0 configurations have a dev and prod client configuration to isolate between those two (JWT will have a different aud claim between dev and prod).

14

Yes, though it’s not particularly about the UX, since we’ll show the guided migration flow by default for applications that didn’t make the switch themselves as mentioned in the timeline of the main post.

More importantly, we’re communicating this now to enable developers to actively communicate the switch to their users and test out the new flow with their product(s) before Jan 26.

15

Oh you gonna ship your dev credentials everywhere in the world. I see.

16

So long story short, aside from the dev environment and E2E tests, if the guided UX becomes the default, there is nothing else to do, as @quint mentionned above, aside from being aware of.

Oki doki, gotcha. Thx.

17

They’re public credentials and we don’t need the client secret for an implicit flow.

18

Quick Q which may seem stupid but worth having it crystal-clear: is it mandatory to upgrade any frontend currently serving Internet Identity as authentication method or things can be kept as-is?

A side note: the recovery key verification procedure will be nightmarish to many (pivoting between the copied phrase and the selector for correct ordering). You should consider just allowing people to cut-and-paste what they have copied, which is what you are actually testing for.

19

As mentioned in the post and discussions above, the legacy II domains will serve the new product after the 26th without any changes required by the dapp developer (backwards compatible). But nonetheless, we do highly recommend to switch to the new domain at the earliest when possible to do so as developer.

In legacy Internet Identity we saw many support cases where users failed to correctly record their recovery phrase. Some did not write it down at all, others recorded it in the wrong order or with missing words, and many stored it digitally and later lost access. Our goal is to encourage users to write down their recovery phrase on physical paper rather than storing it digitally.

We acknowledge this is less convenient for power users who trust their own storage practices. However, II primarily targets non-power users and is fully decentralized. As a result, the recovery phrase is the only way to regain access, unlike centralized products where support can help users recover access.

For this reason, we require users to confirm the full recovery phrase rather than only part of it. To keep this step fast and user friendly on mobile, we use ordered buttons instead of text input fields.

As a note for power users, on desktop you can switch once between the access methods and recovery phrase tabs to get a verification popup with text inputs instead (after closing the ordered buttons popup).

2 Likes
20

I see what you mean. It feels a bit awkward but that’s just my take. I would expect most people by default to digitally copying it, regardless. Copying it on paper does not prelude misplacement, loss or impairment (in fact, people frequently forget where the heck they left that notebook or post-it more often than not). You can do so much in terms of OpSec, unfortunately, other than educating users.