I’m unable to use recovery device to restore my Internet Identity accounts.
It says “This identity has more than one recovery devices, which is not expected” I have two Internet Identity accounts with a recovery phrase and my iPhone set up as recovery device. When testing account recovery on identity.ic0.app using the recovery device I get this error message on both accounts.
“This identity has more than one recovery devices, which is not expected”
On each account I only see the recovery phrase and a single recovery device listed in the recovery section.
Flow: Use existing → Lost access? → Use recovery device
I seem to get a passkey dialog instead of the error on my end. Are you perhaps using a different domain or browser? Any additional details will help me figure out what’s going on.
I’ll now also have a look at your other II account.
For II 2706070 I see 2 recovery methods registered, 1 passphrase and 1 device.
After looking into the II implementation, I see that there has been a regression in recent changes that causes this issue. I’ll prioritize a fix and keep you up to date.
For II 2688047 I only see 1 recovery phrase and 3 authentication devices registered. I don’t see a recovery device registered for this II account.
Currently, it seems one is only allowed to have a single recovery device, so there’s no way to store a backup that would work at each of those URLs. While you can associate passkeys to the same ID from different URLs, it requires you to duplicate all your passkey devices consuming two times what should be required among the eight total allowed passkeys as well. This being the case, it seems like a solution would involve allowing at least 2 recovery devices so that you can back up the account against the multiple URLs the Internet Identity (II) host is associated with. In order to allow safe backup of accounts, it would be helpful to know if there is information regarding longer-term plans for hosting IID at identity.ic0.app vs identity.internetcomputer.org or use of any other domain for the same purpose. Unfortunately, dApp developers have, in general, been forced to make a choice using a mixture of these
leading to the confusing scenario for users where they are then sometimes able and sometimes unable to login using an IID whose collection of passkeys has been associated with one of the two (or more?) domains at which IID is exposed. While this may be acceptable for short-term passkey login, it doesn’t seem acceptable for account backup to only allow a single device forcing users to try to guess which hostname is likely to remain around the longest.
Of course, at a certain level, so long as DNS with centralized authority is being used at all, there is always a risk that a human-readable hostname is mutable relative to the underlying physical set of target endpoints.
If there is an ironed out recovery approach based on the hardware recovery device that bypasses the UI it would be great to have a pointer to its documentation.
Yes a passphrase is irrelevant of the url, it works on any url.
Work is ongoing on resolving the domain constraints, recently a new web standard became available to alleviate these limitations.
To clarify, the issue of this post is a different issue where a user is unable to use their recovery device because they have a recovery phrase due to a bug within II.
In order to allow recovery devices to work across domains, at present, you’d need to actively support multiple recovery devices. Otherwise, it is actually quite dangerous to lead users to think their recovery devices would function as required and then have a hostname change result, at best, in an account recovery procedure that requires more technical skill than most users might have, or, at worst, unrecoverable accounts. This would be most likely to arise if a user had a recovery device, since that is indicated as being supported, WITHOUT a recovery phrase. Indeed there are many who would argue that is indeed the most secure scenario IF you allow and support multiple recovery devices.
I can create a separate thread if you feel it’s too convoluted to address my point in this thread; however, I think I’ve explained clearly how it relates to safely and comprehensively resolving this one above. Indeed, I suggest it would be dangerous from the perspective of robust account management and recovery to consider this issue resolved without addressing this second layer to the OPs issue.
Ah you’re referring to passkeys and domains in this regard. A change wouldn’t be an issue and would be covered by a standard like related origins request mentioned above.
A permanent domain loss on the other hand would be an issue, which indeed would require something like a technical in-depth workaround such as a local dns with trusted ssl cert setup for recovery.
As you’ve proposed, saving multiple recovery passkeys assigned to multiple domains does spread the risk a bit, but doesn’t alleviate it sadly. At this moment the only reliable recovery method not tied to DNS would be the recovery phrase.
Just to clarify, recovery methods are primarily designed as a recovery method from a user perspective instead of disaster recovery perspective (e.g. domain loss). Back in time, when II was created, this made sense when passkeys weren’t synced yet across most devices and devices could be lost.
Now with synced passkeys, the definition of recovery has changed. We’re already looking into what this means in regards of account recovery flows within II. If there are any updates or plans in this regard, they’ll be shared here on the forum.
Sounds great. Thank you for clarifying @sea-snake .
I suppose a mitigating approach at the moment would be to more clearly indicate that, at least currently, it is really quite unsafe to attempt to backup an II without a passphrase despite the fact the II creation process does not force you to generate and verify one. One of the reasons to make this clearer in the UI and/or documentation is that at least one, if not several, prominent hardware wallet merchants actively recommend against generating passphrases altogether. Some users creating IIs familiar with that recommendation might think it’s safer to exclusively have a hardware device key backup, and even infer that the II creation process itself promotes this since it doesn’t force and verify passphrase creation like most widely utilized software wallets. Of course this is never safe without multiple backups and the II UI does not currently support that as is referenced in the error that is quoted in the title of this thread. The hostname-specificity together with potential for mutable/unstable hostname with respect to the passkey and hardware device backups complicates this issue further.
In any case, it seems quite clear at present that passphrase backup for IIs is an essential and manual post-creation task for an II unless it is certain it will never need to be recovered.