On Wed, Oct 2, 2024 at 11:04 AM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote:
> > > 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. > > I've added non-goals, user journeys, and alternatives we discussed with the WebAuthn WG to the explainer <https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Signal-API-explainer> . In terms of the names of the methods, they were vetted by the WebAuthn WG and we do not expect them to change. We've already had our own fair share of bikeshedding (: > 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$> > . > > -- 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/CAB0jiomsEFxwOyc%2BD-q4SZoscAgkcb-eOJO9G4b58gevoo57OA%40mail.gmail.com.
