 Eiji Kitamura [X](https://twitter.com/agektmr) [GitHub](https://github.com/agektmr) [Mastodon](https://infosec.exchange/@agektmr) [Bluesky](https://bsky.app/profile/agektmr.com)
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](https://web.dev/articles/webauthn-discoverable-credentials)) 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](https://w3c.github.io/webauthn/#sctn-signal-methods)
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.
 A dialog displayed when a passkey is deleted from Google Password Manager on Chrome.
> [!NOTE]
> **Note:** Signal API does not support the opposite flow: Signaling passkeys that are available on a passkey provider to the RP server.
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.
 A dialog displayed when a passkey metadata is updated in Google Password Manager on Chrome.
> [!IMPORTANT]
> **Important:** If a user edits their username or display name in Google Password Manager, this will be respected. Even if a user changes their username or display name on the RP, that change won't be reflected in Google Password Manager.
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](https://developer.chrome.com/docs/identity/webauthn-signal-api).