Any chance IndieBits would be interested in allowing users creating accounts with their own IdP?

samuelgoto · April 26, 2024, 8:01pm

I’m working on an extension to FedCM that would allow anyone to bring their own IdP to create accounts on other websites, and I’m wondering - given the recent engagement in [1] - if IndieBits would be interested in co-designing this API with us by using the FedCM API with the “any” option.

Any chance this would be interesting to this community?

github.com/fedidcg/FedCM

Allow IDP registration

opened 02:42AM - 31 Mar 22 UTC

tplooker

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. ![image](https://user-images.githubusercontent.com/15972525/160963891-b2531e42-c847-4eb9-ad9d-2351f732836a.png) 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. ![image](https://user-images.githubusercontent.com/15972525/160963995-d8c0273c-4b7a-4814-8bbb-fe9bb90a1643.png) 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. ![image](https://user-images.githubusercontent.com/15972525/160964047-69b7c170-28e9-4180-acde-7bbed658f5b5.png) 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. ![image](https://user-images.githubusercontent.com/15972525/160964115-0eca6bf6-cd24-45b1-9d89-ac37338ad973.png) 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. ![image](https://user-images.githubusercontent.com/15972525/160964201-e2d81fc1-7030-466e-b19b-3c109f30de73.png) 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. ![image](https://user-images.githubusercontent.com/15972525/160964310-84f0c917-ee75-4da6-ac93-d8d94cb137d8.png) **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. ![image](https://user-images.githubusercontent.com/15972525/160964237-2c9c7146-907e-4947-9ccc-2c287fc667af.png) # 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

[1] Maybe the token format should be specified? · Issue #561 · fedidcg/FedCM · GitHub

anders · April 29, 2024, 7:51pm

Hi @samuelgoto! Sorry for the late response. Had a long weekend and was traveling.

First of all, I really appreciate the work you’re doing with FedCM and would love to help get it off the ground.

I’m definitely interested in building a prototype. However, I’m not sure IndieBits would be the best place to do it. The first problem is this is currently a rather small community. It mostly consists of people coming here for support for boringproxy and TakingNames.io. There aren’t a lot of conversations happening outside of that. I hope that changes over time, but it’s the current reality.

The second problem is that IndieBits currently runs on Discourse, which I would prefer to move away from in the future. Discourse is awesome, but it’s complex, slow, and written in Ruby. What I’d really love to have is a simple forum built on ActivityPub. I’ve started working on a prototype but it’s just a small side project at the moment with relatively low priority.

In any case, I don’t know Ruby and would prefer not to learn it just to implement a feature/plugin for Discourse.

I would be much more likely to implement this for LastLogin.io (which runs on obligator), but I’m not sure that would be much help either. It’s already confusing enough that LastLogin stands between you and Google/GiHub/etc. If it stood between you and something completely new like FedCM it might be very confusing for users.

That and LastLogin doesn’t have many users either, so again not sure it’s bringing much value to your mission.

My suggestion would be to find a popular open source project with users that are likely to appreciate FedCM, and the project would be open to having this implemented. If you can find such a project written in Go or Rust I would be open to working on a prototype. Perhaps something that is primarily self-hosted would be useful. You might also consider reaching out to Tailscale. They support BYO OIDC with WebFinger, which is already way more than most. Also a log of ex googlers there.

Meanwhile, if I build FedCM IdP support into LastLogin, that would give those users a login provider to use.

I really do think we need something like FedCM and I’m motivated to help make it happen. I’ll try to think if I can come up with any candidate projects as well. @erlend_sh @zicklag any ideas?

erlend_sh · April 29, 2024, 9:01pm

We are working on setting up Weird (backed by Rauthy) as a minimal Identity Provider.

We will test that against a linkblocks instance as a Relying Party. That’ll happen in two stages:

First, ‘Login with Weird’ as just another baked-in option for regular OIDC login, alongside Google/GitHub.
Then, via FedCM.

Once we’ve proven this out, we’ll submit the same kind of PR combo as a draft to a Relying Party that’s actually running in production; most likely Omnivore, which we’ve contributed a bit to already. Will probably take a while to get that approved for production use, but I don’t see much getting in the way of a working proof-of-concept.

I’ve chatted a bit with the maintainer of Shiori and he’s also quite receptive to these ideas. That could be another good candidate for a FedCM PR. Miniflux is also a good candidate.

samuelgoto · May 1, 2024, 10:58pm

The first problem is this is currently a rather small community.

I’m thinking that this is a feature, not a bug: a small (but tech savy) community may have more the inclination to bring their own identity than a large / ossified one.

I really do think we need something like FedCM and I’m motivated to help make it happen. I’ll try to think if I can come up with any candidate projects as well.

I appreciate the kind words and I’d love to find ways for our communities to work together! LMK if anything occurs to you and I’d love to reconnect to find ways to work together!

Best of luck, Sam