cc @ekovac @samuelgoto

When reviewing the explainer, it wasn't immediately obvious why this deserves a new web feature when sites could "just" use the existing FedCM API. Among other things, the goals in the explainer seem to be roughly the same as the goals of FedCM itself. I eventually found https://github.com/fedidcg/LightweightFedCM/wiki/Comparing-FedCM-and-FedCM-%22Light%22. That's a little dense for people (me) who aren't intimately familiar with FedCM, but it seems to make the case that this new proposal is almost uniformly simpler than FedCM. The only downside seems to be that there's less IDP-provided information shown in the dialog? Given this simplicity, why does the more-complex FedCM API need to stay in the platform?

Just a few supportive clarifications here, @johannhof and @bvandersloot-mozilla feel free to correct me where I'm wrong.

When reviewing the explainer, it wasn't immediately obvious why this deserves a new web feature when sites could "just" use the existing FedCM API. Among other things, the goals in the explainer seem to be roughly the same as the goals of FedCM itself.

Just to be clear: this is a proposal to extend the FedCM API in a symbiotic manner, rather than in competition to, with a different set of trade-offs in the dimension of ergonomics with the "vanilla" FedCM.

Specifically, in this variation, @johannhof and @bvandersloot-mozilla are interested in exploring a variation of FedCM (in conjunction with this extension to Storage Access API) that doesn't require exposing FedCM-specific HTTP endpoints, which is a worthy goal (albeit, personally, I'm skeptical that it can be accomplished fully, without lowering the privacy properties of "vanilla" FedCM).

There is a solid subset of this proposal to extend FedCM that I think is worth pursuing. There are still a few controversial parts (in terms of privacy relaxations and ecosystem demand), but to be concrete, a big chunk of this (early) proposal is something that would address real problems in "vanilla" FedCM.

That's a little dense for people (me) who aren't intimately familiar with FedCM, but it seems to make the case that this new proposal is almost uniformly simpler than FedCM.

I think the key aspect that is being understated in that table is this line:

We heard extensively from IdPs that it is critical that the user information needs to be fresh (e.g. changing a user's name on a different device should be updated accordingly), and that to do so we'll either require (a) the Push API (or a variation of) and/or (b) the Pull model (what is described as "dynamically fetched" above). One could question the presupposition that IdPs actually need the data to be fresh, but if you take that as fair, then either (a) is going to be orders of magnitude less ergonomical to IdPs or (b) sets us back to having to expose HTTP endpoints so that accounts can be "dynamically fetched".

The other plausible alternative is to have the user "Sign-in to the IdP" again when the user information expires, forcing another navigator.credential.store() without having to expose any FedCM-specific HTTP endpoints.

That's feedback that @bvandersloot-mozilla and @johannhof are aware of and are intending to learn more from IdPs as they go along. Maybe that detail wasn't so clearly stated in that table, which I think would be fair.

Given this simplicity, why does the more-complex FedCM API need to stay in the platform?

As I noted above, I think @bvandersloot-mozilla and @johannhof are exploring a different set of trade-offs in the ergonomics spectrum, in a non-mutually exclusive way with "vanilla" FedCM: different IdPs may find this "lighter" than "vanilla" FedCM, depending on their deployment / legal requirements (e.g. maybe some IdPs don't actually need user names to be that fresh).

This is a proposal that @bvandersloot-mozilla has been working on openly and collaboratively in the FedID CG with @johannhof and I and has been open to reconciling with FedCM constructively.

Much of the proof is in the pudding, specially with regards to gathering evidence of developer demand and product market fit, but so far I've been very excited and supportive of this proposal to solve real ergonomic challenges adopting FedCM.

Thank you for the look!

When reviewing the explainer, it wasn't immediately obvious why this deserves a new web feature when sites could "just" use the existing FedCM API.

:+1:, further emphasis on the simplicity of use relative to the existing FedCM API is worth calling out in the introduction.

[...] it seems to make the case that this new proposal is almost uniformly simpler than FedCM. The only downside seems to be that there's less IDP-provided information shown in the dialog?

Sam beat me to much of the punch here.

It does boil down to the power of dynamically fetching the account information in the existing FedCM API. This gives those freshness guarantees. I actually developed this proposal because I didn't see those freshness guarantees shared by any IDPs participating in FedID CG and the complexity of using FedCM was a concern. We had one idea on how to get those freshness guarantees to Lightweight FedCM involving the Push API and making navigator.credentials.store available on ServiceWorkers, but never pursued it.

There is one more difference that is unlocked by the push of account information here: we allow a few more IDP use-cases. Because Lightweight FedCM does not send unparitioned requests in the background, it allows an arbitrary navigation if a credential isn't found, rather than being restricted to a single url linked by a .well-known file stored on the site's root. This isn't really covered in the explainer, nor the wiki tables yet, so sorry for this lack of clarity.

Given this simplicity, why does the more-complex FedCM API need to stay in the platform?

This proposal was initially designed and adopted by FedID CG as an independent Credential type and alternative to FedCM. In fact, it still operates as a fully functional subset of FedCM! However, we moved it to be a separate "operating mode" of FedCM because of the significant degree of overlap, to neither fanfare nor complaint in FedID CG. The idea being to leave the complicated bits for those that desperately need them. I personally am not wed to any spelling or names, though I cannot speak for my coauthor or the chairs.

We're happy to see this sort of experimentation with the FedCM problem space. It looks like there are outstanding questions in the Community Group about whether the Lightweight API will be enough to completely replace the existing proposal. We wondered whether this approach can enable single sign-out, and if it can't, that's a strong argument against it completely replacing the existing API. We look forward to the outcome of the testing you have planned.

Thank you for the review! Your feedback is greatly appreciated!

We wondered whether this approach can enable single sign-out, and if it can't, that's a strong argument against it completely replacing the existing API.

I believe that all instances of single-sign-out covered by vanilla FedCM are covered by this proposal as well. We will be sure to consider Single-Sign-Out as a key feature in this space.

whether the Lightweight API will be enough to completely replace the existing proposal

Just a clarification here that seems important to come across (and @bvandersloot-mozilla, please feel free to correct me here), but so far we don't believe this is a mutually exclusive proposition (e.g. "replace the existing proposal"), but rather strictly additive, as I said earlier here.

Sorry about that; we lost some of the TAG discussion in the comment that tried to summarize it and possibly also in the minutes of the discussion. There's a TAG preference to do only 1 API and to do just the simpler API, if that adequately serves the use cases. The comment about outstanding questions is the answer to that concern: we recognize that the CG and WG are still exploring whether the lighter-weight API has enough product/market fit to actually replace the more-established one, so we're encouraging the experimentation needed to figure that out.

Another opposite TAG preference also appeared in the discussion: the lightweight API makes it more trivial to join identities (because it assumes granting storage access), and perhaps it's worth having a heavier API with purpose-built features for each use case, in order to impose speed bumps on that identity joining. We ran out of time to really explore that tension, and we may find persistent disagreements about it, but regardless, I suspect both themes will keep coming up in FedCM reviews.

Another opposite TAG preference also appeared in the discussion: the lightweight API makes it more trivial to join identities (because it assumes granting storage access), and perhaps it's worth having a heavier API with purpose-built features for each use case, in order to impose speed bumps on that identity joining.

This is a common misconception about FedCM / SAA autogranting and it's simply objectively not true. FedCM mediates a unique high-entropy user identifier, which means there's no difference to 3PC access (this is why it has a prompt).

We discuss the privacy implications of the autogrant in extensive detail here, but happy to chat about this in more detail if needed.

We're happy to see this sort of experimentation with the FedCM problem space. It looks like there are outstanding questions in the Community Group about whether the Lightweight API will be enough to completely replace the existing proposal. We wondered whether this approach can enable single sign-out, and if it can't, that's a strong argument against it completely replacing the existing API. We look forward to the outcome of the testing you have planned.

We are not really thinking of "lightweight FedCM" and "full FedCM" as competing proposals, but rather complementary -- different modes of using FedCM. See also https://github.com/w3c-fedid/FedCM/issues/665