FedCM: Sign-In-With-Big-Tech-Only or Sign-In-With-Whom-I-Prefer?
New web standard proposed by Google for slicker Sign-In-With buttons props up Big Tech and undermines the independent social net. Let's fix that.
TL;DR: Web identity and open-tech activists needed to steer new Sign-In-With standard FedCM to support user choice of identity provider.
For the attention of federated systems developers, including Matrix, Fediverse and others.
It may be good to know about an issue going on with FedCM “Federated Credential Management” draft spec. Liquid Surf brings it to the attention of all federated systems fans in their blog post: Can FedCM improve the user experience of decentralized ecosystem ? . In short, the spec aims to make a slicker browser flow for the Sign-In-With-Xxx buttons.
To us who care about federated computer infrastructure, introduction of a new standard to streamline the sign-in flow might seem minor and remote, but there is a catch.
What Is FedCM?
FedCM, short for Federated Credential Management, is a new draft specification for web browsers, published by the Federated Identity Community Group and strongly driven by teams from Google. It represents an advancement in how websites manage user logins, when logging in through different identity providers (such as “Sign in with GitHub/Google/etc.”) while preserving user privacy... — Liquid Surf: Can FedCM improve the user experience of decentralized ecosystem ?
The Catch
The critical issue is, at present, the draft standard is likely to cement the monopolies of the big providers (like Google and Facebook) and leave out small providers. In short, the problem is the draft spec says the site we're logging into (called the RP) solely dictates what list of identity providers should be offered to the user. What will happen in that case? Most sites will offer only the BigTech identity providers. Read the blog post and the issue Allow IDP registration #240 for details.
... End Users looking to opt out of the limited federated identity login options available today are required to significantly compromise convenience because they are forced to manage a new set of credentials directly with the relying party, creating friction and usability challenges.
... Currently the proposed FedCM API ... assumes the relying party specifies a set of IDPs it supports login from. This model is largely a continuation of that described above and in many respects is just a browser mediated version of what we see most commonly on the web today.
What to do about it?
The proposal in Allow IDP registration #240 is, in short, not to have the RP site solely dictate what list of identity providers should be offered, but also to let the browser register the user's chosen identity providers and present those as options when a new login is requested.
... instead of the Relying Party specifying the IDPs it supports in the federation request, it communicates the capabilities it supports such as signature schemes, assertion formats and response modes. End-Users can then register providers they wish to use with the browser, which are then available as options to present to the End-User ...
Why Do We Need to Help?
(As I responded to '@thhck' in #fediverse:pixie.town)
The proposing team are saying lack of feedback from developers is holding back the acceptance of this extension.
Decentralising ID providers is key to the whole decentralised movement, including Fediverse, Matrix, self-hosters as well as the ability for independent businesses to provide comprehensive IT services without one of the tech giants playing gatekeeper.
We, all of us who care about federated/decentralised infrastructure, now need to push the draft Federated Credential Management “FedCM” standard to support “Sign In With” the user's choice of identity provider (which may be small, local, independent, hosted by one's school or enterprise or self, and so on). If this extension to the proposal does not get enough support to be accepted, we might get a standard that perpetuates the status quo of sites only offering Sign In With the giants like Google/Github/Facebook, ugh. That would be another death blow for user agency and privacy and variety.
Get Involved
Fedi devs, let's demo this truly user-centric version of FedCM, show us how awesome it is! Fedi fans, this might seem remote from our viewpoint but it's important for our future. Let's share this issue more widely among Fedi projects!
Please join us to discuss this:
- Allow IDP registration #240 (in Github)
#fedcm-user-choice:trax.im(chat via Matrix)- Federated Credentials API: Developer feedback needed (SocialHub Discourse forum)
- W3CCommunity channel (in Slack)
See contributing to FedCM and the Meetings of W3C Federated Identity CG. Agendas and minutes are public, and interested parties are being invited to present their case for making this extension.
Read more:
- FedCM “Federated Credential Management” draft spec. — central place for development of the spec — on Microsoft-Github
- Allow IDP registration #240 — the extension we need to drive forward for user choice
- Federated Credential Management API — W3C Draft Community Group Report, 19 January 2024
- issue #240 comment mentioning lack of feedback from developers
- The Downside of Conveniently Signing In With Google, Facebook, Twitter, or Apple — for context about (lack of) user choice — gizmodo, 2020-09
- On FedCM's (un)suitability in Research and Education federations — Jisc Trust & Identity Services Blog, 2024-01
[EDITS: removed announcement of past meetings; added logo, quotes, TL;DR, call-outs, links; many text edits]
[Image source file, as Inkscape SVG: fedcm-my-choice-1.svg]
