On Wed, Nov 13, 2024 at 11:29 AM Chris Harrelson <chris...@chromium.org> wrote:
> > > On Thu, Nov 7, 2024 at 3:46 PM Christian Biesinger < > cbiesin...@chromium.org> wrote: > >> >> Contact emails >> >> cbiesin...@chromium.org >> >> Explainer >> >> Use case we want to support: >> https://github.com/w3c-fedid/FedCM/issues/477 >> >> Derived explainers: >> >> https://github.com/fedidcg/FedCM/issues/555 >> >> https://github.com/fedidcg/FedCM/issues/556 >> >> https://github.com/fedidcg/FedCM/issues/559 >> >> https://github.com/fedidcg/FedCM/issues/552 >> >> https://github.com/fedidcg/FedCM/issues/553 >> >> Specification >> >> https://github.com/w3c-fedid/FedCM/pull/662 (continuation API) >> >> https://github.com/w3c-fedid/FedCM/pull/661 (parameter API, merged) >> >> https://github.com/w3c-fedid/FedCM/pull/668 (fields API) >> >> https://github.com/w3c-fedid/FedCM/pull/667 (multiple configURLs) >> >> https://github.com/w3c-fedid/FedCM/pull/669 (account labels) >> > > Most of these are still open, is something blocking finishing and landing > these spec PRs? > > We are waiting for reviews from outside of the team and WG approval to land them. No real blocker otherwise. A lot of WG calls have been cancelled recently which makes landing these take longer than we had hoped for. Christian > >> Summary >> >> This bundles a few features that we would like to launch at the same >> time. We are bundling them together because they can be used by IdPs to >> implement authorization flows such as letting a user grant access to a >> user’s calendar to an RP. See also >> https://github.com/w3c-fedid/FedCM/issues/477. Specifically: >> >> - >> >> The IdP needs to be able to show a custom prompt for the permission >> (continuation API) >> - >> >> The RP needs an extensible way to communicate to the IdP what it >> wants access to (parameters API) >> - >> >> The RP needs to be able to customize/suppress the text referring to >> the IdP sharing “name, email address and profile picture” because in this >> situation they are asking for different information (fields API) >> - >> >> The IdP may want to use a different endpoint to implement the >> authorization flow (multiple configURLs) >> - >> >> Certain accounts may only be eligible for one of the authentication >> and authorization flows and so there needs to be a way to show different >> accounts in the two flows (account labels API) >> >> >> In addition, the APIs are solving a series of related FPWD blockers >> <https://github.com/w3c-fedid/FedCM/wiki/Status-of-FPWD%E2%80%90identified-Issues> >> identified >> <https://lists.w3.org/Archives/Public/public-fedid-wg/2024Jul/0006.html> >> by the FedID WG. >> >> Continuation API: >> >> https://github.com/fedidcg/FedCM/issues/555 >> >> This lets the IDP open a popup window to finish the sign-in flow after >> potentially collecting additional information. >> >> Parameters API: >> >> https://github.com/fedidcg/FedCM/issues/556 >> >> This lets RPs pass additional data to the ID assertion endpoint >> >> Fields API: >> >> https://github.com/fedidcg/FedCM/issues/559 >> >> This lets RPs bypass the data sharing prompt in favor of the IDP prompting >> >> Multiple configURLs: >> >> https://github.com/fedidcg/FedCM/issues/552 >> >> This lets IDPs use different config files in different contexts without >> weakening FedCM privacy properties, by allowing one accounts endpoint for >> the eTLD+1 (instead of one config file, which is more limiting than >> necessary) >> >> Account labels: >> >> https://github.com/fedidcg/FedCM/issues/553 >> >> Combined with the previous proposal, this allows filtering the account >> list per config file without providing additional entropy to the IDP. >> >> >> Blink component >> >> Blink>Identity>FedCM >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EIdentity%3EFedCM> >> >> TAG review >> >> https://github.com/w3ctag/design-reviews/issues/945 >> >> TAG review status >> >> Pending >> >> Chromium Trial Name >> >> FedCmContinueOnBundle >> >> Link to origin trial feedback summary >> >> What we learned during the origin trial: >> >> >> - >> >> This bundle works well for implementing an authorization flow for an >> identity provider >> - >> >> The parameter API needed to be refined to be easier to use for an IDP >> (allow nested objects; send the parameters as serialized JSON instead of >> individually prefixed parameters) >> - >> >> The fields API has gone through various iterations during the trial >> and is now easier and more flexible to use >> - >> >> We have identified a possible future extension to the continuation >> API (adding an IdentityProvider.reject function to mirror .resolve) but >> are >> not shipping it as part of this launch. >> >> >> >> >> Origin Trial documentation link >> >> >> https://developers.google.com/privacy-sandbox/blog/fedcm-chrome-126-updates#origin_trial_fedcm_continuation_api_bundle >> >> >> WebFeature UseCounter name >> >> kFedCmContinueOnResponse >> >> Risks >> >> Interoperability and Compatibility >> >> No compatibility risk as this adds new parameters to dictionaries in a >> function argument. >> >> No concern about interoperability because other browser engines currently >> do not ship FedCM. >> >> >> Gecko: No signal. For incremental improvements to FedCM, Firefox has >> asked us not to file standards position, and they will instead provide >> feedback in the GitHub PR. They have interacted on the spec PRs (e.g. on >> https://github.com/w3c-fedid/FedCM/pull/662) and on the explainers (e.g. >> https://github.com/w3c-fedid/FedCM/issues/477) but have not expressed an >> explicit positive signal. >> >> WebKit: No signal ( >> https://github.com/WebKit/standards-positions/issues/336) >> >> Web developers: Positive ( >> https://github.com/fedidcg/FedCM/issues/488#issuecomment-1749682526) >> Also: https://github.com/fedidcg/FedCM/issues/496#issuecomment-1781364610 >> https://github.com/fedidcg/FedCM/issues/533#issuecomment-1878581998 >> >> Other signals: >> >> Ergonomics >> >> This improves ergonomics for passing custom parameters to the IDP because >> it now provides a structured way to do so instead of (ab)using the "nonce" >> parameter. >> >> Otherwise no impact on ergonomics either way. >> >> >> Activation >> >> No particular risks. >> >> >> Security >> >> We made sure that the popup from the continuation API is same-origin with >> the IDP, and that it cannot communicate with the RP except through the >> narrow IdentityProvider.resolve API. In particular, window.opener is null. >> >> The additional parameters from the parameter and fields API are only sent >> to the server after user interaction, and from a privacy perspective are >> equivalent to the existing "nonce" field. However, from a developer >> ergonomics perspective the additions are much easier to use. >> >> Account labels were carefully designed not to add entropy and in >> particular not to send additional data to the server. >> >> >> 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 >> >> >> Debuggability >> >> We show console messages to assist debugging where appropriate. >> >> Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, ChromeOS, Android, and Android WebView)? >> >> No >> >> FedCM in general is not supported in webview >> >> >> 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/fedcm/fedcm-authz?label=experimental&label=master&aligned >> >> We are investing why they are failing on wpt.fyi even though they pass in >> our internal infrastructure (e.g. >> https://ci.chromium.org/ui/test/chromium/ninja%3A%2F%2F%3Ablink_wpt_tests%2Fvirtual%2Ffedcm-authz%2Fexternal%2Fwpt%2Ffedcm%2Ffedcm-authz%2Ffedcm-continue-on-with-account.https.html >> ) >> >> >> >> Flag name on chrome://flags >> >> fedcm-authz >> >> Finch feature name >> >> FedCmAuthz >> >> Requires code in //chrome? >> >> True >> >> Tracking bug >> >> https://crbug.com/40262526 >> >> Launch bug >> >> https://launch.corp.google.com/launch/4348692 >> >> Measurement >> >> https://chromestatus.com/metrics/feature/timeline/popularity/4955 In >> addition, we have several UMA metrics. >> >> Estimated milestones >> >> Shipping on desktop >> >> 132 >> >> Origin trial desktop first >> >> 127 >> >> Origin trial desktop last >> >> 131 >> >> Origin trial extension 1 end milestone >> >> 133 >> >> Shipping on Android >> >> 132 >> >> Origin trial Android first >> >> 128 >> >> Origin trial Android last >> >> 133 >> >> >> 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). >> >> None >> >> Link to entry on the Chrome Platform Status >> >> https://chromestatus.com/feature/6495400321351680?gate=4886628616372224 >> >> Links to previous Intent discussions >> >> Intent to Prototype: >> https://groups.google.com/a/chromium.org/g/blink-dev/c/qqrG6yn1u1Q?pli=1 >> >> Intent to Experiment: >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XEedt%2Bu2pS_2NHHfxtEV9JJ7wbuKNEnieeWr6w8FtwKLw%40mail.gmail.com >> >> Intent to Extend Experiment 1: >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/66ec74bf.2b0a0220.195547.03af.GAE%40google.com >> >> >> This intent message was generated by Chrome Platform Status >> <https://chromestatus.com/>. >> >> -- >> 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 visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XHfrr2FvW4qP%2BsS3Jn7DoE5oyTZETyuJTgT9wSN46ao4Q%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XHfrr2FvW4qP%2BsS3Jn7DoE5oyTZETyuJTgT9wSN46ao4Q%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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XFsZ%3DqJf9GogNxH7Zj_UJU2UMLvMtncetQ6pqUWzZBcJQ%40mail.gmail.com.