Passkeys were invented by engineers with zero understanding of consumer brain

I try to be accurate when sharing information like this. Some things are fact and some things are opinions, I already tried to annotate the opinions as interpretation. Most of the information is first hand, I was a member of FIDO alliance in past, have been watching these discussions.

1. This can be subjective, Unfortunately Customer identity is not on the highest priority from security perspective, its all about ease of product use when it comes to customer identity. For customer identity, most account recovery methods still fall back to email or SMS even if you have 2FA configured. The real money lost with phishing is with enterprise identity, when some one poses as an employee. The recovery of these accounts can be managed. If a customer account gets hacked then the business is not really on the hook to make it even.

> Usability of passwords

This is the biggest point of contention as per my interpretation. The industry did a very poor job of securing their infrastructure leading the massive leaks of password databases. Instead of fixing that goal post changed, with the by introduction of PASSWORDLESS. The passwordless works just fine for enterprise identities, not the customer identity. Even for enterprises, you cannot get rid of passwords if you get into AAL concepts (guidelines provided by NIST for authenticator assurance levels)

4. I was working on WebAuthn when the term passkey was not there, I was there when the term was introduced, I saw how every one was trying to map their existing definition/understnading with the new terminology specially the part where Apple just announced them to be syncable. Enterprise companies had to actually disable the Apple Passkeys for this reason to begin with. I found it interesting to see how Yubico changed their documentation overnight, they switched every instance of WebAuthn keyword with Passkey. It took some time to settle on how to categorize discoverable credentials (where meta information about user is on the device in addition to credential) and non-discoverable credentials (hardware keys, they are limited in space so they did not store user meta information in earlier versions). Eventually google took the lead in calling the credential where private key cannot be synched as Security key and everything else as Passkey. Resident key, syncable, synched are all different bits of the WebAuthn assertion

5. Thats an interpretation of how I read things based on the overall play going on.

> Passkeys protect against phishing attacks, and you get that protection regardless of whether the credential is hardware-bound or not. That protection comes from the cryptographic binding of the credential to the domain at the time of credential creation.

The security aspect is tightly coupled with the authenticator implementation. The phishing aspect is the only default good in here, it just means that the credential is strictly tied to a particular domain, the one on which it was set, that too is highly dependent on the client (browser) doing the right thing. Additionally you have to count on the server to not get compromised as well (There is a a feature to support multiple domains).

Most importantly, when you make something this hard and complex to understand then be advised that people are going to make mistakes in implementation and leave gaps in security.

You can decide what appetite for risk you are comfortable with, but some people don't have any better option than logging in to accounts on a public computer. The industry is pushing this system as the new universal answer for authentication, it NEEDS to work in every scenario passwords do.

(...and I’m pretty sure plugging my yubikey into a locked down public terminal is not going to solve this, either.)

Technically i would think so too, but is that how it's implemented? (I legit don't know, but my feeling was always that you had to add them while they're present, especially as there's different passkeys for different sites, to do it offline do you pregenerate 100 keys for each device to assign later?)

All of the major operating systems and all of the major browsers are password managers. Apple, Google, Microsoft, and Mozilla are all password managers. They all have apps that let you access their password managers on other operating systems.

You're right that all of the major password managers like their lock in. The Credential Exchange Protocol is just barely good enough that OS vendors can say they "support" it, but tricky enough to find that ordinary users probably will never try it. (Not to mention that it doesn't even work yet on Windows or Android.)

As for attestation, the good news is that Apple always returns 0s for the attestation ID (because Apple, like you, opposes it as a side channel), and so any public site/app that insists on attestation would reject all Apple devices. This gives smaller password managers like Bitwarden sufficient cover to 0-out their attestation as well.

Some functionality is not supported via USB-C. Namely HMAC Challenge does not work via usb-c but will work via lighting port.