Thanks for getting more support and better describing the needs, Nina. LGTM2
On Tue, Oct 15, 2024, 8:19 AM Domenic Denicola <dome...@chromium.org> wrote: > LGTM1 > > On Saturday, September 21, 2024 at 1:09:55 AM UTC+9 Nina Satragno wrote: > >> 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 >> >> Measurement >> https://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/e4f40ad6-8ee2-4822-a658-3aba5d3487a2n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e4f40ad6-8ee2-4822-a658-3aba5d3487a2n%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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/CAA44PQhynTnP1tbOQw5_c%2BiaV8c7etBiS%2Bmbkmru4PLWfard8A%40mail.gmail.com.
