The difference is that I can choose my password manager on iOS (and thereby pick my desired security level for password synchronization or opt out of it completely), but not my Passkey synchronization backend: iOS forces these to be stored in iCloud Keychain. (Passkeys are unavailable without iCloud Keychain [1]!)
Ideally, there would be a per-passkey UI option to opt out of synchronization at creation time.
> Security must be a balance with functionality, and this is a huge improvement over passwords.
Sure, but I'm somewhat disappointed that the WebAuthN WG basically forced this huge change of semantics (it's essentially a security vs. availability tradeoff) into relying parties without explicitly collecting their opt-in beforehand, or even providing an ergonomic way of opting out.
I must be missing something but I do not get all this hand-wringing. Don’t like the passkey options from Google or Apple? Fine! Use the hardware authenticator you absolutely already have if you’re the kind of person who has these sorts of objections.
Sure, I already do that, but why shouldn't there be a choice in on-device passkey implementations just like there is for password and HOTP/TOTP authenticators?
Your argument sounds a bit like "Don't like Safari? Just use a different OS then" in the context of allowing browser choice on iOS. There is no technical reason a Passkey provider and OS/platform should be necessarily bundled.
It would encourage competition in both functionality and security, it reduces reliance on a single account your entire digital life, it allows niche products to address special requirements in all kinds of scenarios...
> Your argument sounds a bit like "Don't like Safari? Just use a different OS then" in the context of allowing browser choice on iOS.
Except… you can just use a YubiKey. It’s closer to saying “install Firefox” than “install a different OS”.
> There is no technical reason a Passkey provider and OS/platform should be necessarily bundled.
Sure, fine. This is like V1 of every provider’s implementation. None of this was even available three months ago, I have no doubt these things are coming.
> Except… you can just use a YubiKey. It’s closer to saying “install Firefox” than “install a different OS”.
No, you're literally recommending I use a separate physical device because there is no API to achieve the same functionality that the OS provides via their bundled implementation.
> Sure, fine. This is like V1 of every provider’s implementation. None of this was even available three months ago, I have no doubt these things are coming.
On iOS, Passkeys have been available for more than half a year now. I really hope that Apple will eventually follow suit.
> No, you're literally recommending I use a separate physical device because there is no API to achieve the same functionality that the OS provides via their bundled implementation.
A $50 device that I have no doubt you already own, and that does not require you to change or modify any of your existing computing setup or habits.
If your point truly has merit, you shouldn’t need the hyperbole.
I agree there should be a way to opt out of system level ecosystem passkey sync with a big ol’ “you’re fucked if you don’t back these up somewhere” click through warning.
That's exactly what I want, ideally at a per-passkey level.
It should also be able for relying parties to express that desire (whether opt-in or opt-out by default). As it is, I think it'll just make banks and governments less likely to adopt passkeys.
That's sad, because all in all I think WebAuthN has the potential to have a very positive impact on security globally.
If a platform gave users this option per credential, and there was any visibility to that choice on the relying party side, the replying party would likely just reject the credentials they don't like outright, and tell people 'go figure out how to twiddle this setting if you want to use your phone here'.
Part of the web focus of these APIs mean that they will default to being open and user centric - features that might enable relying parties to block user choice will receive tremendous scrutiny, and proceed very slowly. Sites are expected for now to accept what the user chooses, and do additional steps as necessary to meet their needs. This means passkeys as a whole are not going to be always accepted as a MFA replacement.
Even features like hardware attestation are gated by a prompt by some browsers, because some consumer-facing websites went live with code saying "we will only support this one brand of security key". This led to some of the warnings in the document here: https://www.chromium.org/security-keys/
I can sympathize with the desire of a "footgun mode", which might even lie to the website about whether the credentials are backed up. However, I wouldn't trust something that critical to what is almost going to be a poorly maintained path through the system. Instead, I use (two) Yubikeys for such credentials.
Yeah this is fair. It blows my mind that platform players don't understand that the security posture needs to be configurable at a per-credential level. The hope would be that 3rd parties step in and provide implementations that afford these options to users, but that would require platform players to stop dragging their feet on allowing PW managers to hook in to WebAuthN challenges as a credential store/backend.
Yes, being able to choose my own password manager is indeed an important feature to me. I'm pretty sure that feature is not unique to closed platforms, though.
Ideally, there would be a per-passkey UI option to opt out of synchronization at creation time.
> Security must be a balance with functionality, and this is a huge improvement over passwords.
Sure, but I'm somewhat disappointed that the WebAuthN WG basically forced this huge change of semantics (it's essentially a security vs. availability tradeoff) into relying parties without explicitly collecting their opt-in beforehand, or even providing an ergonomic way of opting out.
[1] https://support.apple.com/guide/iphone/sign-in-with-passkeys...