Amazing; thanks for letting us know! On Thu, Sep 26, 2024 at 10:22 AM Tim Cappalli <tim.cappa...@okta.com> wrote:
> Okta, a very large WebAuthn Relying Party, is excited about this feature. > It addresses one of the top complaints we hear about passkeys which is > "orphaned passkeys" in authenticators when they are deleted from the user > account at the RP. > > tim > > On Wed, Sep 25, 2024 at 2:26 PM Alex Russell <slightly...@chromium.org> > wrote: > >> Hey Nina, >> >> This is an exciting feature! The API OWNERS decided to let this Intent >> ride this week for a couple of reasons: >> >> >> - The TAG review is new, and I strongly suspect that there will be >> feedback on the API naming and consistency here >> - The Explainer is incomplete. I don't see end-to-end code samples >> outlining how this feature solves a problem that was tricky to work around >> before (i.e, the before vs. after state), or considered alternatives to >> this design, or even considered alternatives to this choice of naming. >> Explicit non-goals are also conspicuous by their absence. >> >> Our top-line goal at I2S stage is to judge if a proposal is solving an >> important problem well. Having an RP weigh in last year is helpful, but >> doesn't seem to speak to this specific design. Is there more signal from >> developers that this is the right API? >> >> Thanks, >> >> Alex >> >> On Friday, September 20, 2024 at 9:09:55 AM UTC-7 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 >>> <https://urldefense.com/v3/__https://pr-preview.s3.amazonaws.com/nsatragno/webauthn/pull/2093.html*sctn-signal-methods__;Iw!!PwKahg!936DvbygeUme5MPpNOWqxDy6FvZCZtkSiLMeRY0TwVIoWbehmHPOg5lD3MGweekJMd2uOWJaEiraYqa-M7bw1rJy$> >>> >>> 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://urldefense.com/v3/__https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink*3EWebAuthentication__;JQ!!PwKahg!936DvbygeUme5MPpNOWqxDy6FvZCZtkSiLMeRY0TwVIoWbehmHPOg5lD3MGweekJMd2uOWJaEiraYqa-M_N3sSnT$> >>> >>> 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 >>> <https://urldefense.com/v3/__https://w3c.github.io/webauthn/*sctn-signalAllAcceptedCredentials__;Iw!!PwKahg!936DvbygeUme5MPpNOWqxDy6FvZCZtkSiLMeRY0TwVIoWbehmHPOg5lD3MGweekJMd2uOWJaEiraYqa-M9TX2WFX$> >>> >>> >>> 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 >>> <https://urldefense.com/v3/__https://developer.chrome.com/docs/devtools/webauthn__;!!PwKahg!936DvbygeUme5MPpNOWqxDy6FvZCZtkSiLMeRY0TwVIoWbehmHPOg5lD3MGweekJMd2uOWJaEiraYqa-M6YN4qWB$> >>> [2] https://w3c.github.io/webauthn/#sctn-automation >>> <https://urldefense.com/v3/__https://w3c.github.io/webauthn/*sctn-automation__;Iw!!PwKahg!936DvbygeUme5MPpNOWqxDy6FvZCZtkSiLMeRY0TwVIoWbehmHPOg5lD3MGweekJMd2uOWJaEiraYqa-M7MtriSq$> >>> [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://urldefense.com/v3/__https://chromium.googlesource.com/chromium/src/*/main/docs/testing/web_platform_tests.md__;Kw!!PwKahg!936DvbygeUme5MPpNOWqxDy6FvZCZtkSiLMeRY0TwVIoWbehmHPOg5lD3MGweekJMd2uOWJaEiraYqa-M6yeXYeJ$> >>> ?Yes >>> >>> >>> https://wpt.fyi/results/webauthn/signal-all-accepted-credentials.https.html >>> <https://urldefense.com/v3/__https://wpt.fyi/results/webauthn/signal-all-accepted-credentials.https.html__;!!PwKahg!936DvbygeUme5MPpNOWqxDy6FvZCZtkSiLMeRY0TwVIoWbehmHPOg5lD3MGweekJMd2uOWJaEiraYqa-Mz6qHmfI$> >>> https://wpt.fyi/results/webauthn/signal-current-user-details.https.html >>> <https://urldefense.com/v3/__https://wpt.fyi/results/webauthn/signal-current-user-details.https.html__;!!PwKahg!936DvbygeUme5MPpNOWqxDy6FvZCZtkSiLMeRY0TwVIoWbehmHPOg5lD3MGweekJMd2uOWJaEiraYqa-M0WRDUTb$> >>> https://wpt.fyi/results/webauthn/signal-unknown-credential.https.html >>> <https://urldefense.com/v3/__https://wpt.fyi/results/webauthn/signal-unknown-credential.https.html__;!!PwKahg!936DvbygeUme5MPpNOWqxDy6FvZCZtkSiLMeRY0TwVIoWbehmHPOg5lD3MGweekJMd2uOWJaEiraYqa-M89eiu-V$> >>> >>> >>> 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 >>> <https://urldefense.com/v3/__https://crbug.com/361751877__;!!PwKahg!936DvbygeUme5MPpNOWqxDy6FvZCZtkSiLMeRY0TwVIoWbehmHPOg5lD3MGweekJMd2uOWJaEiraYqa-M7_H9Y5G$> >>> >>> Measurement >>> https://chromestatus.com/metrics/feature/timeline/popularity/5104 >>> <https://urldefense.com/v3/__https://chromestatus.com/metrics/feature/timeline/popularity/5104__;!!PwKahg!936DvbygeUme5MPpNOWqxDy6FvZCZtkSiLMeRY0TwVIoWbehmHPOg5lD3MGweekJMd2uOWJaEiraYqa-M3bFYgic$> >>> https://chromestatus.com/metrics/feature/timeline/popularity/5105 >>> <https://urldefense.com/v3/__https://chromestatus.com/metrics/feature/timeline/popularity/5105__;!!PwKahg!936DvbygeUme5MPpNOWqxDy6FvZCZtkSiLMeRY0TwVIoWbehmHPOg5lD3MGweekJMd2uOWJaEiraYqa-M4OGolP_$> >>> https://chromestatus.com/metrics/feature/timeline/popularity/5106 >>> <https://urldefense.com/v3/__https://chromestatus.com/metrics/feature/timeline/popularity/5106__;!!PwKahg!936DvbygeUme5MPpNOWqxDy6FvZCZtkSiLMeRY0TwVIoWbehmHPOg5lD3MGweekJMd2uOWJaEiraYqa-M9tSF31m$> >>> >>> 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 >>> <https://urldefense.com/v3/__https://signal-api-demo.glitch.me/__;!!PwKahg!936DvbygeUme5MPpNOWqxDy6FvZCZtkSiLMeRY0TwVIoWbehmHPOg5lD3MGweekJMd2uOWJaEiraYqa-M2yTK_9u$> >>> >>> 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 >>> <https://urldefense.com/v3/__https://chromestatus.com/feature/5101778518147072?gate=5111131065286656__;!!PwKahg!936DvbygeUme5MPpNOWqxDy6FvZCZtkSiLMeRY0TwVIoWbehmHPOg5lD3MGweekJMd2uOWJaEiraYqa-M1nAqjrM$> >>> >>> This intent message was generated by Chrome Platform Status >>> <https://urldefense.com/v3/__https://chromestatus.com/__;!!PwKahg!936DvbygeUme5MPpNOWqxDy6FvZCZtkSiLMeRY0TwVIoWbehmHPOg5lD3MGweekJMd2uOWJaEiraYqa-M36Savk8$> >>> . >>> >>> -- >>> 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/cc140654-60b8-4102-9b9f-1ae970073de2n%40chromium.org >> <https://urldefense.com/v3/__https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cc140654-60b8-4102-9b9f-1ae970073de2n*40chromium.org?utm_medium=email&utm_source=footer__;JQ!!PwKahg!936DvbygeUme5MPpNOWqxDy6FvZCZtkSiLMeRY0TwVIoWbehmHPOg5lD3MGweekJMd2uOWJaEiraYqa-M3L2g7ok$> >> . >> > -- 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/CAA44PQjNLpjg-MWEZSrpNGQ62OdjoxqtWv1d4xgA3UDC5Hak0Q%40mail.gmail.com.
