--- url: 'https://www.corbado.com/de/blog/webauthn-signal-api' title: 'WebAuthn Signal API: Passkeys clientseitig aktualisieren & löschen' description: 'Erfahren Sie, wie die WebAuthn Signal API das nahtlose Löschen von Passkeys und die Aktualisierung von Metadaten (user.name, user.displayName) auf clientseitigen Authenticatoren ermöglicht.' lang: 'de' author: 'Vincent Delitz' date: '2025-08-08T11:42:27.283Z' lastModified: '2026-08-29T06:01:57.412Z' keywords: 'webauthn signal api, passkeys clientseitig löschen, passkeys clientseitig aktualisieren, passkeys aktualisieren, passkeys löschen, passkey metadaten aktualisieren, user.displayName aktualisieren, user.name passkeys aktualisieren' category: 'WebAuthn Know-How' --- # WebAuthn Signal API: Passkeys clientseitig aktualisieren & löschen ### WebAuthn Signal API: Browser- & Plattform-Support _Zuletzt aktualisiert: 4. November 2025_ Hier ein kurzer Überblick über die Unterstützung der [WebAuthn Signal API](https://www.corbado.com/blog/webauthn-signal-api) auf verschiedenen Plattformen: | Plattform | Web-Support | Nativer 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) | ⚠️ **Bekanntes Problem:** [Safari](https://www.corbado.com/de/blog/digital-credentials-api) 26+ hat einen Bug, bei dem das Promise nicht korrekt aufgelöst wird ([WebKit Bug #298951](https://bugs.webkit.org/show_bug.cgi?id=298951)). Ein Fix steht noch aus. ## 1. Einleitung: WebAuthn Signal API Das Passkey-Ökosystem entwickelt sich rasant weiter. Um diesen Wandel zu ermöglichen, wird auch der zugrunde liegende [WebAuthn-Standard](https://www.corbado.com/de/blog/webauthn-server-implementierung) ständig angepasst. Neue Funktionen beginnen oft als technischer "Explainer" auf GitHub und werden dann zu einem Pull Request für den Standard, sobald sie ausreichend diskutiert wurden. Kürzlich wurde dieser [Pull Request](https://github.com/w3c/webauthn/pull/2093) als [WebAuthn Signal API](https://www.corbado.com/blog/webauthn-signal-api) in den Standard-Entwurf aufgenommen. In diesem Artikel behandeln wir: - **Warum wird die WebAuthn Signal API benötigt:** Welche Anwendungsfälle unterstützt die [WebAuthn Signal API](https://www.corbado.com/blog/webauthn-signal-api)? - **Wie funktioniert die WebAuthn Signal API:** Wie genau arbeitet die API? Was sind die Empfehlungen für Relying Parties? Zum Zeitpunkt dieses Artikels ist die WebAuthn Signal API standardmäßig ab [Chrome](https://www.corbado.com/de/blog/digital-credentials-api) 132 aktiviert. Früher war sie als "Reporting API" bekannt, wurde aber umbenannt, um Konflikte mit einer [anderen API](https://developer.mozilla.org/en-US/docs/Web/API/Reporting_API) gleichen Namens zu vermeiden. ## 2. Anwendungsfälle der WebAuthn Signal API Die WebAuthn Signal API adressiert spezifische Anwendungsfälle im Zusammenhang mit der Verwaltung von Passkeys auf der Client-Seite. Konkret hilft sie dabei, Informationen zwischen der [Relying Party](https://www.corbado.com/glossary/relying-party) (RP) und den Authenticators, die Teil der clientseitigen Betriebssysteme sind, synchron zu halten. Es gibt folgende wichtige Anwendungsfälle: ### 2.1 Aktualisierung von Metadaten der Passkeys auf dem clientseitigen Authenticator Wenn ein Passkey erstellt wird, enthält er verschiedene Informationen: `user.id`, `user.name` und `user.displayName`. Der Passkey selbst wird über die eindeutige Credential ID identifiziert. - **user.id:** ist eine eindeutige Kennung, die das Konto repräsentiert, mit dem der Passkey verknüpft ist. Diese `user.id` ist entscheidend, da sie für den eigentlichen Abgleich des Passkeys mit dem Benutzerkonto verwendet wird. - **user.name und user.displayName:** Dies sind Metadaten, die ausschließlich zu Anzeigezwecken in der Benutzeroberfläche verwendet werden. Die folgende Grafik zeigt eine typische, einfache Datenbankstruktur und erklärt, welche Informationen normalerweise in welchem Feld gespeichert werden: ![Passkey Datenbankstruktur](https://www.corbado.com/website-assets/passkey_database_structure_ff43f765dd.png) Es ist wichtig zu verstehen, dass `user.name` (oft eine E-Mail-Adresse) und `user.displayName` (ein freundlicherer, lesbarer Name) dem Benutzer zwar helfen, sein Konto in der Auswahl-UI zu identifizieren, **die eigentliche Verknüpfung zwischen einem Passkey und einem Konto jedoch über die** `user.id` und die **Credential ID** erfolgt: - Ein Konto kann mehrere Passkeys haben, aber jeder Passkey wird über die `user.id` eindeutig identifiziert und dem Konto zugeordnet. - Jeder Passkey selbst hat eine einzigartige [Credential ID](https://www.corbado.com/blog/webauthn-user-id-userhandle), die vom [Authenticator](https://www.corbado.com/glossary/authenticator) generiert wird. Ein Problem entsteht, wenn sich der `user.name`, der beispielsweise eine E-Mail-Adresse sein kann, ändert. Derzeit gibt es keinen Mechanismus, um diese Änderung direkt auf dem clientseitigen [Authenticator](https://www.corbado.com/glossary/authenticator) zu aktualisieren. Der `user.name` kann sich aus verschiedenen Gründen ändern, etwa wenn ein Benutzer seine E-Mail-Adresse aktualisiert. Trotz dieser Änderung der Konto-Metadaten auf der Server-Seite wird der alte `user.name` weiterhin in der Credential-Auswahl-UI angezeigt, was bei Benutzern zu Verwirrung führen kann. Der Workaround für dieses Problem besteht darin, einen neuen Passkey mit dem aktualisierten `user.name` und derselben `user.id` zu erstellen und den bestehenden Passkey zu überschreiben. Dieser Ansatz ist jedoch aus mehreren Gründen unpraktisch: 1. **Redundanz:** Ein [Authenticator](https://www.corbado.com/glossary/authenticator) kann nur einen Passkey pro `user.id` für eine spezifische [Relying Party](https://www.corbado.com/glossary/relying-party) ID speichern. Das bedeutet, der alte Passkey muss durch einen neuen ersetzt werden, um Metadaten zu aktualisieren – ein zusätzlicher Schritt. 2. **User Experience (UX):** Benutzer verstehen oft nicht, warum sie einen neuen Passkey erstellen müssen. Deshalb ist dieser Workaround nicht weit verbreitet. 3. **Komplexität:** Die Verwaltung von [Passkey-Erstellung](https://www.corbado.com/de/blog/passkey-erstellung-optimieren) und -Austausch nur zur Aktualisierung von Metadaten ist unnötig komplex. E-Mail-Adressen, Telefonnummern und andere Identifikatoren können sich regelmäßig ändern. Ohne eine einfache Methode, `user.name` und `user.displayName` direkt auf dem Authenticator zu aktualisieren, stoßen Benutzer auf das dauerhafte Problem, dass sie einen Passkey sehen und auswählen müssen, der mit ihrer alten E-Mail-Adresse verknüpft ist. Diese Situation untergräbt die nahtlose Erfahrung, die Passkeys eigentlich bieten sollen. Die WebAuthn Signal API zielt darauf ab, dieses Problem zu lösen, indem sie Relying Parties ermöglicht, Updates an den Metadaten von Passkeys zu melden, ohne dass neue erstellt werden müssen. Bevor wir die [Implementierung](https://www.corbado.com/de/blog/passkeys-cheat-sheet) der Signal API erklären, schauen wir uns den zweiten wichtigen Anwendungsfall an. ### 2.2 Löschen von Passkeys auf der Client-Seite Ein weiterer entscheidender Anwendungsfall ist das Löschen von Passkeys auf dem clientseitigen Authenticator. Im Laufe der Zeit können Benutzer Anmeldeinformationen über ihre Passkey-Verwaltungsliste widerrufen oder ihre Konten löschen. Es muss sichergestellt werden, dass diese Anmeldeinformationen auch vom clientseitigen Authenticator entfernt werden, damit sie nicht in zukünftigen Auswahl-UIs (Conditional UI / [Passkey Autofill](https://www.corbado.com/blog/webauthn-conditional-ui-passkeys-autofill)) erscheinen. Die Notwendigkeit für diese Funktion ergibt sich in mehreren Szenarien: 1. **Passkey über Kontoeinstellungen gelöscht:** Wenn ein Credential nicht mehr gültig ist, z. B. nachdem ein Benutzer es explizit über die Kontoeinstellungen gelöscht hat: ![Passkey Liste](https://www.corbado.com/website-assets/passkey_list_315a76814a.png) ``` Aus Benutzersicht ist schwer verständlich, warum eine Löschung in den Kontoeinstellungen (wie im obigen Dialog) nicht dazu führt, dass der Passkey auch auf diesem Gerät entfernt wird. ``` 2. **Kontolöschung:** Wenn ein Benutzer sein Konto löscht, sollten auch alle zugehörigen Passkeys entfernt werden. 3. **Sicherheitsrichtlinien:** Relying Parties haben möglicherweise Sicherheitsrichtlinien, die den Widerruf von Credentials nach Inaktivitätsphasen oder aufgrund erkannter Sicherheitsprobleme erfordern. Ohne eine direkte Methode zum Löschen von Passkeys auf der Client-Seite überfluten diese veralteten oder ungültigen Credentials weiterhin die Auswahl-UI, was zu Verwirrung führt. Benutzer sehen möglicherweise Passkeys, die nicht mehr gültig sind, und versuchen, diese zu verwenden, was zu fehlgeschlagenen Authentifizierungsversuchen und einer schlechten UX führt. Seht euch dieses Video an, um zu erfahren, wie man serverseitige Passkeys in der Corbado Connect Management Console löscht: [Watch on YouTube](https://www.youtube.com/watch?v=wQdQfHuthxU) ## 3. So implementiert ihr die WebAuthn Signal API Die [Implementierung](https://www.corbado.com/de/blog/passkeys-cheat-sheet) der WebAuthn Signal API umfasst mehrere Schritte und Überlegungen, um sicherzustellen, dass die Funktionalität korrekt und sicher integriert wird. Die Signal API ermöglicht es Relying Parties (RPs), Passkey-Credentials auf dem clientseitigen Authenticator zu aktualisieren oder zu löschen. Dieser Abschnitt beschreibt die wichtigsten Überlegungen und Schritte zur [Implementierung](https://www.corbado.com/de/blog/passkeys-cheat-sheet). ### 3.1 Wichtige Überlegungen Bei der Implementierung der WebAuthn Signal API solltet ihr folgende Punkte beachten: - **Datenschutzfreundlich (Privacy Preserving):** Die WebAuthn Signal API ist darauf ausgelegt, die Privatsphäre der Nutzer zu wahren, da dies eines der Fundamente von WebAuthn ist. Das bedeutet, dass die RP kein Feedback darüber erhält, ob die angeforderte Änderung verarbeitet wurde. Die API arbeitet still im Hintergrund, um potenzielle Informationslecks über den Status von Credentials zu verhindern. - **Verfügbarkeit des Authenticators:** Die Wirksamkeit der WebAuthn Signal API hängt von der Verfügbarkeit des Authenticators ab. Dies umfasst sowohl die physische Verfügbarkeit als auch die Softwareunterstützung (z. B. Browser- und Betriebssystemkompatibilität). Der Browser kann Aktionen nur durchführen, wenn der Authenticator zugänglich ist und die erforderlichen Operationen ohne Notwendigkeit einer biometrischen [Authentifizierung](https://www.corbado.com/de/blog/passkey-fallback-recovery) unterstützt. - **Domain-Beschränkungen:** Die API stellt sicher, dass nur die [Relying Party](https://www.corbado.com/glossary/relying-party), die mit einer bestimmten Domain verbunden ist, Änderungen an Credentials für diese Domain anfordern kann. Dies ist eine Sicherheitsmaßnahme, um unbefugte Änderungen durch Dritte zu verhindern. - **Credential ID als Schlüssel:** Wenn auf Passkeys Bezug genommen wird, ist die [Credential ID](https://www.corbado.com/blog/webauthn-user-id-userhandle) der Primärschlüssel, den die WebAuthn Signal API verwendet. Diese ID identifiziert den Passkey auf dem clientseitigen Authenticator eindeutig. Die API erlaubt RPs, Metadaten von Passkeys zu ändern oder zu signalisieren, dass bestimmte Passkeys nicht mehr verwendet werden sollen, jedoch nur über die [Credential ID](https://www.corbado.com/blog/webauthn-user-id-userhandle). Falls ein Authenticator eine spezifische Credential ID nicht kennt, wird er die Anfrage stillschweigend ignorieren. Diese Überlegungen sind essenziell, um die wichtigsten Aspekte der Funktionsweise der WebAuthn Signal API zu verstehen. ### 3.2 Wie lassen sich mit der WebAuthn Signal API Metadaten ändern? Die WebAuthn Signal API bietet einen optimierten Mechanismus für Relying Parties (RPs), um die mit Passkeys verknüpften Metadaten auf clientseitigen Authenticators zu aktualisieren. Dies ist besonders wichtig, um sicherzustellen, dass Benutzer genaue und aktuelle Informationen in der Credential-Auswahl-UI sehen, ohne unnötig neue Passkeys erstellen zu müssen. So ermöglicht die API dies: **Metadaten aktualisieren mit signalCurrentUserDetails(options)** Die Methode `signalCurrentUserDetails(options)` der Signal API ist speziell für die Aktualisierung von Passkey-Metadaten konzipiert. Diese Methode erlaubt RPs, die aktuellen Werte für `user.name` und `user.displayName` bereitzustellen. So funktioniert der Prozess (siehe auch den [WebAuthn Level 3 Standard](https://w3c.github.io/webauthn/#sctn-signalCurrentUserDetails)): 1. **Struktur der Methode:** Die Methode `signalCurrentUserDetails(options)` enthält die `rp.id`, `user.id` und die aktualisierten Werte für `user.name` und `user.displayName`. ```javascript PublicKeyCredential.signalCurrentUserDetails({ rpId: "example.com", userId: "aabbcc", // User-Handle, base64url. name: "New user name", displayName: "New display name", }); ``` 2. **Aktualisierung der lokalen Metadaten:** Es wird nach lokal (auf dem Authenticator) verfügbaren Credentials gesucht, die zur `rpId` und `userId` passen. Für alle übereinstimmenden Credentials aktualisiert der Authenticator `name` und `displayName`. 3. **Datenschutz:** Der Prozess ist datenschutzfreundlich gestaltet. Die Signal API gibt der RP keine Rückmeldung darüber, ob die Updates erfolgreich verarbeitet wurden, um Informationslecks über den Status der Credentials zu vermeiden. 4. **Konsistenz über Geräte hinweg:** Durch regelmäßiges Ausführen der Methode `signalCurrentUserDetails(options)` können RPs sicherstellen, dass die Metadaten für Passkeys auf verschiedenen Geräten und Plattformen, auf denen sich der Benutzer authentifiziert, konsistent bleiben. Dieser Ansatz reduziert die Wahrscheinlichkeit, dass veraltete oder falsche Informationen in der Credential-Auswahl-UI angezeigt werden. ![Google Password Manager Passkey Update](https://www.corbado.com/website-assets/GPM_PK_updated_a1f50063d3.png) Im obigen Screenshot seht ihr, wie Google [Chrome](https://www.corbado.com/de/blog/digital-credentials-api) ein solches Update dem Benutzer signalisiert. Die WebAuthn Signal API ist Teil von [Chrome](https://www.corbado.com/de/blog/digital-credentials-api) und kann mit dem [Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager) auf dem Desktop getestet werden. ### 3.3 Wie lassen sich mit der WebAuthn Signal API gelöschte Passkeys signalisieren? Die WebAuthn Signal API bietet Mechanismen für Relying Parties (RPs), um das Löschen von Passkeys auf clientseitigen Authenticators zu signalisieren. Dies ist essenziell, um sicherzustellen, dass veraltete oder ungültige Credentials nicht in der Auswahl-UI erscheinen und so eine schlanke und sichere Benutzererfahrung gewahrt bleibt. Es gibt zwei Methoden, um Passkeys lokal zu löschen: `signalUnknownCredential(options)` und `signalAllAcceptedCredentials(options)`. Erstere kann in Situationen verwendet werden, in denen der Benutzer nicht authentifiziert ist, während letztere verwendet werden kann, wenn der Benutzer authentifiziert ist. Daher sollte die zweite Methode aus Datenschutzgründen bevorzugt werden. So funktionieren die beiden Methoden: #### 3.3.1 Passkeys löschen mit signalUnknownCredential 1. **Struktur der Methode:** Die Methode `signalUnknownCredential(options)` beinhaltet die `rpId` (Relying Party ID) und die `credentialId` (die eindeutige Kennung des zu löschenden Credentials). ```javascript PublicKeyCredential.signalUnknownCredential({ rpId: "example.com", credentialId: "aabbcc", // Credential ID, die der User gerade versucht hat, base64url }); ``` 2. **Aufruf der Methode:** RPs rufen diese Methode auf, wann immer sie feststellen, dass ein Credential gelöscht werden sollte. Dies könnte unmittelbar nach einem Authentifizierungsversuch mit einem ungültigen Credential sein, während einer Kontolöschung oder wenn ein Benutzer ein Credential über die Kontoeinstellungen widerruft. 3. **Verarbeitung der Methode:** Wenn die Methode `signalUnknownCredential(options)` aufgerufen wird, versucht der clientseitige Authenticator, Credentials zu finden, die mit `rpId` und `credentialId` übereinstimmen. Abhängig von den Fähigkeiten des Authenticators wird das Credential entfernt oder ein authenticator-spezifisches Verfahren angewendet, um das Credential in zukünftigen Authentifizierungs-Abläufen zu verbergen. #### 3.3.2 Passkeys löschen mit signalAllAcceptedCredentials 1. **Struktur der Methode:** Die Methode `signalAllAcceptedCredentials(options)` enthält die `rpId` (Relying Party ID), `userId` und eine Liste gültiger Credential IDs in `allAcceptedCredentialIds` (Liste der eindeutigen Kennungen von Credentials, die behalten werden sollen). ```javascript PublicKeyCredential.signalAllAcceptedCredentials({ rpId: "example.com", userId: "aabbcc", // User-Handle, base64url. allAcceptedCredentialIds: ["bb"], }); ``` 2. **Aufruf der Methode:** RPs rufen diese Methode auf, wann immer sie feststellen, dass ein Credential gelöscht werden sollte, und signalisieren eine Liste der _gültigen_ Credentials. Diese Methode sollte gegenüber `signalUnknownCredential(options)` bevorzugt werden, um Credentials zu löschen. 3. **Verarbeitung der Methode:** Wenn die Methode `signalAllAcceptedCredentials(options)` aufgerufen wird, gleicht der clientseitige Authenticator die `rpId` und `userId` ab. Der Authenticator sucht alle lokalen Credentials, die zu `rpId` und `userId` passen. Das Ergebnis wird mit `allAcceptedCredentialIds` verglichen. Wenn es lokale Credentials gibt, die _nicht_ in `allAcceptedCredentialIds` enthalten sind, werden diese Credentials lokal entfernt (oder je nach Authenticator verborgen). 4. **Credentials wieder sichtbar machen:** Wenn Credentials lediglich verborgen wurden (abhängig vom Authenticator) und nun wieder Teil von `allAcceptedCredentialIds` sind, werden diese Credentials in zukünftigen Authentifizierungs-Abläufen wieder präsent sein. 5. **Nützliche Tipps:** - Bei der Verwendung von `signalAllAcceptedCredentials(options)` ist zu beachten, dass Authenticators zum Zeitpunkt der Ausführung dieser Methode möglicherweise nicht immer verbunden sind. Daher sollten Relying Parties erwägen, `signalAllAcceptedCredentials(options)` periodisch auszuführen, z. B. bei jedem Login, um sicherzustellen, dass alle Credentials aktuell sind. - Relying Parties müssen vorsichtig sein, wenn sie die Liste der Credential IDs (`allAcceptedCredentialIds`) spezifizieren. Credentials, die nicht in dieser Liste enthalten sind, können vom Authenticator verborgen oder entfernt werden, möglicherweise irreversibel. Um zu verhindern, dass gültige Credentials versehentlich weggelassen werden, muss sichergestellt werden, dass die Liste vollständig ist. Falls eine gültige Credential ID versehentlich ausgelassen wurde, sollte sie so schnell wie möglich wieder zu `signalAllAcceptedCredentials(options)` hinzugefügt werden, um sie wieder sichtbar zu machen, vorausgesetzt, der Authenticator unterstützt dies. - Wann immer möglich, sollten Authenticators das vorübergehende Verbergen von Credentials dem permanenten Entfernen vorziehen. Dieser Ansatz erleichtert die Wiederherstellung, falls eine gültige Credential ID versehentlich von der Relying Party ausgelassen wurde, und ermöglicht die Wiederherstellung ohne dauerhaften Verlust. ![Google Password Manager Passkey gelöscht](https://www.corbado.com/website-assets/GPK_PK_deleted_all_c211cc9e0a.png) Im obigen Screenshot seht ihr, wie Google Chrome Löschvorgänge signalisiert. Die WebAuthn Signal API kann mit dem [Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager) auf dem Desktop getestet werden. ## 4. Empfehlungen Um die WebAuthn Signal API effektiv zu implementieren und eine nahtlose Synchronisierung von Passkey-Metadaten über clientseitige Authenticators hinweg sicherzustellen, solltet ihr folgende Empfehlungen beachten: - **Achtet auf Updates der WebAuthn Signal API und die tatsächliche Implementierung:** Bleibt über die neuesten Entwicklungen und Updates zur Signal API informiert. Die WebAuthn Signal API ist ab [Google Chrome 132](https://chromestatus.com/feature/5101778518147072) aktiviert, gefolgt von anderen Browsern (z. B. hat [Safari ebenfalls Unterstützung angekündigt](https://github.com/WebKit/standards-positions/issues/400)). Prüft regelmäßig den Fortschritt und Updates der WebAuthn Signal API, um sicherzustellen, dass eure Implementierung den neuesten Standards und Praktiken entspricht. Wir werden diesen Blogpost aktualisieren, sobald sich die Landschaft weiterentwickelt. - **Startet mit dem `signalAllAcceptedCredentials(options)`-Ansatz nach jedem erfolgreichen Login:** Dieser Ansatz stellt sicher, dass alle Metadaten und Credential IDs in einem einzigen Methodenaufruf aktualisiert werden, was den Prozess vereinfacht, Konsistenz über Geräte und Plattformen hinweg wahrt und gleichzeitig gelöschte oder veraltete Credentials deaktiviert. - **Echtzeit-Messaging mit `signalUnknownCredential(options)` für große Deployments:** Zieht Echtzeit-Messaging mit der Methode `signalUnknownCredential(options)` für große Deployments in Betracht oder wenn sofortige Updates erforderlich sind. Diese Methode kann die Effizienz und Genauigkeit des Credential-Managements verbessern und sicherstellen, dass ungültige oder veraltete Credentials umgehend aus der Auswahl-UI entfernt werden. Indem ihr diesen Empfehlungen folgt, könnt ihr die WebAuthn Signal API effektiv implementieren, sobald sie unterstützt wird. So stellt ihr sicher, dass Passkey-Metadaten aktuell und konsistent über alle clientseitigen Authenticators hinweg bleiben und bietet damit eine reibungslose und sichere Benutzererfahrung für Passkeys. ## 5. Fazit Der [WebAuthn-Standard](https://www.corbado.com/de/blog/webauthn-server-implementierung) entwickelt sich ständig weiter und wird monatlich funktionsreicher. Die Einführung der WebAuthn Signal API ist ein bedeutender Schritt vorwärts im Management von Passkey-Metadaten und Löschungen auf clientseitigen Authenticators. Diese API adressiert die entscheidenden Anwendungsfälle der Synchronisierung von Informationen zwischen Relying Parties (RPs) und Authenticators und stellt sicher, dass ungültige oder veraltete Passkeys entfernt werden, was die Benutzererfahrung verbessert. - **Warum wird die Signal API benötigt?** Die Signal API ist essenziell für die Aktualisierung von Passkey-Metadaten und das Löschen von Passkeys auf clientseitigen Authenticators. Sie löst Probleme im Zusammenhang mit veralteten `user.name`- und `user.displayName`-Informationen, die zu Verwirrung führen können, wenn Credentials in der Auswahl-UI präsentiert werden. Zusätzlich hilft sie dabei, eine saubere und sichere Credential-Auswahl-Schnittstelle zu bewahren, indem widerrufene oder gelöschte Passkeys entfernt werden. - **Wie funktioniert die Signal API?** Die Signal API ermöglicht es RPs, Methoden über den aktuellen Status von Credentials aufzurufen, einschließlich Updates von Metadaten und der Signalisierung von Passkey-Löschungen. Diese Berichte werden vom clientseitigen Authenticator verarbeitet und stellen sicher, dass die den Benutzern präsentierten Informationen korrekt und aktuell sind. Die API ist datenschutzfreundlich konzipiert und arbeitet ohne Rückmeldung an die RP über den Erfolg der Updates. Da sich der [WebAuthn-Standard](https://www.corbado.com/de/blog/webauthn-server-implementierung) weiterentwickelt, profitiert er von den vielfältigen Interessen seiner Teilnehmer, die verschiedene Teile des Standards vorantreiben. Ein Auge auf diese Entwicklungen zu haben, ist entscheidend, um bei den neuesten Verbesserungen auf dem Laufenden zu bleiben und sicherzustellen, dass Implementierungen mit den neuesten Best Practices und Standards übereinstimmen. Die WebAuthn-Community treibt die Innovation weiter voran und macht die [Authentifizierung](https://www.corbado.com/de/blog/passkey-fallback-recovery) sicherer und benutzerfreundlicher.