Contact emailsnsatra...@chromium.org, identity-...@chromium.org Explainer https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Signal-API-explainer
Specification https://pr-preview.s3.amazonaws.com/nsatragno/webauthn/pull/2093.html#sctn-signal-methods Summary 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 Blink componentBlink>WebAuthentication <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebAuthentication> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/996 TAG review statusPending Risks Interoperability and Compatibility None, this is a new API. *Gecko*: No signal ( https://github.com/mozilla/standards-positions/issues/1075). I'll update here once that changes. *WebKit*: No signal ( https://github.com/WebKit/standards-positions/issues/400). I'll update here once that changes. *Web developers*: Positive ( https://github.com/w3c/webauthn/issues/1967#issuecomment-1848433321) The signal methods address common concerns from RPs that have been voiced since the early days of WebAuthn. See https://github.com/w3c/webauthn/issues/1967 and the issues linked from there. *Other signals*: Ergonomics Omitting a valid credential ID from `signalAllAcceptedCredentials` can result in the user no longer being able to sign in with that passkey. This is explicitly called out in the spec [1]. The spec recommends that authenticators hide (instead of removing) passkeys to mitigate this issue. Chrome will ship a first version that removes credentials, and a follow-up will hide them instead. This is because removing credentials requires a lot less coordination from multiple products than hiding them, and lets us ship and iterate on the API faster. [1] https://w3c.github.io/webauthn/#sctn-signalAllAcceptedCredentials Security Relying parties can only update or remove credentials that are bound to their relying party ID. WebView application risks Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? N/A, this is a new API. Debuggability Chrome supports signal* methods through the WebAuthn devtools panel [1]. signal* methods are also supported through webdriver's WebAuthn API [2], with a small change in the works [3] specifically to be able to debug `signalCurrentUserDetails`. [1] https://developer.chrome.com/docs/devtools/webauthn [2] https://w3c.github.io/webauthn/#sctn-automation [3] https://github.com/w3c/webauthn/pull/2148 Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?No Initially, this feature will be supported on Chrome desktop only, and on Chrome only for Google Password Manager (GPM) credentials. Support for iCloud keychain and Windows Hello will depend on macOS and Windows updates respectively. Android support requires an update to the Android Credential Manager API that is being worked on. For GPM credentials, we also need to update Google Play Services accordingly. Once the Android Credential Manager API is launched, other credential providers will be able to hook to the API. Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ?Yes https://wpt.fyi/results/webauthn/signal-all-accepted-credentials.https.html https://wpt.fyi/results/webauthn/signal-current-user-details.https.html https://wpt.fyi/results/webauthn/signal-unknown-credential.https.html DevTrial instructions https://github.com/w3c/webauthn/wiki/Experimenting-with-the-Signal-API-on-Chrome Flag name on chrome://flags chrome://flags#enable-experimental-web-platform-features Finch feature nameCredentialManagerReport Requires code in //chrome?True Tracking bughttps://crbug.com/361751877 Measurementhttps://chromestatus.com/metrics/feature/timeline/popularity/5104 https://chromestatus.com/metrics/feature/timeline/popularity/5105 https://chromestatus.com/metrics/feature/timeline/popularity/5106 Availability expectationWe expect this feature to be generally available on desktop for M131. Android will follow after. Adoption expectationThe feature can be adopted right away, as while the functionality provided significantly improves the UX of WebAuthn, it's provided as a "best-effort" and can safely be unimplemented. Non-OSS dependencies Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function? * Android Credential Manager for Android support * Apple's browser passkey APIs for macOS and iOS support. * Windows webauthn.dll for Windows Hello credentials. Sample links https://signal-api-demo.glitch.me Estimated milestones DevTrial on desktop 130 Anticipated spec changes Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way). No changes. Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5101778518147072?gate=5111131065286656 This intent message was generated by Chrome Platform Status <https://chromestatus.com/>. -- Nina Satragno -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0jio%3DK91NiFqx%3DO1uCtCHRKdfuqc%3Dp2HOmEg_eQ7xXFfm9Xg%40mail.gmail.com.
