#1184: Incubation: IdP-Initiated FedCM

Visit on Github

Opened Jan 13, 2026

Explainer

https://github.com/w3c-fedid/FedCM/blob/main/explorations/drafts/interception.md

The explainer

Where and by whom is the work is being done?

  • GitHub repo: https://github.com/w3c-fedid/FedCM/blob/main/explorations/drafts/interception.md
  • Primary contacts:
    • Sam Goto (@samuelgoto), Google, Author
  • Organization/project driving the design: Google Chrome
  • This work is being funded by: Google
  • Incubation and standards groups that have discussed the design:
    • FedID CG
  • Standards group(s) that you expect to discuss and/or adopt this work when it's ready: FedID WG

Feedback so far

You should also know that...

This proposal intends to help enable IdPs to deploy FedCM on all of its RPs without requiring the RPs to redeploy.

There are a few reasons why we think deploying FedCM at scale might be important:

  • First, we think this can remove one of the main blockers to combat bounce tracking, which relies on top-level link-decorated navigations in conjunction with first party cookies. With this proposal deployed at scale, browsers get closer to be able to remove one of those two components, at least for a meaningful part of the traffic that is required to preserve federation.
  • Second, we are finding that the built-in native FedCM UX often outperforms top-level navigations (specially on mobile), so we'd expect that this will be useful present a better user experience to IdPs/RPs and users, in and of itself.
  • Third, in agentic browsers, whenever FedCM is being used, we think we can turn federation into a structured/programmable tool (like an MCP), rather than unstructured computer-use actuation (like computer vision), fundamentally providing a better foundation to agentic browsers when it comes assisting users logging in to websites.
<!-- Content below this is maintained by @w3c-tag-bot -->

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1184

Discussions

Log in to see TAG-private discussions.

Discussed Jan 12, 2026 (See Github)

Ehsan: Let me have a read, and then decide.

Discussed Jan 26, 2026 (See Github)

Ehsan: Still reading.

Hadley: How are we on deadlines? Looks like no obvious deadline. We are missing multi stakeholder support.

Discussed Feb 2, 2026 (See Github)

Ehsan: My review is almost done, think can post it by next week. Suggestion is to put it for discussion on next Thursday meeting so I can get Matthew’s opinion.

Lola: Please ping Hadley, as she’s in charge for the agenda for next week.

Discussed Feb 2, 2026 (See Github)

bump

Discussed Feb 9, 2026 (See Github)

Ehsan: Finished my review, will post it very soon. My main concern is that I see this as a stepping stone for more Agentic-related specs coming. I don't see any position from other stakeholders on this one. Because it seems like a stepping stone, I think we need to push for a clear position from other stakeholders first (Mozilla and WebKit).

Lola: We look forward to your draft comment.

Discussed Feb 16, 2026 (See Github)

Hadley: Ehsan has drafted this wonderful comment, which I am on board with, with two editorial contributions. Wonder if it would be better to look at the things separately. Ask them to share their thoughts and then update the explainer.

Ehsan: Ok, if you agree with the final one, just thumbs-up it, and I’ll post it.

Hadley: Ok, but generally I’m fine with it.

Heather: This is my Working Group by the way.

Hadley: Split answer: The explainer doesn’t look complete, the common-sense answer is, you need an alternatives considered section.

Lola: I think we can do both, leave it up for you to device.

Hadley: What are your views, Heather?

Heather: Don’t know your exact question. (https://github.com/w3ctag/design-reviews-private-brainstorming/issues/239#issuecomment-3908582396) This API has been in development for 4 or 5 years now. Yes, it needs the alternatives considered section. But this is basically in response to the deprecation of third-party cookies. This allows us to keep the use case. Front-channel communication in OIDC breaks. The proposal has flaws, Apple and Mozilla have dropped out. They are not actively blocking it, but won’t implement. So there is only Google. They are quite focused on implementation. Discussion results from Google with developers don’t come back to the Working Group. We have many explainers for this one API. The only goal is CR.

Lola: I think it’s worth bringing this up to Jeffrey to encourage participants to bring the information back to the group.

Hadley: We should add "missing multi-stakeholder support," and point it out when we get to that point.

Ehsan: This is a stepping stone for agentic browsing. But I think there must be some coordinated action across browsers.

Hadley: We can always say "we think this is bad for the Web."

Heather: Want the group to make their own technical and architectural decisions. Can talk directly to the editors, but want to be a relatively neutral chair when it comes to the technology itself.

Hadley: We can always add to the comment that you personally didn’t take part in the decision.

Yves: Also remember there is a requirement to have two implementers to progress towards Recommendation.

Heather: Not sure if the specification would adopt the needs of Apple and Mozilla if they would return.

Hadley: We can talk about it why it’s bad (https://www.w3.org/TR/ethical-web-principles/#multi)

Lola: Multiple ways we can continue. 1) We can post Ehsan’s comment. 2) The consensus in this group that this is bad for the web based on the lack of multiple implementations.

Hadley: We should talk to the entire group.

Lola: Put it to the plenary?

Ehsan: This is a hype area of discussion. Genuinely think that authentication needs to be solved at some point. Also, don’t want the TAG to be seen as blocking that effort.

Lola: Don’t think this indicates that TAG is antagonistic to Agentic Browsing. We can always weigh it against our principles. If it is socially harmful or technically harmful.

Discussed Feb 23, 2026 (See Github)

Hadley: We had a good conversation about this last week... there was consensus that this is bad for the web... waiting on Ehsan to update the proposed comment.

Ehsan: Expect to propose the comment tomorrow.

Jeffrey: I'm worried about saying this is bad for the web because the other implementations haven't adopted it - I think we should encourage everyone to adopt it, or everyone not to - others have had the opportunity to comment.

Hadley: We discussed that Jeffrey would need to be part of the discussion.

Lola: I think we may need to reword the design principle about multiple stakeholders in implementation. The design principle can't be 'it must have multiple implementations or it's bad for the web' - multi stakeholder input needs to be considered. (Ref last week's discussion.)

Ehsan: +1 to Lola. Also, as it's mentioed to be related to the agentic web, it may set a foundation for what is to come, so we really need others' input.

Heather: The point I raised last week is that the other browser developers are not active anymore. Apple never was, and Mozilla pulled out. Thus they're taking a position of 'we're not saying no, but we're not roadmapping it at this time'. FedCM as a whole is a heavyweight set of APIs. The bigger it gets without multiple implementations, the more of a challenge it is going to be.

Jeffrey: FedCM exits because of third-party cookie deprecation. Mozilla and Apple are handling it by giving undocumented exceptions to make things like login work. Chrome is trying to get federation right. The undocumented exceptions are bad for the web. We should be encouraging participation by more stakeholders. Not sure how we can do this, but we need to try.

Hadley: A good topic for the f2f.

Lola: This is part of the feedback we got on the 3pc Finding. We should liase more closely with the Privacy group. At the last meeting, seems like they review specs as they come in for horizontal review, and also is actively working on Global Privacy Control (GPC). I wonder if there's space here for them to be advocating for 3pc replacement work that is moving in the right direction.

Hadley: Last time we had a great converstation, but we didn't clarify what's happening next. Shall we do that now?

Ehsan: I think the plan was that I redo the draft comment that I did, discuss with Hadley and the whole TAG. Then post it for the proponents if it gets consensus.