Can the existing II identity number be retained for login? At present, I think it’s very convenient and secure to log in with II identity. The suggestion is: You can add the login function and keep the original II identity number. Because there is an IDGEEK supermarket in the icp ecosystem, I also bought some neurons and five-digit II login numbers without assets there. If you cancel the original login numbers and change them again, I think it’s very incredible.
2 Likes
I just tried the new login method. It’s very convenient to log in with an iPhone, but it’s quite difficult to log in with an iPhone that’s not an iOS system. I still prefer the login method with the II number. You can choose to log in directly to the device with the number or log in with the key, which is also very convenient. I sincerely hope that the login method with II numbers will not be cancelled. Currently, there are approximately 2.8 million users with II identity numbers.
@Gianm, GRD is the DFINITY Global R&D meeting that happens on the last Wednesday every month. It is recorded and shared in YouTube a day later.
3 Likes
@sea-snake As a non-Apple and incognito user, I would also like to keep using Internet Identity v1 because I have at least 5-6 II numbers that I frequently use which would force me to have to buy a Yubikey for each one if Internet Identity v2 completely replaces v1 making everything much harder to manage compared to just entering a II number + builtin fingerprint scanner.
3 Likes
Feel like people dont understand passkeys, lmao… The II anchor number still uses passkeys. When you create an identity and u have your II anchor number, you’re creating a passkey for your current device. Then you can add more passkeys/devices.
You’re not selecting via passkey or via finger scanner. You are selecting passkey everytime. Either external device passkey(yubi key/ledger/bluetooth connection) or internal (your phone or computer)
If you have multiple IDs and they have passkeys on one device (your phone) you shouldnt need multiple yubikeys or devices… The passkeys should be on your phone, referencing different IDs.
Unless I’m wrong, V2 should work the same, you just don’t need to enter your anchor number but just select the passkey/ID.
Most of the times I use incognito and in that mode you can’t login using just your passkey:
As seen above, you’d need an Yubikey or similar USB device on Windows when using incognito. It’s a similar situation for Android.
1 Like
Can you elaborate? You technically dont need to remember your anchor but for years the default support answer if you forget your number is… sucks to be you, you’re SOL? Token blackhole ploy? 
2 Likes
That is your passkey. I think youre talking about your pin for computer… that’s not “passkey” its just a pin on your computer to unlock your passkey stored on your pc… similar to ledger with pin or your phone with pin/face id… passkey is not your pin. Pin unlocks passkey.
Your Yubikey stores your passkey. So I would imagine, you just sign in from different device for V2 (scroll up, android dont lemme screenshot the screen, but sign in via passkey, scroll up on the passkey drawer window) select device, and id imagine it would see all the IDs associated with the passkey)
You’re missing the point here @codecustard, right now with Internet Identity v1 I can login in incognito mode by just entering my II number and then using my laptop’s or Android phone’s builtin fingerprint scanner without relying on any external devices for all of my Internet Identities. With Internet Identity v2, if I want to keep managing my 5-6 Internet Identities while using incognito it would force me to buy 5-6 Yubikeys which would not only cost me quite a lot but it also be a much bigger hassle compared to just remembering 5-6 II numbers and using the same builtin fingerprint scanner for all of them.
In short, with Internet Identity v2 you can’t manage many Internet Identities using one single device like you currently can with Internet Identity v1 when you’re in incognito mode.
1 Like
You can. Maybe its a bug. Atleast on Mac, u can create multiple IDs and scan.
Technically 2.0 is an updated (rewritten) frontend for 1.0, it’s the same canister with the same existing identities. The idea is to sunset the 1.0 frontend code once 2.0 has been stabilized, considered ready and feature complete in comparison with 1.0.
I can’t give an exact date when this will be the case since this largely depends on development time and community feedback around 2.0. I do want to clarify that, existing 1.0 identities will always be able to authenticate in 2.0 one way or another. Backwards compatibility with older identities is a key requirement.
When a WebAuthn signature is made during the creation of a Passkey, additional metadata is returned, including a credential id (16+ random bytes) that identifies your passkey.
To authenticate with a Passkey using the WebAuthn API, you need to either:
- specify the credential id
- omit the credential id
The first case (specify credential id) is how the initial WebAuthn API used to solely work, which means we need to somehow look up the credential id before we can use a passkey, which means a (non-authenticated) canister call with an identity number in the case of II to receive all credential ids of a given identity.
If you somehow forgot your identity number, you could technically, loop over all identity numbers one by one and request the credential ids for each of them to find a match with your local passkey signature metadata.
Obviously this is all a rather technical exercise, which is why we instead suggest users to lookup the identity number range created around the date they created theirs and just try that whole range one by one instead.
The second case is where II 2.0 comes in, given that the WebAuthn API now also allows you to call the API without specifying the credential id, we can let the user choose which passkey they’d like to use instead.
After which we lookup the identity number by this credential id. A query method was added to make this a single call, avoiding the need to loop over every identity number to find a match.
One could argue that adding this canister method would make it easier for attackers to figure out which identity belongs to a passkey, but since this data technically needs public to begin with to be compatible with the WebAuthn API, anyone could already create an index of this data to begin with.
This is also why the identity number was never considered an addition security mechanism on top of a passkey (like a pin is on a yubikey).
Just double checked incognito mode on Android and it seems to work fine with multiple identities and identities created inside/outside of incognito mode on my end.
I’ll have a look later on Windows to see if there are some strange edge cases there.
2 Likes
Whatabout ledger. Doesnt seem to work.. FIDO app as well as Security Key app..
Thank you so much for being so clear on answering the questions.
As a community feedback point - if you can let the user of an anchor number authenticate using the identity anchor in 2.0 that way we get the best of both worlds. New users will use 2.0 whereas existing community those who want to use 1.0 numbers can still do so.
Over time we ll find out once there is enough data to if users still use anchor numbers.
If the backwards compatibility can be done in a way while preserving existing anchor numbers - PERFECT. I think lot of existing community would like that.
4 Likes
Yes, the Ledger Security Key app (as far as I’m aware that’s the recommend app by Ledger for Passkeys) only supports non discoverable passkeys at the moment.
It has an experimental option to enable support for discoverable passkeys, but that shouldn’t actually be used yet at this moment in time as far as I’m aware.
Significant efforts are being made to improve the overall ICP ecosystem support with Ledger as mentioned in the roadmap.
On another note, we made sure to verify and test that YubiKeys have discoverable passkey support and are thus fully compatible with II 2.0.
1 Like
And ledger fido u2f?
Technically speaking, I don’t understand these technologies details. I believe that over 99% of users are ordinary users. If he picks up my phone, he has no idea about my anchor number (incognito mode). How can he steal my property then? So I don’t understand why anchor can’t be a measure to ensure the safety of my property.
Besides, after reading the above comments, it seems that most users expect to keep the V1 version (maybe this is what you are doing now). I hope the Dfinity team can listen to more voices from the community. Wish you all the best. thanks a lot.
2 Likes
When II v2 comes out, if we meet a “robber”, we will definitely lose everything without saying a word. At least V1 makes the robber force us to talk.
1 Like
U2F pre-dates the FIDO2 standard and doesn’t support discoverable passkeys and likely never will since that’s one of the reasons the FIDO2 standard exists now.
- U2F was created and later renamed to CTAP1, considered legacy now
- Build on top of this specification, the CTAP2 standard was created.
- FIDO2 is an overarching term for CTAP2 + WebAuthn.
- The FIDO Alliance and W3C have deprecated U2F in favor of FIDO2
- Browsers still support CTAP1 mainly for backward compatibility, especially for older hardware security keys.
For sure for sure… but II v2 doesnt work with it. You cant register II with it, how does that apply for II created with v1 using UF2 passkeys.
2 Likes
II 1.0 doesn’t rely on discoverable passkeys and is thus compatible with the Ledger Security Key app while 2.0 isn’t compatible in comparison.
Most passkey providers support discoverable credentials by now, the Ledger HW is unfortunately an exception here, hopefully it’ll add support at some point.
1 Like