Image created by Julian Foad, @julianfoad .
The W3C Federated Identity CG is working on Federated Credential Management Web Platform API specification. One of the issues is that the authors may focus mostly on Big Tech identity providers. So folks working to use Solid wrote an article, and there’s a Github issue to allow IDP registration, give any provider a chance in this mechanism. Julian Foad summarized all that in another article FedCM: Sign-In-With-Big-Tech-Only or Sign-In-With-Whom-I-Prefer? .
The Community Group is seeking developer feedback, so if any of you are working/interested in the subject, either from Fediverse or other background, then participate on the GH issue, or alternatively respond on the fedi to Sam Goto of the Google Chrome team.
Here is a direct link to the Github issue:
opened 02:42AM - 31 Mar 22 UTC
design
early interest
TL;DR there is a significant amount of context at the start of this issue before… we get to the proposal, here is a [google doc version](https://docs.google.com/document/d/1zxRFhF6qwGTCOYZ6UwTutbXVyRiD3krXyfFkcp_6t98/edit) for an alternative form.
# Background
The origins of many federated identity technologies have deep ties to providing an open ecosystem of IDPs to give End Users ample choice in how they choose to “login”. Efforts like OpenID v1 and v2, SIOP, Mozilla Persona, CHAPI, and others, strongly embodied these principles and much of this has remained in future revisions of standards such as OpenID Connect core. However, due to numerous complex issues, much of the industry today, primarily around the “social login” market has consolidated leaving a few IDPs as the dominant market players. To counteract this, FedCM in this work on establishing new browser mechanisms for supporting federated identity has an opportunity to make a meaningful impact and help re-chart the course for the future of federated identity on the web.
In the landscape of today, the choices around federated providers an End-User has available to them when going to “login” on the web is most often a small curated list of IDPs pre-determined by the Relying Party.
One of the main market forces that influences the options an End-User is presented with is often referred to as the NASCAR problem (https://github.com/fedidcg/FedCM/blob/main/explorations/related_problems.md#the-nascar-flag-problem). In order for a relying party to keep the UX on their login page from being overwhelming, they must pick a small number of IDPs to support (usually 2-3). How this decision is made by a relying party can be complex, but one major driving factor that applies to many is the existing user-base a particular IDP offers. Often the larger the user base, the more likely the relying party is in its desire to support it. This is because the relying party wants to offer as few login options as possible that services the largest possible user-base for them. This factor makes it difficult for new competition in the IDP side of the federated identity landscape, especially for entities that don’t have large pre-existing user-bases.
Who an IDP is, is often also important to factor in. As federated login technologies have developed, companies who built successful social networks, ISPs and commonly used search engines had the large user bases that made them attractive as IDPs to many Relying Parties. These IDPs have been very open about their interests in performing the IDP role, where the access it gives them to information about End User behavior, often supports their primary business models. In this context, concerns about user tracking are very real.
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.
This equation in many cases has led to End Users using federated login options, trading off concerns such as the fear of being tracked by a particular IDP, for the convenience it offers. As a result, Relying Parties seeking large user bases continue to converge on the dominant IDPs and End User choice is further diminished. We end where we are today, in a self-reinforcing loop dominated by extremely limited choice at logon.
What we need to support instead is a federated login model that re-introduces the End-User into the mediation process so they can have more of a say on which provider they use and where.
# Proposal
Currently the proposed FedCM API is focused around a browser mediated approach that 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.
Many Relying Parties will want to continue in a model where they specify the IDPs they support.
**The challenge is for when this is not the case, to provide a viable way to achieve more End-User choice, greater inclusiveness, increased competition, and reduce vendor lock-in around the IDP options available.**
In this proposed additional model, 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 when they go to login. This is enabled through the following two step process
1) Registration Step - The End User navigates to the IDP they want to use, prior to attempting a login with an RP and registers it for use in the browser.
2) Login Step - Later when the End User goes to login with a particular RP that supports this open IDP model, instead of the End User being presented with a pre-set list of IDPs determined by the RP, they are presented with a list of IDPs they have registered to use that support the capabilities required by the relying party.
**Note** - To prevent a scenario where a relying party is supporting this login model but no IDPs have been previously registered in the browser, the relying party could provide IDP hints.
# Conclusions
Considering the cited basis for FedCM is to “preserve and elevate identity federation” please strongly consider adopting this in your work. Choosing this path would have a meaningful positive impact on federated identity on the web by improving the choices End-Users have to login on with. Ignoring this issue risks the continued consolidation of options available for End-Users and therefore undermining its value as a means of login.
# Acknowledged Challenges
- What happens to an end user when their registrations are wiped?
- What happens if an end user has forgotten what IDP they use where?
- Can a significant enough portion of relying parties trust login assertions from an IDP for which they don’t have a pre-existing trust relationship?
- How are the capabilities supported by the RP communicated to the browser
# Prior Art
[CHAPI](https://w3c-ccg.github.io/credential-handler-api/)
[Mozilla Persona](https://wiki.mozilla.org/Identity/Persona_AAR)
[Account Chooser](https://github.com/openid/accountchooser.com)
[OpenID](https://openid.net/specs/openid-connect-core-1_0.html)
Raised with @dmitrizagidulin
2 Likes
@erlend_sh had some really nice follow-up news wrt this topic today:
Boosts of that post as well as interaction in the various GH discussion/issues most welcome.
2 Likes
