I believe there is more to the problem than just laziness from the relying party side. The problem is what do you verify against? It's not as easy as in, for example, TLS handshake where browsers/HTTP clients have well-defined root CAs to verify the provided server cert against. It's easier for security keys (e.g. yubikeys) where you can just use the FIDO MDS service but there are many other uncovered use cases such as TPMs and browser/password manager generated passkeys. The current WebAuthn/passkey registration process is practically TOFU at this point which is funny since this by itself negates the entire rationale behind hardware-based phishing resistant authenticators. And since you mentioned Apple, as far as I know and I could be wrong for their newer products, it doesn't even provide real attestation statements to begin with like in Android or Windows Hello devices. The entire standard is currently practically based on TOFU "trust me bro, I am a hardware-based generated key lol"-tier registration process.
> The current WebAuthn/passkey registration process is practically TOFU at this point which is funny since this by itself negates the entire rationale behind hardware-based phishing resistant authenticators.
This is not an accurate description of the point of Fido phishing resistance. It isn't to make a bank feel happy the user has a hardware key unless you choose attestation. It is to make the user happy that if they click the key they know is hardware on the wrong site then that site can't MITM a site they intend to authenticate to.
(Stopping users from reusing the protocol for security between passwords and real hardware keys is basically just forcing the DRM for SaaS aspect of attestation on people because you can. If you aren't the kind of institution that issued real tokens to account holders then it is none of your business.)
