Communities currently make rules about what account names may be created on their projects, before overriding their decisions by allowing a trivial automatic bypass of their controls on WMF servers this should have a global RFC.

In a more extreme proposal (https://www.mediawiki.org/wiki/User:Legoktm/evil-plans2.txt) the "local account" concept would be eliminated completely.

We should probably talk to the Anti-Harassment team and stewards and think though the implications of this - we might need better tooling against abuse that can be done just by account autocreation (e.g. spamming the logs with abusive usernames). But in general I thing this would be the way to go - local wikis being able to prevent account creation was always a bad idea that only exists accidentally. It's only possible because "central accounts" aren't truly central, which isn't where we want to be in the long term.

For account creation, we probably still want to prevent usernames that do not comply with the local policy, because it's far better to tell users about account creation than forcing them to request a rename or abandon the account. For autocreation, maybe we could add the ability to show a warning that the user's account is violating local policies, or send an Echo notification (more reliable as the autocreation can be triggered by an AJAX request, especially on Wikidata or Commons).

In T354487#9439710, @Xaosflux wrote:

before overriding their decisions by allowing a trivial automatic bypass of their controls on WMF servers this should have a global RFC.

It would need some sort of consultation. We don't generally use RfCs to make decisions about software architecture, though (well, we used to, but that was a different kind of RfC).

We don't generally use RfCs to make decisions about software architecture, though.

That's the problem. You see this as a software architecture decision. Xaosflux (and others like myself) see it as a community policy decision instead.

I mean it's both, but what is or isn't feasible to build is going to limit the range of available choices. Policy choices that lead to impossible or unmaintainable software are bad policy choices, and I don't think it's possible to arrange a global RfC where participants can really take the feasibility of various software design choices into account. That's why the software exception in WP:CONEXCEPT exists.

Anyway, at this point I don't think we have a good understanding of feasibility ourselves (not so much of this task, specifically, but how it would fit into the wider set of changes needed to migrate authentication flows to a central wiki) so I think this discussion is a bit premature. Concerns duly noted, let's get back to them once we have a better idea of how the authentication framework would have to be changed.