v130 · security

WebAuthn signal API

Allow WebAuthn relying parties to report information about existing credentials back to credential storage providers, so that incorrect or revoked credentials can be updated or removed from provider and system UI. https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Signal-API-explainer

concepts

  1. WebAuthn Signal probe

    Detect the three signal methods on PublicKeyCredential, create a real passkey with a server challenge, store the credential ID in the backend, and exercise each signal call against the browser.

  2. signalUnknownCredential — stale passkey cleanup

    The chromestatus motivation's concrete scenario: user deletes their account, returns later, sees a ghost passkey in the picker. Includes a real call into signalUnknownCredential with valid base64url payloads.

  3. RP lifecycle orchestrator

    Four real relying-party lifecycle events (username rotate, server-side revoke, multi-device removal, account merge). Each emits the exact Signal API call sequence, server-side state changes, a 4-step timeline of the user-visible effect, and a written rationale.

  4. Credential audit

    Audit the real credential IDs stored by the backend after navigator.credentials.create(). Active IDs go through signalAllAcceptedCredentials; revoked IDs go through signalUnknownCredential.

why it shipped

Discoverable credentials, such as passkeys, can be requested with navigator.credentials.get with an empty allowCredentials. In this case, if a user has any credentials for that relying party, they are presented with some UI to select which credential to use. If the user selects a credential, the resulting assertion carries the user.id value set at registration, allowing the relying party to resolve to an account without any further information.

references