> Apple and Google are putting a lot of effort in making this work well and it shows.
They're not putting in enough effort. Both platforms still have serious caveats that mean that passkeys are not ready for ordinary users and both platforms are still willing to push this technology on ordinary users before those caveats are solved. That makes me trust them less because if they tell me the technology is ready, I don't know if they're actually using me as a guinea pig or not.
The big caveat (but by no means the only one) is still that passkeys can not be imported and exported across ecosystems (and no, 1Password does not solve this problem, 1Password keys also can not be imported and exported across ecosystems).
And what we're seeing above from Amazon is that even if Apple and Google step up and allow export the ecosystem is still going to be fragmented and overcomplicated as long as the FIDO Alliance refuses to take responsibility for pushing companies to make good decisions about their implementations. The Alliance's deliberate hands-off approach to these problems is why the ecosystem is a fragmented disaster. I don't want to rely on the good will of Google, that's not good enough. These fixes have to be part of the standard itself.
> On some of these websites, the passkey is still seen as security key for 2FA instead of a “real” passkey not requiring a password at all.
This is exactly what I'm talking about, passkeys are designed to be an alternative to passwords, it is a weakness of the spec that they are being used by services as a 2FA token. That's not a positive place for the ecosystem to be, it's mixed messaging about what passkeys are supposed to be.
It makes passkeys less accessible to ordinary people if companies are not even aligned on what passkeys definitionally are supposed to be.
Agreed on the importance of passkeys "portability" (being able to import/export passkeys across ecosystems).
Edit: But don't we have the same problem with TOPT? I don't there is a standard letting us export/import TOPT keys from one system to another (like Authy, Google Authentication, Microsoft Authenticator, 1Password, Apple Keychain, etc.).
> Edit: But don't we have the same problem with TOPT
We do, and it is a problem. Google Authenticator is a good example, lacking both automatic export (at least it did last time I checked) and (until recently) lacking even backup within Google's own ecosystem. People got burned by Google Authenticator, and I think that is a contributing factor to why real 2FA didn't take off for the general public. 2FA usage is low and is mostly relegated to the tech community, ie people who are able to easily avoid the above issues.
Note that unlike passkeys, 2FA is also not intended to be a replacement for passwords. The use cases are a lot simpler and there are fewer things to be concerned about (for example, unlike with passkeys there generally isn't a need for services to support having multiple 2FA codes linked to the same account). A big part of why I'm comfortable with 2FA is that I don't have to onboard normal users, and the standard itself is so simple that I feel like I could implement it myself if I ever needed to, and unlike with passkeys there's virtually nothing any service could do to stop me.
But putting that all aside, if the idea behind passkeys is to be a replacement for passwords, they're going to need to do a lot better than TOTP did. I use 2FA, but I also notice that it is a frequent usability complaint from non-technical users and honestly from technical users too -- there was pushback when PyPi started mandating it for certain accounts. Passkeys have to be way better than 2FA if they have any hope of seeing wide adoption.
Also note that the export situation with passkeys is a lot worse than the export situation for TOTP ever was. Export for a 2FA app is usually unencrypted, you're basically just exporting a number. So while the lack of requirement to allow export was definitely a problem, the need for a standardized format (as nice as it would have been) was much lower because the format was kind of self-evident. With passkeys that's not the case; 1Password is currently holding off on export because they don't want to allow plain-text export of the keys and they want FIDO's input into how to do it. There wasn't ever a point with TOTP where implementers were saying "we can't export keys until we get instructions how to".
They're not putting in enough effort. Both platforms still have serious caveats that mean that passkeys are not ready for ordinary users and both platforms are still willing to push this technology on ordinary users before those caveats are solved. That makes me trust them less because if they tell me the technology is ready, I don't know if they're actually using me as a guinea pig or not.
The big caveat (but by no means the only one) is still that passkeys can not be imported and exported across ecosystems (and no, 1Password does not solve this problem, 1Password keys also can not be imported and exported across ecosystems).
And what we're seeing above from Amazon is that even if Apple and Google step up and allow export the ecosystem is still going to be fragmented and overcomplicated as long as the FIDO Alliance refuses to take responsibility for pushing companies to make good decisions about their implementations. The Alliance's deliberate hands-off approach to these problems is why the ecosystem is a fragmented disaster. I don't want to rely on the good will of Google, that's not good enough. These fixes have to be part of the standard itself.
> On some of these websites, the passkey is still seen as security key for 2FA instead of a “real” passkey not requiring a password at all.
This is exactly what I'm talking about, passkeys are designed to be an alternative to passwords, it is a weakness of the spec that they are being used by services as a 2FA token. That's not a positive place for the ecosystem to be, it's mixed messaging about what passkeys are supposed to be.
It makes passkeys less accessible to ordinary people if companies are not even aligned on what passkeys definitionally are supposed to be.