Early Design Review: Lightweight FedCM

[bvandersloot-mozilla]

こんにちは TAG-さん!

I'm requesting a TAG review of Lightweight FedCM.

The goal of this project is to provide a purpose-built API for enabling secure and user-mediated access to cross-site top-level unpartitioned cookies. This is accomplished with integration with the Credential Management API to enable easy integration with alternative authentication mechanisms. A site that wants a user to log in calls the navigator.credentials.get() function with arguments defined in this spec the browser ensures there is appropriate user mediation and identity provider opt-in and hands off a token. With those assurances, the browser may also decide there is no additional privacy loss associated with access to unpartitioned state, and choose to automatically grant access to Storage Access requests.

• Explainer¹ (minimally containing user needs and example code): https://github.com/fedidcg/LightweightFedCM/blob/main/README.md
• User research: None
• Security and Privacy self-review²: https://github.com/fedidcg/LightweightFedCM/blob/main/security-privacy-self-review.md
• GitHub repo: https://github.com/fedidcg/LightweightFedCM
• Primary contacts (and their relationship to the specification):
  • Benjamin VanderSloot (@bvandersloot-mozilla), Mozilla, Author
  • Johann Hofmann (@johannhof), Google, Author
  • Heather Flanagan (@hlflanagan), Spherical Cow Consulting, LLC, Community Group Chair
• Organization/project driving the design: Mozilla
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status):
  • Bugzilla: [meta] Lightweight FedCM Implementation

Further details:

• [x] I have reviewed the TAG's Web Platform Design Principles

• The group where the incubation/design work on this is being done (or is intended to be done in the future): Federated Identity CG

• The group where standardization of this work is intended to be done ("unknown" if not known): Federated Identity WG

• Existing major pieces of multi-implementer review or discussion of this design:

  • Substantial discussions from FedIDCG meetings:
    • https://github.com/fedidcg/meetings/blob/38e2079ee17f2cd045293551a64b4426296375c3/2024/2024-05-14-notes.md?plain=1#L140-L233
    • https://github.com/fedidcg/meetings/blob/38e2079ee17f2cd045293551a64b4426296375c3/2024/2024-06-11-notes.md?plain=1#L70-L221
    • https://github.com/fedidcg/meetings/blob/38e2079ee17f2cd045293551a64b4426296375c3/2024/2024-08-06-notes.md?plain=1#L39-L119
    • https://github.com/fedidcg/meetings/blob/38e2079ee17f2cd045293551a64b4426296375c3/2024/2024-08-20-notes.md?plain=1#L41-L226

• Major unresolved issues with or opposition to this design:

  • The only major open point of contention among implementers is how to handle privacy protections on the navigation this API may induce. This reduces to whether this proposal should be held to a higher privacy standard than window.open by its design or if it should just accept any general navigational tracking mitigations that may come in the future.

• This work is being funded by: Mozilla and Google

[johannhof]

cc @ekovac @samuelgoto

[jyasskin]

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?

[samuelgoto]

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:

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

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.

[bvandersloot-mozilla]

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.

[rhiaro]

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.

[bvandersloot-mozilla]

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.

[samuelgoto]

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.

[jyasskin]

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.

[johannhof]

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.