--- url: 'https://www.corbado.com/blog/webauthn-signal-api' title: 'WebAuthn Signal API: Update & Delete Passkeys on Client-Side ' description: 'Learn how the WebAuthn Signal API enables seamless passkey deletion and metadata updates (user.name, user.displayName) on client-side authenticators.' lang: 'en' author: 'Vincent Delitz' date: '2024-07-16T11:40:29.523Z' lastModified: '2026-09-09T06:01:19.712Z' keywords: 'webauthn signal api, delete passkeys on client side, update passkeys on client side, update passkeys, delete passkeys, update metadata passkey, update user.displayName, update user.name passkeys' category: 'WebAuthn Know-How' --- # WebAuthn Signal API: Update & Delete Passkeys on Client-Side ### WebAuthn Signal API: Browser & Platform Support _Last updated: November 4, 2025_ A quick overview of WebAuthn [Signal API support](https://www.corbado.com/blog/webauthn-l3-credential-manager-support) across platforms: | Platform | Web Support | Native Support | | :---------- | :---------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------- | | **Windows** | ✅ Chrome + Google Password Manager | N/A | | **macOS** | ✅ Safari 26+ (iCloud Keychain) | N/A | | **iOS** | ✅ Safari 26+ (iCloud Keychain) | ✅ iOS 26+ ([WWDC 2025 Session 279](https://developer.apple.com/videos/play/wwdc2025/279/?time=787)) | | **Android** | 🧪 Chrome 143 (Beta) | 🧪 Credential Manager Alpha ([v1.6.0-alpha05](https://developer.android.com/jetpack/androidx/releases/credentials); beta in v1.6.0-beta03) | ⚠️ **Known Issue:** Safari 26+ has a bug where the promise does not resolve properly ([WebKit Bug #298951](https://bugs.webkit.org/show_bug.cgi?id=298951)). Fix pending merge. ## Key Facts - **`signalAllAcceptedCredentials()`** is the preferred method for client-side passkey deletion, sending a complete list of valid credential IDs and removing any not included, for authenticated users only. - The Signal API has been **enabled by default since Chrome 132**, with Safari 26+ adding support via iCloud Keychain, though a known promise resolution bug (WebKit Bug #298951) remains pending fix. - **`signalCurrentUserDetails()`** updates user.name and user.displayName on client-side authenticators without creating new passkeys, resolving stale credential display issues after email or name changes. - The API is **privacy-preserving**: it returns no feedback to the relying party about whether credential updates or deletions were successfully processed by the authenticator. - **`signalUnknownCredential()`** deletes a single credential by Credential ID and is suited for unauthenticated scenarios or large-scale deployments requiring real-time credential removal. ## 1. Introduction: WebAuthn Signal API The passkey ecosystem is evolving. To facilitate change the underlying WebAuthn standard evolves fast. New features start often with a technical explainer in GitHub and then evolve into a pull request into the standard when they have been discussed sufficiently. Recently, this [pull request](https://github.com/w3c/webauthn/pull/2093) was added into the standard draft as the [WebAuthn Signal API](https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Signal-API-explainer). In this article, we will cover: - **Why is the WebAuthn Signal API needed:** Which use cases does the WebAuthn Signal API support? - **How does the WebAuthn Signal API work:** How exactly does the WebAuthn Signal API work? What are the recommendations for relying parties? At the time of writing, the WebAuthn Signal API is enabled by default since Chrome 132 and was formerly known as the Reporting API before being renamed to avoid conflicts with [another API](https://developer.mozilla.org/en-US/docs/Web/API/Reporting_API) of the same name. ## 2. Use cases of the WebAuthn Signal API The WebAuthn Signal API addresses specific use cases related to the management of passkeys on the client-side. Specifically, it helps keeping information in sync between the relying party (RP) and the [authenticators](https://www.corbado.com/glossary/authenticator) which are part of the client-side operating systems. The following important use cases exist: ### 2.1 Updating Meta-Data of Passkeys on Client-Side Authenticator When a passkey is created, it includes several pieces of information: `user.id`, `user.name` and `user.displayName`. The passkey itself is identified via the unique [Credential ID](https://www.corbado.com/blog/webauthn-user-id-userhandle). - **user.id:** is a unique identifier that represents the account to which the passkey is linked. This `user.id` is crucial because it is used for the actual matching of the passkey to the user's account. - **user.name and user.displayName:** these are meta-data used solely for display purposes in the user interface. The following illustration shows a typical, simple database structure that explains which information would usually be stored within which field: ![passkey database structure](https://www.corbado.com/website-assets/passkey_database_structure_ff43f765dd.png) It's important to understand that while `user.name` (often an email address) and `user.displayName` (a more friendly, readable name) help the user identify their account in the selection UI, **the real association between a passkey and an account is maintained through the** `user.id` and the **Credential ID**: - An account can have multiple passkeys, but each passkey is uniquely identified and matched to the account using the `user.id` - Every passkey itself has a unique [Credential ID](https://www.corbado.com/blog/webauthn-user-id-userhandle) that is generated by the [authenticator](https://www.corbado.com/glossary/authenticator) One issue arises when the `user.name`, which can be an email address, changes. Currently, there is no mechanism to update this change on the client-side [authenticator](https://www.corbado.com/glossary/authenticator) directly. The `user.name` can change for various reasons, such as when a user updates their email address. Despite this change in the account's meta-data on the server side, the old `user.name` will continue to appear in the credential selection UI, which can cause confusion for users. The workaround for this issue is to create a new passkey with the updated `user.name` and the same `user.id`, and then overwrite the existing passkey. However, this approach is inconvenient for several reasons: 1. **Redundancy**: An [authenticator](https://www.corbado.com/glossary/authenticator) can only store one passkey per `user.id` for a specific [relying party](https://www.corbado.com/glossary/relying-party) ID. This means the old passkey must be replaced with a new one to update metadata, which is an extra step. 2. **User Experience**: Users will not understand why they need to create a new passkey. That’s the reason this workaround is not in widespread use. 3. **Complexity**: Managing [passkey creation](https://www.corbado.com/blog/passkey-creation-best-practices) and replacement just to update metadata is an unnecessary complexity. Email addresses, phone numbers and other identifiers can change regularly. Without a straightforward method to update `user.name` and `user.displayName` directly on the authenticator, users may encounter a persistent issue where they see and have to select a passkey associated with their old email address. This situation undermines the seamless experience that passkeys aim to provide. The WebAuthn Signal API aims to solve this problem by allowing relying parties to report updates to the meta-data of passkeys without requiring the creation of new ones. Before we explain how to implement the Signal API we will explore the second important use case that it addresses. ### 2.2 Deleting Passkeys on the Client-Side Another crucial use case is the deletion of passkeys on the client-side authenticator. Over time, users may revoke credentials via the passkey management list or delete their accounts, and it becomes necessary to ensure that these credentials are removed from the client-side authenticator to prevent them from appearing in future credential selection UIs ([Conditional UI](https://www.corbado.com/glossary/conditional-ui) / [passkey autofill](https://www.corbado.com/blog/webauthn-conditional-ui-passkeys-autofill)). The need for this functionality arises in several scenarios: 1. **Passkey deleted via account settings**: When a credential is no longer valid, such as after a user has explicitly deleted it via account settings: ![passkey list ](https://www.corbado.com/website-assets/passkey_list_315a76814a.png) ``` From user perspective, it is difficult to understand that a deletion in their account setting, in a dialogue like the above, does not lead to the passkey being removed on this client. ``` 2. **Account Deletion**: When a user deletes their account, all associated passkeys should also be removed. 3. **Security Policies**: Relying parties may have security policies that require the revocation of credentials after periods of inactivity or due to detected security issues. Without a direct method to delete passkeys on the client-side, these outdated or invalid credentials continue to clutter the selection UI, leading to confusion. Users might see and attempt to use passkeys that are no longer valid, resulting in failed authentication attempts and a poor user experience. #### 2.2.1 What this looks like in Production PhonePe, India's largest UPI app, described exactly this problem at the [FIDO India Working Group meetup](https://www.corbado.com/blog/passkeys-india-overview) in Bengaluru in August 2026\. Their [passkey login](https://www.corbado.com/blog/passkey-login-best-practices) is live at scale and credential state drifting apart was one of the operational issues they named. Today they mark stale credentials inactive by hand. Their case is also a good reminder of what the Signal API does and does not cover, because the drift happens in two directions and only one of them is addressed here: | **Direction** | **Covered by the Signal API?** | | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | User deletes the passkey in your app, credential manager still shows it | **Yes.** The [relying party](https://www.corbado.com/glossary/relying-party) signals which credentials are still valid, so the credential manager can clean up the rest | | User deletes the passkey in the credential manager, backend still counts it | **No.** Nothing is reported back to your server. You find out when the next login fails | The second row is the one teams underestimate, and it is the one PhonePe described. The Signal API runs from the server to the client, so a client-side deletion still surfaces only as a failed login. Adopting the API cleans up the credentials your backend has already invalidated, which is the first row. It does not remove the manual work for the second row, so design the fallback path for that case rather than treating the Signal API as the fix for both directions. See this video on how to delete server-side passkeys in the Corbado Connect Management Console: [Watch on YouTube](https://www.youtube.com/watch?v=wQdQfHuthxU) ## 3. How to Implement the WebAuthn Signal API Implementing the WebAuthn Signal API involves several steps and considerations to ensure that the functionality is integrated correctly and securely. The Signal API allows relying parties (RPs) to update or [delete passkey](https://www.corbado.com/blog/how-to-delete-passkey-apple-windows-android) credentials on the client-side authenticator. This section outlines the key considerations and steps for implementation. ### 3.1 Important considerations When implementing the WebAuthn Signal API, it is crucial to keep the following considerations in mind: - **Privacy Preserving**: The WebAuthn Signal API is designed to preserve [user privacy](https://www.corbado.com/faq/ensure-gdpr-compliance-with-passkeys) as it is one of the foundations of WebAuthn. This means that there is no feedback provided to the RP about whether the requested change was processed. The API operates silently to prevent any potential leakage of information about the state of credentials. - **Authenticator Availability**: The effectiveness of the WebAuthn Signal API depends on the availability of the authenticator. This includes both physical availability and software support (e.g., browser and operating system compatibility). The browser can only perform actions if the authenticator is accessible and supports the necessary operations without needing [biometric authentication](https://www.corbado.com/blog/passkeys-biometric-authentication). - **Domain Restrictions**: The API ensures that only the [relying party](https://www.corbado.com/glossary/relying-party) associated with a specific domain can request changes to credentials related to that domain. This is a security measure to prevent unauthorized modifications by third parties. - **Credential ID as Key**: When referencing passkeys, the [Credential ID](https://www.corbado.com/blog/webauthn-user-id-userhandle) is the primary key used by the WebAuthn Signal API. This ID uniquely identifies the passkey on the client-side authenticator. The API allows RPs to change meta-data associated with passkeys or signal that certain passkeys should no longer be accessed, but only through the Credential ID. In case an authenticator does not know a specific Credential ID, it will silently ignore it. These considerations are essential for understanding the most important aspects of the WebAuthn Signal API functions correctly. ### 3.2 How Does the WebAuthn Signal API Allow to Change Metadata of Passkeys? The WebAuthn Signal API provides a streamlined mechanism for relying parties (RPs) to update the metadata associated with passkeys on client-side [authenticators](https://www.corbado.com/glossary/authenticator). This is especially important for ensuring that users see accurate and up-to-date information in the credential selection UI without having to create new passkeys unnecessarily. Here's how the API allows this to happen: **Updating Metadata with signalCurrentUserDetails(options)** The `signalCurrentUserDetails(options)` method in the Signal API is specifically designed for updating metadata of passkeys. This method allows RPs to provide the current values for `user.name` and `user.displayName`. Here’s how the process works (see also the [WebAuthn Level 3 standard](https://w3c.github.io/webauthn/#sctn-signalCurrentUserDetails)). 1. **Method Structure:** The `signalCurrentUserDetails(options)` method includes the `rp.id`, `user.id` and the updated values for `user.name` and `user.displayName`. ```javascript PublicKeyCredential.signalCurrentUserDetails({ rpId: "example.com", userId: "aabbcc", // user handle, base64url. name: "New user name", displayName: "New display name", }); ``` 2. **Updating the Local Metadata**: Look for locally (on the authenticator) available credentials that match the `rpId` and `userId`. For all matching credentials, the authenticator will update the credential's `name` and `displayName`. 3. **Privacy Preserving:** The process is designed to be privacy-preserving. The Signal API does not provide feedback to the RP about whether the updates were successfully processed, preventing any leakage of information about the state of the credentials. 4. **Consistency Across Devices:** By regularly running the `signalCurrentUserDetails(options)` methods, RPs can ensure that the metadata for passkeys remains consistent across different devices and platforms where the user may authenticate. This approach reduces the chances of outdated or incorrect information being displayed in the credential selection UI. ![google-password-manager-passkey-updated](https://www.corbado.com/website-assets/GPM_PK_updated_a1f50063d3.png) In the above screenshot, you can see how Google Chrome signals such an update to the user. WebAuthn Signal API is part of Chrome and can be tested with [Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager) on desktop. ### 3.3 How Does the WebAuthn Signal API Allow to Signal Deleted Passkeys? The WebAuthn Signal API provides mechanisms for relying parties (RPs) to signal the deletion of passkeys from client-side [authenticators](https://www.corbado.com/glossary/authenticator). This is essential for ensuring that outdated or invalid credentials do not appear in the credential selection UI, thus maintaining a streamlined and secure user experience. There are two methods to delete the passkeys locally: `signalUnknownCredential(options)` and `signalAllAcceptedCredentials)(options)`. The former can be used in situations where the user is not authenticated, while the latter can be used when the user is authenticated. Therefore, the latter one should be preferred for privacy reasons. Here's how the two methods work: #### 3.3.1 Delete Passkeys with signalUnknownCredential 1. **Method Structure:** The `signalUnknownCredential(options)` method includes the `rpId` (relying party ID) and the `credentialId` (the unique identifier of the credential to be deleted). ```javascript PublicKeyCredential.signalUnknownCredential({ rpId: "example.com", credentialId: "aabbcc", // credential id the user just tried, base64url }); ``` 2. **Calling the Method**: RPs call this method whenever they detect that a credential should be deleted. This could be immediately following an authentication attempt with an invalid credential, during account deletion or when a user revokes a credential through account settings. 3. **Handling the Method**: When the `signalUnknownCredential(options)` method is called, the client-side authenticator tries to find credentials that match `rpId` and `credentialID` specified credential for omission. Depending on the [authenticator's](https://www.corbado.com/glossary/authenticator) capabilities, the credential is removed or an authenticator-specific procedure to hide the credential in future authentication ceremonies is employed. #### 3.3.2 Delete Passkeys with signalAllAcceptedCredentials 1. **Method Structure:** The `signalAllAcceptedCredentials(options)` method includes the `rpId` (relying party ID), `userId` and a list of valid Credential Ids `allAcceptedCredentialIds` (list of unique identifiers of credentials that should be kept). ```javascript PublicKeyCredential.signalAllAcceptedCredentials({ rpId: "example.com", userId: "aabbcc", // user handle, base64url. allAcceptedCredentialIds: ["bb"], }); ``` 2. **Calling the Method**: RPs call this method whenever they detect that a credential should be deleted and signal a list of valid credentials. This method should be preferred over `signalUnknownCredential(options)` to delete credentials. 3. **Handling the Method**: When the `signalAllAcceptedCredentials(options)` method is called, the client-side authenticator matches the `rpId` and `userId`. The authenticator that looks up all local credentials that match `rpId` and `userId`. The result is compared to `allAcceptedCredentialIds`. If there are local credentials that are not in `allAcceptedCredentialIds`, then these credentials are removed locally (or hidden depending on the authenticator). 4. **Unhide Credentials**: If a credentials have been hidden only (depending on the authenticator) and are now part of `allAcceptedCredentialIds`, then these credentials will be present in future authentication ceremonies again. 5. **Useful Tips**: - When using `signalAllAcceptedCredentials(options)` it's important to note that authenticators may not always be connected at the time this method is executed. As a result, relying parties might consider running `signalAllAcceptedCredentials(options)` periodically, such as during every sign-in, to ensure that all credentials are up-to-date. - Relying parties must be cautious when specifying the list of credential IDs (`allAcceptedCredentialIds`). Credentials that are not included in this list may be hidden or removed by the authenticator, potentially irreversibly. To prevent valid credentials from being mistakenly omitted, it is crucial to ensure that the list is complete. If a valid credential ID is accidentally left out, it should be re-added to `signalAllAcceptedCredentials(options)` as soon as possible to make it visible again, assuming the authenticator supports this. - Whenever possible, authenticators should prefer temporarily hiding credentials instead of permanently removing them. This approach can help facilitate recovery if a valid credential ID was accidentally omitted by the [relying party](https://www.corbado.com/glossary/relying-party), allowing it to be restored without permanent loss. ![GPK_PK_deleted_all.png](https://www.corbado.com/website-assets/GPK_PK_deleted_all_c211cc9e0a.png) In the above screenshot, you can see how Google Chrome signals deletes. WebAuthn Signal API can be tested with [Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager) on desktop. ## 4. Recommendations To effectively implement the WebAuthn Signal API and ensure seamless synchronization of passkey metadata across client-side authenticators, consider the following recommendations: - **Watch out for WebAuthn Signal API updates and actual implementation**: Stay informed about the latest developments and updates related to the Signal API. The WebAuthn Signal API is enabled with [Google Chrome 132](https://chromestatus.com/feature/5101778518147072), followed by other browsers (e.g. [Safari announced support as well](https://github.com/WebKit/standards-positions/issues/400)). Regularly check the progress and updates on the WebAuthn Signal API to ensure your implementation aligns with the latest standards and practices. We will update this blog post as the landscape evolves. - **Start with the `signalAllAcceptedCredentials(options)` approach after every successful login**: This approach ensures that all metadata and credential IDs are updated in a single method, simplifying the process and maintaining consistency across devices and platforms and at the same time deactivates deleted or stale credentials. - **Real-time messaging with `signalUnknownCredential(options)` for large-scale deployments**: Consider using real-time messaging with the `signalUnknownCredential(options)` method in [large-scale](https://www.corbado.com/blog/introducing-passkeys-large-scale-overview) deployments or when there is a need for immediate updates. This method can enhance the efficiency and accuracy of credential management, ensuring that invalid or outdated credentials are promptly removed from the selection UI. By following these recommendations, you can implement the WebAuthn Signal API effectively once it is supporting, ensuring that passkey metadata remains up-to-date and consistent across all client-side authenticators, thereby providing a smooth and secure user experience for passkeys. ## 5. How Corbado can help The recommendation above, calling `signalAllAcceptedCredentials()` after a successful login, is easy to write down and easy to forget in the one place it matters most: the screen where a user just deleted a passkey. [Corbado Connect](https://www.corbado.com/connect) ships that call inside its passkey list component. After a deletion the list is refetched and the authenticator is handed the full set of credential IDs the server still accepts, so the entry the user removed stops showing up in the selection UI. [Video: Manage passkeys](https://www.corbado.com/videos/connect/manage-passkeys.mp4) ([See how Corbado Connect ships this](https://www.corbado.com/connect)) - **Feature detection is already handled.** The SDK checks for `signalAllAcceptedCredentials` on `PublicKeyCredential` and returns quietly when the browser does not have it, so the gaps in the support table above stay harmless. - **The Safari hang cannot block your UI.** The call is raced against a short timeout, which matters while WebKit Bug #298951 is open. - **`signalUnknownCredential` is implemented too**, keyed by [Credential ID](https://www.corbado.com/blog/webauthn-user-id-userhandle), for the unauthenticated case described above. Because the API returns no feedback to the relying party, the only way to know whether signalling reaches your users is to measure their clients. [Corbado Observe](https://www.corbado.com/observe) reports [Signal API support](https://www.corbado.com/blog/webauthn-l3-credential-manager-support) as a [client capability](https://www.corbado.com/blog/webauthn-client-capabilities) next to `conditionalGet` and `hybridTransport`, so you can see what share of your traffic is able to act on the call at all. ## 6. Conclusion The WebAuthn standard is continually evolving, becoming more feature-rich on a monthly basis. The introduction of the WebAuthn Signal API is a significant step forward in managing passkey meta-data and deletions on client-side authenticators. This API addresses the crucial use cases of keeping information in sync between relying parties (RPs) and authenticators, and ensuring that invalid or outdated passkeys are removed, thereby improving the user experience. - **Why is the Signal API needed?** The Signal API is essential for updating passkey metadata and deleting passkeys on client-side authenticators. It resolves issues related to outdated `user.name` and `user.displayName` information, which can cause confusion when credentials are presented in the selection UI. Additionally, it helps in maintaining a clean and secure credential selection interface by removing revoked or deleted passkeys. - **How does the Signal API work?** The Signal API works by allowing RPs to call methods about the current state of credentials, including updates to metadata and signaling the deletion of passkeys. These reports are processed by the client-side authenticator, ensuring that the information presented to users is accurate and up-to-date. The API is designed to be privacy-preserving and operates without providing feedback to the RP about the success of the updates. As the WebAuthn standard evolves, it benefits from the diverse interests of its participants, who push different parts of the standard forward. Keeping an eye on these developments is crucial for staying up-to-date with the latest enhancements and ensuring that implementations remain aligned with the latest best practices and standards. The WebAuthn community continues to drive innovation, making authentication more secure and user-friendly. ## Frequently Asked Questions ### What is the difference between signalUnknownCredential and signalAllAcceptedCredentials in the WebAuthn Signal API? signalAllAcceptedCredentials() accepts a full list of valid credential IDs per user and removes any local credentials not in that list. It is preferred for privacy reasons because it requires the user to be authenticated, whereas signalUnknownCredential() targets a single credential by Credential ID and is used when the user is not authenticated. ### How do I update a passkey's displayed email address without creating a new passkey? Call PublicKeyCredential.signalCurrentUserDetails() with the rpId, userId and the new name and displayName values. The client-side authenticator finds all credentials matching the rpId and userId and updates their metadata in place, eliminating the need to replace the passkey entirely. ### Why does deleting a passkey in account settings not remove it from my device? The WebAuthn standard historically had no mechanism to push credential deletions to client-side authenticators, so the passkey remains visible in the credential selection UI even after server-side deletion. The Signal API solves this by allowing relying parties to call signalAllAcceptedCredentials() or signalUnknownCredential() to remove or hide stale credentials locally. ### Which browsers and platforms currently support the WebAuthn Signal API? Chrome has supported the Signal API by default since Chrome 132 and Android Chrome 143 is in beta. Safari 26+ on macOS and iOS supports it via iCloud Keychain and iOS 26+ adds native support, though a known bug (WebKit Bug #298951) prevents promises from resolving correctly in Safari 26+ pending a fix. ### When and how often should I call signalAllAcceptedCredentials in my authentication flow? The recommendation is to call signalAllAcceptedCredentials() after every successful login to keep all credential IDs and metadata synchronized in a single operation. Because authenticators may not be connected at every execution, running it on each sign-in ensures that deleted or stale passkeys are consistently removed across devices.