Feature request: Expose WebAuthn Signal API (signalUnknownCredential / signalAllAcceptedCredentials)

[TimGustafson]

Problem

This is a follow-up to #172, which described the situation where a passkey credential is deleted server-side but remains on the device. The user then picks the stale credential from the OS passkey picker, authentication fails, and there's no way for the app to clean it up programmatically.

That issue was closed with the conclusion that the platform doesn't support programmatic deletion — which is true for direct deletion, but the WebAuthn Signal API is a different and more appropriate mechanism that wasn't mentioned there.

The Signal API

WebAuthn Level 3 introduced methods specifically for this problem that allow a relying party to signal to the platform that a credential is no longer valid, so it can be removed from autofill suggestions:

• signalUnknownCredential(rpId, credentialId) — tells the platform that a specific credential is not recognized by the relying party
• signalAllAcceptedCredentials(rpId, userId, allAcceptedCredentialIds) — tells the platform the full set of valid credentials for a user, allowing it to prune any others
• signalCurrentUserDetails(rpId, userId, name, displayName) — updates user display info on stored credentials

Both Android and Apple platforms support this:

• Android: SignalUnknownCredentialRequest / SignalAllAcceptedCredentialIdsRequest via CredentialManager
  (androidx.credentials 1.6.0-beta03+, Android 15+)
• iOS/macOS: ASCredentialUpdater.reportUnknownPublicKeyCredential /
  reportAllAcceptedPublicKeyCredentials (note: ASCredentialUpdater is deprecated as of iOS/macOS 26.2 in favour of ASCredentialDataManager, so both should ideally be supported)

Requested Addition

New methods on PasskeyAuthenticator (or a separate utility class):

Future<void> signalUnknownCredential({
  required String rpId,
  required String credentialId,
});

Future<void> signalAllAcceptedCredentials({
  required String rpId,
  required String userId,
  required List<String> allAcceptedCredentialIds,
});

Use Case

After a relying party returns an error indicating that a credential is not recognized, the app could call signalUnknownCredential to hint to the OS to remove the stale entry, preventing it from accumulating in the picker over repeated login attempts.

[kopy]

Thank you for the feature request. I think we should wait until the Android dependency is stable. We are monitoring it closely to avoid shipping with an RC or beta requirement, and then we can test everything together.