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? > > 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/CAOMQ%2Bw9B2dg1u1jhOrX8nZt%3DqXaV_%2Bocz6%2Be%3D_ULjMsxMDExww%40mail.gmail.com.
