#974: FedCM's IdP Registration API

Visit on Github.

Opened Jul 9, 2024

This came up recently in a discussion with the TAG and @plinss, of an extension to FedCM that is both (a) early and (b) could use early directional guidance from the TAG. Side note, also discussed in the discussion with the TAG: I'm glad that Chrome's Process points to Early Tag Reviews at the Devtrials stage, which I think is (a) exactly when we'd want to get early tag guidance and (b) where this specific API is at.

こんにちは TAG-さん!

I'm requesting a TAG review of FedCM's IdP Registration API.

One of the problems on the web is that users are currently constrained by a small set of social login providers to login to Websites. Websites, in turn, are constrained by finite space in login flows, so they typically have to pick 2-5 large social login providers (e.g. facebook, google, twitter, linkedin, github, etc) that can represent a large fraction of their users, but, by construction, not all of them.

This is a proposal to increase user choice by allowing RPs to request any IdPs that the user has chosen to register.

  • Explainer¹ (minimally containing user needs and example code): explainer forked out of this thread
  • User research: not yet available
  • Security and Privacy self-review²: not yet available
  • GitHub repo: same as explainer
  • Primary contacts (and their relationship to the specification):
    • Sam Goto, @samuelgoto, Google Chrome
  • Organization/project driving the design: FedID CG, Indie Web community, Solid community
  • External status/issue trackers for this feature (publicly visible, e.g. Chrome Status):

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): FedID CG/WG
  • The group where standardization of this work is intended to be done ("unknown" if not known): FedID WG
  • Existing major pieces of multi-implementer review or discussion of this design: url
  • Major unresolved issues with or opposition to this design: See open questions here.
  • This work is being funded by:

You should also know that...

[please tell us anything you think is relevant to this review]

CAREFULLY READ AND DELETE CONTENT BELOW THIS LINE BEFORE SUBMITTING

Please preview the issue and check that the links work before submitting.

In particular:

  • if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document. We would prefer public documents though, since we work in the open.

¹ For background, see our explanation of how to write a good explainer. We recommend the explainer to be in Markdown.

² Even for early-stage ideas, a Security and Privacy questionnaire helps us understand potential security and privacy issues and mitigations for your design, and can save us asking redundant questions. See https://www.w3.org/TR/security-privacy-questionnaire/.

Discussions

Comment by @samuelgoto Sep 17, 2024 (See Github)

From todays minutes:

https://github.com/w3ctag/meetings/blob/gh-pages/2024/telcons/09-16-agenda.md#logistics https://cryptpad.w3ctag.org/code/#/2/code/view/9bPjNIDj4hX6pAkIA3hIgTaa8q57Mr+wssssQctYrww/

Peter: One thing I would like to see: FedCM not tied to speciic IDPs. I'd love to run my own personal IDP and use that to log in everywhere... Scared of a FedCM world where only a few top IDPs are used... Hadley: I'm with you but if I'm a RP don't I choose who I'm going to trust? Peter: yes - not sure how to reconcile... FedCM allows you to "bring your own IDP".. but RP cant just trust any old IDP... Matthew: +1 to both Peter and Hadley... Just to say that we both briefly touch on this in discussion with Sam ... we did touch on that in this meeting... minutes from last f2f

@torgo, @hadleybeeman, @plinss I just wanted to note that this early TAG review that we filed hopefully can add some clarity to some of the intuition that we are forming that matches what you discussed today. No particularly rush from my side to review this, but just wanted to send a review that should support your discussion, in case that's helpful.

Comment by @martinthomson Mar 4, 2025 (See Github)

Hey @samuelgoto, I know that this has taken a while, but we're curious as to what has been done in the last 8 months or so. Is this still an active proposal?

One thing that we observe is that the permission to act as IdP seems a bit unnecessary. Why would a browser not just store the IdP's willingness to act as IdP (maybe after checking it)? That shifts some burden to the login phase, but we think that could be easily managed (in the extreme case, with a search).

This engagement with a user also creates a presumption that the IdP would be usable, when that isn't really true, because each RP will have their own rules about what IdPs they accept.

Comment by @samuelgoto Mar 4, 2025 (See Github)

but we're curious as to what has been done in the last 8 months or so. Is this still an active proposal?

This is still an active proposal.

It somewhat depends on the multi-idp proposal (i.e. the browser needs to be able to handle "many" IdPs, because there can be "many registered" IdPs), so we have been focusing on that first. Chrome has since put the multi-idp proposal in origin trials and we have a corresponding spec PR, so I think what was most blocking us looking into the IdP Registration API is starting to get resolved.

I think, however, that apart from the product dependencies (that, as i said, are starting to get resolved), we are not gathering as much of a sense that the ecosystem is actually ready or needing this ... specifically, we are not seeing relying parties be as excited about this as we were hoping for ... and, in as much as browsers want to make this happen, relying parties have to vote with their feet here for this to materialize (i think IdPs are generally going to be incentivized). So, yet to be seen if this is economically viable.

It might be that this is a chicken and egg problem, where RPs need enough BYOIDP IdPs to use it, but, anyway, we are yet to figure out how to break this cycle.

One thing that we observe is that the permission to act as IdP seems a bit unnecessary.

Yeah, that occurred to us.

Why would a browser not just store the IdP's willingness to act as IdP (maybe after checking it)? That shifts some burden to the login phase, but we think that could be easily managed (in the extreme case, with a search).

Yeah, so that's a plausible outcome, and one that I think could be a possible end state here. You are right that there is no privacy / security violation here.

I think, as you may have already noted by your "search UI", the problem is abuse: if any website that you visit can "claim" that it is an IdP, than it is possible that we'll live in a world where a lot of them would (just to show up in login dialogs).

So, yeah, I think you got that right: we added the prompt exclusively so that we can prevent abuse (seemed much simpler than a search UI and met, so far, the requirements that small IdPs have - where convincing a user to "register" isn't that big of a deal).

So, yeah, I think we are open to exploring other forms of preventing abuse, including not having the prompt at all and a Search UI.

This engagement with a user also creates a presumption that the IdP would be usable, when that isn't really true, because each RP will have their own rules about what IdPs they accept.

Interoperation between RPs and IdPs I think we know how to solve with this.

Comment by @samuelgoto Mar 6, 2025 (See Github)

One thing that we observe is that the permission to act as IdP seems a bit unnecessary.

Here is another idea that occurred to us early on:

https://github.com/w3c-fedid/idp-registration/issues/18

Discussed May 26, 2025 (See Github)

Skipped.