Indeed the extension that provides Wikimedia's central account and login system might be affected by major changes made to the user account stack. As far as I can tell the IP masking plan hasn't been communicated to me or the other volunteers who maintain CA. Where I can read up on the plans? Is AHT planning to implement the needed changes to CA?

There was https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralAuth/ /773384, not sure if anything else is needed.

Will it be possible to lock temporary accounts? If not, CheckUser will need some changes due to this.

Related: T342475: Define temporary account behavior on Wikimedia wikis which have IP masking disabled

In T326937#8719364, @Dreamy_Jazz wrote:

Will it be possible to lock temporary accounts? If not, CheckUser will need some changes due to this.

This does currently just work (as you'd expect since it's just another account, but I've checked by testing locally too).

I haven't seen any plans to stop it from working, but there is this: T340275: Allow GlobalBlocking to block temporary accounts. When we eventually do that, should we prevent locking from CentralAuth?

In T326937#9234993, @Tchanders wrote:

I haven't seen any plans to stop it from working, but there is this: T340275: Allow GlobalBlocking to block temporary accounts. When we eventually do that, should we prevent locking from CentralAuth?

IMO we should do T17294: Allow globally blocking of accounts (which will probably also cover temporary accounts, which are basically just accounts) and T222281: Add a way to prevent user from log in and disable a users session when blocking, and then drop locking from CentralAuth. Specifically for temp users, the difference between locking and blocking probably isn't really meaningful anyway.

While T17294 seems stalled, is there anything do be done for CentralAuth in the meantime?

In T326937#9449629, @ArielGlenn wrote:

While T17294 seems stalled, is there anything do be done for CentralAuth in the meantime?

Just the usual things (which special pages and actions are accessible to temp users, what user management things they can be the target of) I think. The authentication logic was updated in T342475: Define temporary account behavior on Wikimedia wikis which have IP masking disabled, and global user groups are about privileged users so they are not affected. We should probably disallow global renaming of temp users.

@Tchanders should Special:CentralAuth/<username> be any different for temp users? E.g. show when the account will expire?

@Tgr We hadn't made any specific plans about showing anything different on Special:CentralAuth. But if we can reliably calculate expiry time (and also whether an account has expired) I can see that'd be helpful. FAO @Madalina too.

In theory the expiry time is registration date plus $wgAutoCreateTempUser['expiryAfterDays']. In practice expiry is done with a maintenance script so the exact timing is unpredictable, but I don't think a small inaccuracy matters. We use the same date logic to show the temp users themselves a warning.

I don't think there's a good way to accurately tell whether an account is expired right now, other than guessing from the date. We expire them by invalidating the session; from the system's point of view the account is in a normal state, the user just doesn't have any session cookie to access it anymore. So I wouldn't show something like "this account has expired" because for that there's more expectation to be 100% correct. But "expires on <day>" seems OK to me.