That fact that there are flaws in the TLS/SSL implementation of public key authentication does not equate to those flaws being present in the Passkey implementation of public key authentication.

So the fact that LITERALLY EVERY public key auth up to this point in history except for a very very limited few has been broken/updated isn't a sign to you? Why are you so willfully ignorant here? NO encryption method is perfect... NO Authentication method is perfect.

TLS/SSL is one implementation of public key authentication.

Good thing everything I've talked about has been about Public Key Authentication and the traits that those have! Almost like being such a thing would have common traits between them that would not change!

Passwords MUST be transmitted to the service in a form that the server accepts as valid

Just like the challenge/response must be transmitted in a way that the server accepts it as a valid answer... Platitudes like this mean nothing and show that you do not understand any of the fundamentals happening here. Public Key Encryption is fundamentally 2 entangled passwords and a challenge (random generated known) on session start. There's 0 reason that the passwords couldn't just be an actual password for the private side, and the hash the public key. You need to read up on implementation of these things.

A passkey is never transmitted and thus cannot be stolen from that transmission. They are not dependent on the security of a known to be flawed network protocol.

I literally said this so many time already it's getting sad that you are arguing so disingenuously. You don't HAVE to transport the password at all in password-based authentication. You can transport a hash(password+challenge) just like what passkeys would be doing.

I’m actually doing the opposite: Compairing the best password implementations with the worst passkey implementations. (regarding how the service implements auth, not how the user manages their auth info. Ie; what the user has no control over)

No you're not, and now I'm walking away from this discussion. I can't have discussions with people who outright lie.

The best password implementations would do what I've outlined several times now... The worst passkey implementation could simply challenge with the same or no value at all which would allow replay (gasp! like bad implementations of passwords! almost like they are basically the same!). Like YOU admitted, you can't control the site implementation. I've said it repeatedly that the best possible passkey implementation is WORSE than the best possible Password implementation. However, the worst passkey implementation is likely better than that worse password implementation. Kneecapping those of us who actually implement properly... That's dirty.

I’m also not going to discuss the merits of someone elses talking points. I didn’t even open that link.

And you've outlined none of your own. What productive communication this has been. It's literally the same parroted talking lines that every fucking one of you "passkey" fanboys spout without any functional knowledge of what happening.

Go look at how all Public Key Encryption works. TLS is sufficient to understand it. https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/

Nothing stops step 4 from being the hash of a password, step 5 being you applying your password. Literally nothing. Passkeys are not significantly different than passwords from a best implementation standpoint, and actually introduce a number of problems that passwords do not have. It's all about implementation and everyone who is lazy in implementing strong password authentication code WILL be lazy implementing PassKeys.

Others don’t care to go into that kind of detail and just stick with google/apple. To each their own.

Yeah you've already admitted that phone user's don't have a choice... and the vast majority of people's only significant interaction with the internet in a day is their phone. So where's the options for those people? Right... I've asked that like 3 times now and you've failed to answer.