We are in the era where the average non-technical user doesn't even necessarily know what a file even is, they are used to apps managing everything with Cloud sync and "just working".

Export can be handy for "offline" backup, but in practice the thing to backup offline is the device PIN or Password Manager "master password". Especially because in practice you aren't using just one Passkey, you are using hundreds or thousands. (One per host/domain/app, at least.)

> implement functionality FIDO does not like

The KeypassXC GitHub issue wasn't "FIDO", it was one guy acting like he could make threats on behalf of FIDO, without even the full backing of his employer, much less other members of FIDO. It was bad communication to write a suggestion in the form of a threat and pretending to speak for others.

Declarative Configuration is also the thing that allows the controlling corporation to remotely wipe the phone and other such things where they own the phone more than you do.

I know not every person has the luxury of telling their employers that they will not install corporate apps on personal phones and that if their employer wants to own their phone they should pay for a separate work phone. But that is the big scenario to avoid attestation becoming more common in the wild, making sure people realize that "No work apps on personal phones" is maybe something worth striking about.

I'm sure that there are big enough fools out there, I'm just thinking there might be signs they are doing something wrong in that case.

Netflix is more incentivized to keep people paying subscriptions than they are worried about people sharing passwords or passkeys. No one "needs" Netflix, it's an entertainment service. If they are truly a bad actor with respect to Passkeys then they upset too many consumers and lose a chunk of their audience.

I generally add keys from two very different Password Managers to every site/app I use Passkeys with. Both Password Managers also sync between multiple devices I own.

Redundancy is already an option. Choice in Password Managers to use for your Passkeys is an option.

I understand that accidental denial of service fear, but the tools exist technically to deal with that fear if you wanted to try to deal with it.

Not to mention the only way to blacklist a specific app from Passkeys is to use the AAGUID from attestation which means it only applies to attestation. A few pieces of software were providing AAGUIDs by choice even when not attested and Apple helped remind them that the spec says non-attested Passkeys should always just return an Empty UUID (all zeroes) in AAGUID. The people that are going to block non-attested Passkeys might as well block all of them, including Apple consumer Passkeys.

Passkeys enforcing keys not be extracted/copyed as plaintext and that keys are per-host/domain are just following ancient SSH best practices.

Because yes the SSH world is sloppy with dangerous plaintext (or modest password encrypted) key copying and reuse. That does make it a "simpler" ecosystem, but that doesn't make it a better ecosystem.

That said, Passkeys generally are frequently copied, most of the ecosystems support multi-device sync and backup. They just aren't done in a way that provide plaintext export if you want to print a book of your Passkeys and store it in a safe deposit box or sloppily `scp` them from one machine to another.

So the "biggest providers" very much have some champions against attestation.

In theory phones and watches could implement the other direction and generate the QR codes, there's just less pressure on the ecosystems to make that easy to do so it's not there in practice today.

Passkeys largely meet 2FA requirements by themselves because they are "something you have" (its stored on a device you own) and require "something you know" (device PIN) or "something you are" (biometric unlock) to use.

A lot of the "slippery slope" confusion in the past couple of articles has been that this "cheap SSH key" approach was built on top of the same standard for "expensive hardware key" (Webauthn). This is great because it means a rich backwards compatibility story across a long history of devices and "expensive hardware key" remains an option for Passkeys. This is unfortunately confusing because Enterprises still need Webauthn for "only expensive hardware key" usage so need options in the standard like "Attestation" which specifies things like "exactly which expensive hardware key vendor was used".

People see this confusion and think it leads to a slippery slope of attestation being required "in the future", but the reality is more that attestation and things like it were required in the past and are optional now because we realize "cheap SSH keys" are good enough for most users (with some standardization and shared "branding").

The vendors could use it to enhance lock in, but for the most part the vendors all seem in agreement that the rising tide safety to float all boats of Passkeys is worth investing in making them friendly, especially to non-technical users, and to some extent try to avoid direct lock-in.