II 2.0 is no different to II 1.0 re biometrics. The biometrics is stored on device.
If you’re referring to creating a new II 2.0 via signing in with Apple, Google or Microsoft then, as per FAQ, they only see that your Big Tech ID has an II attached to it. They know nothing else. Depending on how you set this up they might have a passkey or synced passkey. And your last concern, especially re II 2.0, is one I share!
You can use a password manager though. I’ve used II on Linux that way.
At this point, all the wallets are still on II 1.0 right?
I’ve spent years explaining to my seed investors how to use II 1.0- & keeping them up to date with voting requirements etc- do I have to contact them & explain your II 2.0 plans or will II 1.0 ALWAYS ( for the next 20yrs or so) be available?
Suppose you are new to ICP and you get II 2.0. Does this mean you can only use Caffeine and one or two others perhaps, but not NNS or OpenChat or OISY Wallet right now?
I had this last week. If it’s something that, right now, is expected to occur occasionally, with recovery after a few minutes, then a friendlier user error should be displayed. This is discouraging and scary for the average user. E.g., say, they can’t get into their OISY wallet (which is what I was trying to do).
IC aims to abstract away crypto but I doubt it can do that completely. There has to be some secure method of recovery. Right now with 2FA, you are offered a recovery path that involves saving something (e.g., recovery codes) somewhere. A seed phrase is no more complex, just more words. The main advantage with the IC ecosystem is that you shouldn’t need more than the one seed phrase or some equivalent. Then a dApp such as OISY Wallet does not require a seed phrase itself, as you just sign in with II.
In regard to the rest of crypto, the problem now is that you require multiple wallets with multiple seed phrases, quite apart from usernames and passwords.
Keeping track of multiple sets of seed phrases and securing them is user-hostile. It’s the biggest weakness of crypto.
My current solution is not to use pen and paper but to save them to named text files, encrypt them using an open source encryption program, and then back them up redundantly to multiple external drives and clouds, some of which are not Big Tech.
This is a horror show.
ii 1 needs to remain fully intact, immutable.
ill deal w/ my annoying numbers, seed phrases, pen and paper organization.
the only argument to be made is “convenience”.
Thanks for all the great questions and discussions here! I won’t be able to reply to everything directly, as most of my time is dedicated to product development. For any support needs, please visit our official support page: https://identitysupport.dfinity.org/hc/en-us
II 2.0 is backwards compatible with existing dapps using the same protocol as II 1.0. Dapps can opt-in to use II 2.0 early with AuthClient by setting the identityProvider to https://id.ai.
It should automatically show a QR code with instructions when you attempt to authenticate in II 2.0 on a new device: Continue with passkey → Use existing identity → cancel/close the browser passkey prompt.
Scanning the QR code or copying the link to an existing device and following the instructions should get you signed in on your new device. This flow was particularly implemented for users with devices across multiple ecosystems e.g. macOS and Android.
What actually is II 2.0?
Both II 1.0 and 2.0 are the same canister, the primary difference between them is the rewritten frontend in combination with some new canister methods that allow for II 2.0 functionality like Google sign in and discoverable passkeys.
Back when we started the II 2.0 project, we had similar concerns regarding the existing II user base. Therefore, the technical decision was made to not deploy another canister for II 2.0. Migrating between two canisters would a large technical challenge we’d rather avoid to begin with.
In practice this means that II 2.0 is solely a frontend rewrite, to be precise the II 1.0 & 2.0 frontends and backend implementation are actually all within a single canister.
What does upgrading actually do?
Technically speaking, upgrading an identity to II 2.0 is solely adding another passkey to the existing identity, no changes are made to the identity.
This is required since the newer discoverable passkey API used in the II 2.0 flows is incompatible with the existing non-discoverable passkeys created previously.
If access is lost to this II 2.0 passkey and there’s no additional II 2.0 passkey:
This upgrade process will remain available long term to make sure that users that haven’t visited II in a long time can still access their funds in the future.
Does II 2.0 remove any functionality from 1.0?
No, all functionality from the II 1.0 frontend is already available in the II 2.0 frontend except for seed phrases which are currently being picked up for development over the coming weeks.
Besides existing II 1.0 functionality, there’s also additional functionality:
All these features are opt-in:
Upgrade instructions are indeed shown on II 2.0 for users that haven’t upgraded yet.
As of this moment, it’s not yet possible to authenticate using II 2.0 with all dapps unfortunately. The current recommended workaround is creating an 1.0 identity and then upgrading it to 2.0 so it can be used in both 1.0 and 2.0.
The missing support for seed phrases in II 2.0 is indeed one of the primary reasons why we haven’t updated all integrations yet. Seed phrases are a crucial recovery mechanism, particularly for crypto wallets like e.g. OISY.
The good news is that we’ve picked up the implementation of seed phrases in II 2.0, expect to see ongoing development around this feature in the II upgrade proposals in the coming weeks.
Passwords managers are still a headache on Android to get configured correctly, last time I was setting up Bitwarden to test it’s support for the II 2.0 implementation, I had to dive quite far into the Bitwarden support pages to figure things out.
As mentioned in the II 2.0 support page, Bitwarden is verified to be compatible with II 2.0, so it should be possible to configure it as replacement for Google Password Manager. Hopefully the following link helps.
Proposal:
Add OAuth / OIDC support to Internet Identity.
Reason:
The current II uses a custom WebAuthn-based system, so existing OAuth libraries and mobile SDKs can’t be used.
This lowers development efficiency and causes poor UX on mobile devices.
Request:
Issue JWTs from II authentication results and provide standard OAuth endpoints (/authorize, /token, /userinfo).
Also, please provide official SDKs for iOS and Android.
This would allow developers to use existing authentication libraries and significantly lower the barrier to adopting II.
With all due respect, the moment you process you private key in your computer, with whatever encryption software, you can consider them exposed already.
This is precisely the reason I advocate Passkey. There is nothing for you to leak, even if you want to.
I am currently working on implementing support for ic-auth-client-rs for native applications, and I largely agree with this perspective.
To use II in native applications, developers currently need to set up a website serving as a proxy for WebAuthn, and users must tolerate two web pages are opened in their web browser during authentication.
While the robustness of WebAuthn is undoubtedly important, I believe having multiple options would also help expand the use cases for IC.
Yes, as I mentioned a bit further along in my somewhat lengthy post, I was able to get there eventually with some intermediate steps.
Add Bitwarden to Chrome on desktop
Sign into II 2.0 on Chrome - Google Password Manager pops up with passkey I added on phone.
Add a new passkey - Bitwarden pops up offering to save it.
Launch my default browser (Vivaldi in my case).
Sign into Caffeine with II 2.0 - Bitwarden pops up offering the passkey I added via Chrome.
We’re talking about seed phrases. Either you write them down on paper and put them in a safe in at least two locations or you save them on your device temporarily, encrypt them and store in at least two clouds. Sure, there’s a window of opportunity for a key logger to slip in before encryption, but the chance of that happening is remote.
If you have an alternative and more secure form of recovery for II 2.0, feel free to suggest one.
To nuance this point, the website proxy is there not specifically for WebAuthn but rather to enable II to identify the domain name that’s trying to authenticate since native applications don’t have a domain name.
This challenge is avoided on Android apps with Google auth and iOS apps with Apple auth due to the respective native OS APIs available. The same challenge appears when e.g. an iOS app wants to authenticate with Google and vice versa, though this has largely been simplified for developers due to respective SDKs being available that mostly handle this complexity.
At this moment we don’t have an SDK available for mobile platforms, the most I can share is an example implementation of II in React Native: GitHub - krpeacock/ic-expo-mvp: MVP example of Expo making an IC mainnet call
As I noted earlier, you can choose not to use the additional phrase; you can rely solely on the devices; you have no obligation. Just let it be an option for those who want to “take a risk.” Okay? Nothing will change for you.
and with all the respect
”with whatever encryption software, you can consider them exposed already.”
This is Bullshit. All your life can be exposed too, you know? Your device can also be stolen before you can react. A passkey isn’t more secure than private keys, so you can create hundreds of paranoid scenarios. According to your narrative, owners of Bitcoin and all cryptocurrencies are playing with fire because they operate with private keys—which can, of course, be exposed. Tell them that, and you’ll surely topple the dominoes. That’s called paranoia, man. And you’re acting like the fate of the universe depends on it. A meteorite could hit you tomorrow; you’re mortal—deal with it.
Objectively speaking, the phrase “identity recovery” is an additional security measure, not a risk. For most users, it would be risky (and foolish) not to take advantage of it.
@sea-snake @lmuntaner Thank you for the detailed answers above.
I’m still waiting for an answer on this:
Scanning with an Android device does not produce a usable link or anything that can be used for logging in (afaict). Have you tested this with the Windows / Android combination?
Seems like Windows Hello has not been set-up on your Windows device.
You should be able to create and sign into identities with your Windows device after setting up Windows Hello in system settings, passkeys aren’t available on Windows without enabling Windows Hello.
Alternatively you can use password managers like 1Password and Bitwarden to store your passkeys if you prefer an alternative to Windows Hello.
To sign in to an existing identity created on another device from Windows on II 1.0:
To sign in to an existing identity created on another device from Windows on II 2.0:
Unfortunately the browser WebAuthn APIs don’t give us any control over the options shown by the system e.g. “iPhone, iPad or Android device”. This means in practice that these systems options might work for some users to use passkeys across devices and/or ecosystems but not for all users.
Therefore, we added the “Continue from another device” flow automatically in II 2.0 when users cancel/close system passkey dialog(s).
just to be clear on my laptop that used to be one of my trusted devices where i could access nns with a pin number now MUST enable Microsoft’s 3rd party Hello garbage?