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) 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.
