Já pode entrar nos serviços da Google sem password! Saiba como usar…

cs says:

As passkeys não são enviadas nem partilhadas com a Google, a Apple, a Microsoft ou outra qualquer. As passkeys funcionam com um sistema de chave pública/chave privada que são geradas no dispositivo e apenas a chave pública (que como diz na lata é… pública) é enviada para o server para acontecer a autenticação. Um extracto da documentação da Apple:

“… Passkeys, however, work very differently. Rather than having a single, typeable string, a passkey is actually a pair of related keys. These keys are generated by your devices, securely and uniquely, for every account. One is public and is stored on the server. The other is private and stays on your devices even when signing in. The public key is not a secret. It’s just as public as your user name. The private key is what is needed to actually sign in. The server never learns what your private key is, and your devices keep it safe. When you go to sign in, the server sends your device a single-use challenge. WebAuthn allows many different challenge-response algorithms, but passkeys on Apple platforms use standard ES256. Only your private key is capable of producing a valid solution to the challenge for your account. Your device produces this solution — called a signature — locally, and only sends the solution back to the server. Your private key stays secret and only on your devices. The server then validates the solution using your public key. If the solution your device provided is valid, you’re signed in! A public key can be used to check if a solution is valid but is not able to produce a solution itself. This means the server can be sure that you have the right private key, without knowing what the private key actually is. And since the server doesn’t know any private keys, it’s a less valuable target for attackers, because there are no user credentials to leak. All of this cryptography and key protection is totally transparent and performed by the devices. Your customers never have to know”

A autenticação de um novo dispositivo usando um já acreditado é feita localmente e de forma segura, sem intervenção da cloud.
Mais uma vez citando a mesma documentação da Apple:

“Passkeys can also be used to sign in across devices in a secure, phishing-resistant manner. Here’s how that works. There are two devices here. The client, which is the device or web browser where I’m signing in, and the authenticator, which is the device which has my passkey. First, the client shows a QR code, which the authenticator scans. This QR code contains a URL that encodes a pair of single-use encryption keys. Then, the authenticator produces a Bluetooth advertisement containing routing information for a network relay server. This local exchange allows selecting a server and sharing routing information, but also serves two additional functions. It performs an out-of-band key agreement that the server can’t see, so everything going over the network is end-to-end encrypted and the server can’t read anything. It also provides a strong claim that these two devices are in physical proximity. That means a QR code sent in an email or generated on a fake website won’t work, because a remote attacker won’t be able receive the Bluetooth advertisement and complete the local exchange. So that’s the local part. Once the local exchange and key agreement have happened, the two devices connect to a relay server picked by the phone. From there, they perform a standard FIDO CTAP operation, which is encrypted using the keys from earlier, so the relay server can’t see anything that’s going on.
This whole process is performed by the device and the web browser. The website is not involved at any point in the cross-device communication. Cross-device cross-platform sign-in is a system feature that just works anywhere passkeys can be used.”

Claro que no caso da Apple a informação é armazenada na KeyChain e fica na cloud, mas está encriptada end-to-end, daí que eles não tenham acesso.

Tudo isto é baseado nos standards abertos da FIDO Alliance.