Published: Nov 13, 2024
Starting from Chrome 132, Chrome desktop (macOS, Windows, Linux and ChromeOS) supports the Signal API that can keep the passkeys on passkey providers consistent with public key credentials on the relying party's server.
When a passkey (a discoverable credential) is created, metadata such as a username and a display name are saved to the passkey provider (such as a password manager) along with the private key, and the public key credential is saved to the relying party's (RP's) server. Saving the username and display name helps the user to identify which passkey to sign in with, because the user is asked to select a passkey upon signing in. This is especially useful when they have more than two passkeys from different passkey providers.
However, there are a couple of cases where differences between the passkey list on the passkey provider and the credential list on the server can cause confusion.
The first case is when a user deletes a credential on the server leaving the passkey in the passkey provider untouched. The next time the user tries to sign in with the passkey, the passkey will still be presented to the user by the passkey provider. However, the attempt to sign in will fail because the server won't be able to verify with the deleted public key.
The second case is when a user updates their username or the display name on the server. The next time the user tries to sign in, the passkey in the passkey provider continues to display the old username and display name even though it's been updated on the server. Ideally they should be in sync.
Signal API
The WebAuthn Signal API allows RPs to signal existing credentials to connected passkey providers. This allows a supporting passkey provider to update or remove incorrect or revoked passkeys from its storage so that it is consistent with the server.
For example, when a user fails to sign in to an RP because the associated credential on the RP server no longer exists, the RP can use Signal API to signal that the deleted credential is no longer valid to the passkey provider, so the passkey provider can delete the associated passkey.
Another example is when a user goes to the RP's settings page and deletes the existing credential, the RP can use Signal API to signal a list of available credentials to the passkey provider, so the passkey provider can keep associated passkeys in sync.
It can also signal updated username and display name, so that passkey metadata stored for the same user can be updated.
For example, when a user updates their username or display name on the RP, the RP can use Signal API to signal the updated user information to the passkey provider, so the passkey provider can keep associated passkeys' user information in sync.
Google Password Manager on Chrome desktop implements the Signal AP. For Chrome extension based passkey providers, it's up to them whether they will reflect the signal or not.
We are planning to support Signal API on Android Chrome in the future.
To learn how to integrate the WebAuthn Signal API, read Keep the list of passkeys in sync with the server using the Signal API.