I'm using passkeys in BitWarden, and they so far work everywhere, except for the Apple Developer website. That doesn't _have_ a passkey enrollment option, and instead automagically creates it in the keychain somehow.
I checked the way they are implemented in BitWarden, and it's straightforward.
BTW, the blog is disingenuous. The removal of device attestation from PassKeys was a great boon for compatibility. And the experience with resetting key storages or not having enough slots are simply bugs and/or limitations of hardware. Which was to be expected from a new technology.
> The removal of device attestation from PassKeys was a great boon for compatibility.
Did they remove attestation? The blog implies they didn't when it says: "a security key ... fail to register ... since the IDP rejected the device attestation." What they removed was a browser API that allowed the IDP to filter the available passkeys, so they could tell the user which of the available keys they would accept before they tried to enrol it.
I gather attestation is rarely used by IDP's. That makes sense - why force a low security web site like a forum to keep a list of acceptable token models. However some sites like banks and my Federal Government absolutely need guarantees on how well the secrets are managed. Without it, they will remain with their current "roll their own" solutions. Providing an API that lets their web page say "no we won't accept your North Korean made phone as an authenticator" seems perfectly reasonable to me. That would be the API that Chrome refused to implement.
Attestation is still in the standard, and some vendors support it.
However, Apple removed it from their Keychain-synced keys: https://x.com/rmondello/status/1545085197250482176 and this effectively means that most sites will be forced to deal with non-device-bound keys.
Banks can still require device-bound keys, just like they do now. But this effectively makes it impossible to sync these keys across devices. You'll have to use the same hardware token every time, and if you lose it, then you have to re-enroll the keys on every site.
> this effectively means that most sites will be forced to deal with non-device-bound keys.
Right. Because a non-device bound key means you are now trusting not just the device, but the management of those keys, how they are moved between devices, and what devices the manager of the keys allows them to be stored on. Some parties are going to better at that management than others. For example you might trust Google but not Bitwarden.
I gather from what you say attestation doesn't of a passkey doesn't include about information about who is managing it. If true, I can just generate my own passkeys, store them in plane text on my laptop and manage them with a home grown shell script and copy them to any device I please. Maybe someone can write a Firefox extension that does all that for me. Have it auto sync between my devices, put a long enough password on it, and I could replace Bitwarden with it.
Them being phishing resistant I guess means they are still an improvement on passwords, but my they are a major compromise on the original WebAuthn vision.
> If true, I can just generate my own passkeys, store them in plane text on my laptop and manage them with a home grown shell script and copy them to any device I please.
I checked the way they are implemented in BitWarden, and it's straightforward.
BTW, the blog is disingenuous. The removal of device attestation from PassKeys was a great boon for compatibility. And the experience with resetting key storages or not having enough slots are simply bugs and/or limitations of hardware. Which was to be expected from a new technology.