Re: [w3ctag/design-reviews] Early Design Review: Lightweight FedCM (Issue #986)

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 that doesn't require exposing HTTP endpoints, which is a worthy goal (albeit, personally, I'm skeptical that it can be accomplished fully).

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:

| | FedCM "Light" | FedCM
| -- | -- | -- |
|account chooser UI hints | stored in-browser, with lifetime specified by IDP | dynamically fetched |

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

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.  

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/986#issuecomment-2315850595
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/986/2315850595@github.com>