LGTM3 On Tue, Oct 15, 2024 at 6:52 AM Alex Russell <slightly...@chromium.org> wrote:
> 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA44PQhynTnP1tbOQw5_c%2BiaV8c7etBiS%2Bmbkmru4PLWfard8A%40mail.gmail.com?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/CAOmohSKvK6055tVY94%3D95Stbe8UBARKYcnL64vkqwC2CLRYL6g%40mail.gmail.com.
