On Thursday, September 26, 2024 at 10:26:35 PM UTC+2 Alex Russell wrote:
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 Explainerhttps://github.com/w3c/webauthn/wiki/Explainer:- WebAuthn-Signal-API-explainer Specificationhttps://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. WebKit are now supportive <https://github.com/WebKit/standards-positions/issues/400#issuecomment-2386532601> ! *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 instructionshttps://github.com/w3c/webauthn/wiki/Experimenting- with-the-Signal-API-on-Chrome Flag name on chrome://flagschrome://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$> Measurementhttps://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 milestonesDevTrial on desktop130 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 Statushttps://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/8d40ea14-6d0b-4649-9e93-8c87c5efd3cfn%40chromium.org.
