[throwaway41597]

I wasn't sure what your concern was, but is it that?

1 ) Hardware authenticators won't spit their root secret, almost by design.

2 ) Webauthn doesn't require that the authenticator store the list of accounts, also by design (for privacy). So if you want to switch from iPhone to Android, you have to remember all websites you used Passkey on, and go one by one hunting down the right security settings page.

[g_p]

My concern isn't either, although both are interesting discussions - 1 in particular is relevant but understandable, as this prevents you from pairing tokens so you can maintain an off-site backup you don't have to retrieve every time you make a new account.

The specific challenge here is around software webauthn for passwordless access (think using Safari to create an account on a site). In this scenario, the average user has no portable authenticator. They cannot move to a new browser - you install Chrome, but can't log in from Chrome, as only safari can do a passkey login.

Even if chrome supports an equivalent setup (their version of passkey over Google sync, for example), you can't enroll it - to enroll, you need to sign in using Safari. To enroll your new device (chrome), you need to use it. You can't get logged in on chrome to do this. The average user has no option. A tech savvy user could manually copy session cookies to steal their own session, perhaps, or use a hardware key as a "bridge".

In essence, if you sign up for something using a passkey, you won't be able to easily leave that ecosystem at all, without pretty advanced tech knowledge (using a dedicated hardware webauthn key, or stealing and porting session cookies).

My separate observation about a lack of support for hardware keys to be "paired" to support an off-site backup use-case is unrelated, but perhaps relevant for tech savvy users who want to better "own" their own identity, and link their webauthn keys together for backup use-cases. Otherwise you have to maintain a list or spreadsheet of every site you use - I have one, so I can ensure I enroll each token I have with each service!

[throwaway41597]

Thanks for your reply. I think the issue you describe is more due to the website. A website that accepts Passkeys should provide a way to enroll a competitor. In this case it could be as simple as copying a code in one browser and pasting in the other. This isn't too bad if you consider that typing a user+password pair is also annoying though more familiar. Of course, it gets near impossible if the device is dead and the user wants to switch brands without any backup. But again, websites enrolling only one authenticator and no alternative are somewhat negligent.

I think people who evangelize Webauthn need to carefully convey the risks and remind everyone that end users need backups (multiple authenticators, backup codes...). Hopefully, down the road, it will force interoperability between big manufacturers so one authenticator can authorize another for all websites in one go (this probably requires websites to have a standard way to enroll new authenticators).

> My separate observation about a lack of support for hardware keys to be "paired" to support an off-site backup

This is worrying me more. Interoperability between tech giants is bad but the sovereign solution may never get there.

[nickzana]

Passkeys do have a (partial) solution to this problem: multi-device credentials. See the videos at the bottom of [1].

Say you install an app/visit a website on your phone and register an account with a passkey. My current understanding is that on iOS 16, the passkey lives in your iCloud keychain. If you want to sign in on a Mac on Safari, you can just visit the website and the discoverable credential from your phone will appear when you try to log into the site with webauthn. The website will be able to tell that you're logging in from a new device and optionally require additional authentication.

If you want to sign in on a device that doesn't have access to your keychain, you can use your phone as an authenticator over a combination of Bluetooth and a tunnel server by scanning a QR code on that device with your phone. The site is then supposed to prompt you to register the new device with whatever its local passkey solution is.

The best source I could find for how this protocol works at a technical level is an episode of "Security. Cryptography. Whatever" on passkeys. I guess the specs aren't exactly public yet (at least since I last checked) and are only available to fido alliance members.

I've been trying to work on figuring out ways to build a "passkey manager" of sorts to live up to the potential webauthn offers with hardware-backed credentials that are also synced and backed up (to an offsite key). As far as I can tell, as mentioned in another comment, this just doesn't seem to be a priority for the fido alliance, which is a real shame.

I'm cautiously waiting to see how 1Password deals with passkeys, given that they're one of the few FIDO members with a vested interest in being cross platform, but I'm betting they'll just implement a software keystore built into their current vaults without any hardware backing.

[1] https://fidoalliance.org/multi-device-fido-credentials/