Cannot be phished by currently known methods. Trust me, sooner or later they will find a way. Either through specific implementation issues, workarounds etc. Remember when everyone shrugged off concerns about sms 2fa codes?
The WebAuthN standard (and corresponding browser implementations) do inject browser supplied attestation of the requesting domain, so only a horribly broken implementation would sign a request for mail.google.hackers.ru with the key provisioned for mail.google.com - the user has no input into what the browser supplies, hence its phishing resistance.
That being said, there's no end-to-end verification of the server, so any DNS-poisoning or proxy-MITM-ing of traffic that presents a certificate trusted by the browser will validly present the Passkey implementation a domain that matches a validly provisioned key, allowing session hijacking or the start of oracle attacks on the private key itself.
Also: phishing the recovery passwords to add a new device to the synched keychain is definitely a thing.
That being said, there's no end-to-end verification of the server, so any DNS-poisoning or proxy-MITM-ing of traffic that presents a certificate trusted by the browser will validly present the Passkey implementation a domain that matches a validly provisioned key, allowing session hijacking or the start of oracle attacks on the private key itself.
Also: phishing the recovery passwords to add a new device to the synched keychain is definitely a thing.