Worth noting that implementing FIDO2/Passkeys is more challenging than it looks both from a UX standpoint and from a threat modeling standpoint. We tried to cover some of this in a blog post, in case anybody is interested: https://www.slashid.dev/blog/passkeys-security-implementatio...
The short answer is that it's non standard and it depends on where the passkeys are stored. To be precise, the original WebAuthn standard did not account for a recovery mechanism at all and instead recommended adding multiple credentials to an account.
Practically if the passkeys are stored in your iCloud Keychain, they are automatically synced across your Apple devices and the recovery mechanism is the recovery mechanism for iCloud.
Similar consideration for Google/Chrome and other password managers.
Passkeys are definitely a leap forward in that we are shifting the bulk of the account takeover risk from the end users using weak passwords or clicking on phishing links to:
1) The server side implementation, including any mechanism for account recovery and support for multiple passkeys/auth factors
3) The wallet/keychain/password manager holding the keys (there's a lot of variance here in terms of security guarantees, see recent password managers breaches. We wrote a bit about how Apple does it: https://www.slashid.dev/blog/passkeys-deepdive/#the-technica...)
4) The authenticator itself (again, lots of variance here)
All of which are harder to compromise vs the average end-user.
There are still scenarios where the end-user could be targeted/tricked but they are fewer and harder to pull off (to name some: malware stealing the private keys and account takeovers on the password manager).
This is an area with the specs contrast with the vendors.
The WebAuthn specs recommends to register multiple passkeys/credentials per device and assume that once a credential is lost it might not be recoverable.
Apple and other vendors using keychains/wallets are effectively offering the option to delegate the recovery of the passkey to the recovery of the account with them (eg: the iCloud account).
I'm the author of the SlashID blogpost. You are right, the WebAuthn standard doesn't provide any guarantees on the authenticator storage security hence passkeys (and WebAuthn creds) can be stored in anything that speaks CTAP2.
I'm the author of the blogpost. You are spot on, Passkeys are exportable so the private key ends up both on iCloud and the Enclave/authenticator.
My understanding is that there's chatter about cross-vendor synchronization of passkeys but nothing concrete yet.
Meanwhile Apple allows people to share Passkeys via AirDrop (Settings > Passwords - select the passkey you want and click the "Share" icon to send it over Airdrop) so it should be possible with some effort to obtain the private key with something like this: https://github.com/seemoo-lab/opendrop. Haven't done extensive testing yet though, so I can't confirm.
Would love to hear if anybody knows more about how the sharing via AirDrop is implemented/protected.
Thank you! 100% agree - realistically, given their scale, the tradeoff made sense. The UI would have been fairly un-intuitive for users had they left the option to do both device-bound keys and passkeys.
We wrote a long post on Passkeys, in particular how they are implemented by Apple[0] that might be interesting.
Technically a Passkey is just a multi-device FIDO credential that is compatible with WebAuthn (which is an official W3C and FIDO spec).
However, vendors implementations of Passkeys/FIDO credentials differ quite widely. The Apple implementation of Passkeys, as an example, doesn't provide attestation information which reduces the ability to do device verification. Similarly, even though it's not technically part of Passkeys, Apple removed the possibility to create device-bound WebAuthn keys which significantly weakens the security guarantees you'd normally get with WebAuthn.
Co-founder of SlashID here (one of the companies mentioned above). I think we have exactly what you are looking for:
https://www.slashid.dev/blog/anonymous-users/
https://developer.slashid.dev/docs/access/concepts/anonymous...
Hit me up if you want to chat more: [email protected]