The two likely follow-up tasks are T364939: Provide a JavaScript library for logging in / signing up to MediaWiki via a popup and T364941: Use a popup as the default login flow in MediaWiki when appropriate.

secure.wikimedia.org used to work in a similar way until it was replaced by T22643: Serve SSL/HTTPS sites out of same domain names as HTTP access: https://en.wikipedia.org/ (in 2013, I think?). It was implemented as an Apache proxy (still is, to some extent, to support old links).

There are two implementation strategies I can think of for such a shared domain:

1. At the traffic level: ATS redirects sso.wikimedia.org/foowiki/path to foo.wikipedia.org/path so the target wiki mostly doesn't even notice what's going on (to some extent MediaWiki needs to be aware so I imagine we'd set a custom header).
2. At the configuration level: CommonSettings.php applies some special logic when it determines from the hostname what DB name / wiki ID to use.

Unassigning this since @DAlangi_WMF is working on the more specific task T363483, and this is probably too large to be assigned anyway.

You need to confirm the email address (via the button at the bottom of Special:Preferences, or the email you get right after signup, or by using shell.php and doing something like MW::user('my-username')->confirmEmail()). Although you should still have an email field without that, it's just empty. And other data is missing too (the response should have fields like confirmed_email, registered, rights) so I assume this data is already somewhat post-processed?

Note that "JSON Schema" is not a single well-defined thing, there are several slightly incompatible versions of it (Draft-04, Draft-06, Draft-07, Draft 2019-09, Draft 2020-12 - with, at least in the PHP world, tooling being somewhat sluggish to catch up with changes, so when people talk about "JSON Schema" it's not at all obvious that they mean the latest version of the spec). Either that should be configurable or (more realistically) we should choose what schema version MediaWiki uses, and document it clearly.

In T335851#8869692, @RhinosF1 wrote:

First-Party sets would also be useless to Miraheze as custom domains could take weeks to be added and need manual work. It looks like sets have to be reviewed and shipped in a chrome profile.

The current code uses WebResponse::setCookie() which will result in cookie values like backend%3Dmwdebug1001.eqiad.wmnet%3Blog%3Bexpire%3D1715464158. Varnish itself does not need to know the values of the various flags within the cookie, but it does need to decode them because ATS is expecting unencoded plain text in the X-Wikimedia-Debug header (the logic is here. I think we are fine decoding only ; and =, as long as we are careful not to make changes on the PHP side.

The API payload is "pubKeyCredParams": [ { "type": "public-key", "alg": -7 } ] which per the spec is ES256. Maybe a Chrome bug?

In T363035#9786792, @RHo wrote:

While it does seem this change to warning instead of notice seems to have occurred at some point recently as it was initially styled as the neutral notice T87261

See also T72624: Consolidate page moving code in one place (Renameuser now in core, plus GlobalRename and UserMerge extensions).

Probably relevant for the planned incident reporting system.