Could do with a bit more clarity
I have a V1 identity, are there any steps we should take now in the future? Will v1 always work or do we at one point to we need to migrate to V2?
Or is V2 only for new indentites? Would we therefore need to transfer assets from V1 to V2? If so what about staked Nuerons?
V2 will support v1 identities shortly. We are working on it.
There are no differences in the applications when logging in with v1 or v2. The identification that the application receives is the same when the user authenticates with v1 or v2. Therefore, the neurons and other assets will stil be there when using v2.
Will developers be able to disable the Google integration (or any other third-party auth option in the future)? I like that v1 doesn’t rely on corporations that sell user data, and I don’t want any other option besides passkeys for my project.
It has not been ruled out to give developers that kind of control.
However, from an applications perspective, they won’t be able to see which authentication method was used. Therefore, it could be considered an implementation detail that we might not want to expose.
Same with the accounts. Applications won’t be able to tell whether different ids come from different identities or different accounts from the same identity.
This is to protect the user’s privacy.
I don’t understand, I just want to use v2 like v1 (but without identity numbers, I guess): how does that violate user privacy? I thought passkeys ensure user privacy and are preferable, but the Google alternative will be added to reach a broader audience.
However, from an applications perspective, they won’t be able to see which authentication method was used. Therefore, it could be considered an implementation detail that we might not want to expose.
How is not being able to see which auth method was used related to exposing implementation details?
Same with the accounts. Applications won’t be able to tell whether different IDs come from different identities or different accounts from the same identity.
What do you mean? How is v2 different from v1 regarding this?
how does that violate user privacy?
If we exposed the google account used to authenticate we would be exposing user data. Because Google itself is centralized, by exposing that they are either using passkey or Google, they could combine that with other data and guess some patterns.
It’s more privacy-friendly not to expose which authentication method was used.
How is not being able to see which auth method was used related to exposing implementation details?
I meant that it’s “like implementation details”. Like when you use a library, many times you don’t care how it works, you care that it works and you follow their interface.
What do you mean? How is v2 different from v1 regarding this?
2.0 introduces the concept of “account”. Try logging in a second time. There is a new screen where users can decide to continue with their “Primary account” (the default), or create new accounts.
This can be used if you want to create test accounts for applications, differentiate your personal and work accounts in a specific application, etc.
We will prepare more tutorials or explanations for this.
I guess I didn’t realize how the auth flow will change when I was writing the previous message, thanks for clarification.
My concern is about how by introducing OAuth support to II, it lowers the minimum level of security, privacy and introduces a new set of problems related to that: a user can use a Google account to authenticate to II with simple password without any additional 2FA, and even with SMS confirmation there could be man-in-the-middle vulnerability, or the Google account can be phished, etc. Google has access to information about which service you use OAuth, which info you share, what’s your IP, time of requesting OAuth info/confirmation.
I like that v1 is passkeys-only and is more secure, I’m sure some part of the developers and users also like that and some apps/services might even require some minimum level of security if they are about working with some sensitive info or important/valuable data (e.g. enterprise, government, finance, journalism, activism). OAuth increases reach for some part of the audience, but I think without adding more secure alternatives you might also lose some audience who are concerned with more security or might want to build their apps/services on Internet Computer platform. And currently I don’t see how v2 address that.
If we talking in terms of standards, there is Authenticator Assurance Levels (AAL) standard from National Institute of Standards and Technology (US department of commerce) which is widely used (e.g. by Microsoft) and according to this standard using passkeys can be 2nd level (AAL2, higher is better) if user sync passkeys e.g. with password manager or iCloud, or 3rd level (AAL3) if user doesn’t sync and every passkey is a separate device or they use a hardware key. I don’t know if you are going to add OAuth check that user uses 2FA, but if not, then OAuth lowers the minimum level of security from AAL2 to AAL1 (single-factor), and even if you add that 2FA check, synced passkeys are still more secure than OAuth with 2FA.
If I was tasked to solve the problem to provide OAuth for better reach and also provide more secure options, I would propose the following solution:
I think this solution both allows to reach a wider audience with adding support for OAuth and also provide developers/users with more secure options for authentication.
Interesting what you and other think about my thoughts
Thanks for the thoughtful response!
As I said, this is the first iteration of Internet Identity 2.0.
We took the decision to introduce Google authentication to reach a less technical audience. The technical audience can still use passkeys, they are not forced to reduce the level of security.
Regarding google tracking the users. Google will only see that users are authenticating with Internet Identity, not with which application they are being logged in later. So no data about application use will be shared there.
About allowing dapps to set the security level. As I said, we haven’t ruled it out. However, this is not something that the initial version offered either. The user was still in control of their security level. It’s true that Google wasn’t there, but still, it’s up to the users to decide to use synced or non-synced passkeys for example.
The proposed solution makes sense if we decide to give applications that kind of control. When it arrives, we’ll make some research and I’ll keep this post saved for that moment 
Thanks again! I hope I addressed your concerns.
There is a risk of loss, damage, and other issues with the equipment, as well as variables in third-party services. There is also a possibility of bankruptcy or other service variables for GOOGLE in the long run. So a security system without a private key is very insecure. My V1 has been logging in well, but suddenly I couldn’t log in for a day. Later, I used a phrase to retrieve it, which is equivalent to rebuilding the login. However, the original PASSKEY still exists, but I can never log in again. Therefore, the phrase private key must be used as the last resort for retrieval. If it’s not safe, who would use it? So please be sure to pay attention to this point.‘NOT YOU KEY, NOT YOU MONEY’ is the most fundamental cornerstone of building web3,
I have tried v2 a few times and it is very convenient. However, it only has the private key 
. The storage methods on Google Cloud or apple cloud are still not very secure. The security performance of the key wallet also adds mnemonic phrases. So when you upgrade, you can consider adding the registration method and login method while retaining the previous private key mnemonic phrases, or directly put the private key on the chain.
What are you saying? I didn’t understand a single thing of what u said it and why u said it
If you go to test the trial version of V2（ https://id.ai/ ）You will find that there are no phrases, only Google’s security measures, which means you can only rely on your device and Google. However, the device may be damaged or lost, and Google’s related services cannot be guaranteed in the long run. For example, if you haven’t logged into Google for a long time, you can be revoked. So the simplified login and multiple login methods of II are commendable, but we cannot cancel the most basic point of the web: ‘NOT YOU KEY, NOT YOU MONEY’. Is that clear? Of course, based on strong suggestions from everyone, V2 supports V1, but I hope this is not a transitional measure. This is what we are worried about. If we really cancel it casually, the security of encrypted assets will be a big issue. Think about those BTC accounts that have been dormant for more than 10 years. BTC assets can be stored for decades and trusted for security, simply because the private key serves as the last resort for recovery, allowing access to the BTC network from anywhere using any device, without relying on any third-party service.
Some II 1.0 features like seed phrases are still work in progress, they will be implemented in II 2.0.
As mentioned in the topic post:
It’s still early, so some functionality might be unfinished or missing at this stage.
Who told you that seed phrases will be removed on II v2 ?
I like the general direction, i.e no anchors/Google Integration, but I would seriously reconsider the new UI design. I think the current one is aesthetically better and more in line with the existing design language used in the official website, dashboard and NNS.
I am a developer, and I am using the current Internet Identity.
Would applications that rely on Internet Identity continue to work, or they would have to be updated to work with 1.0? This is a big issue for us because our customers would use version one to manage their ICP and ckBTC.
Are there any estimates for when would the migration happen, meaning when developers have to prepare and update / change their apps?
Overall impression, seems like a good plan to make it easier for newbies to adopt the IC, and that is good.
The main concern I have, besides the developer questions I posted before is about security.
Despite the quirky way that II 1.0 works, it has proven to be quite secure. It supports:
So please make sure these features continue in version 2.0.
Hi @josephgranata ,
Aplications don’t need to do anything, but users will have to perform a short flow to be enabled into the new flow, yes.
We are working on the migration and we hope to release it soon.
We don’t encourage applications to use the new domain id.ai until this migration is in place. We will announce it in the forum.
Internet Identity 2.0 intends to be as secure as 1.0:
I hope this answers your questions,
Don’t hesitate to reach out if you have any other question!