Actually it is less than that because people can have more than one passkey.

wikiadmin2023@10.64.0.47(centralauth)> SELECT oat_name, count(*) FROM oathauth_devices JOIN oathauth_types ON oad_type = oat_id GROUP BY oat_name;
+----------+----------+
| oat_name | count(*) |
+----------+----------+
| totp     |     2367 |
| webauthn |      185 |
+----------+----------+

wikiadmin2023@10.64.0.47(centralauth)> SELECT COUNT(DISTINCT gu_name) FROM oathauth_devices JOIN oathauth_types ON oad_type = oat_id JOIN globaluser ON oad_user = gu_id WHERE oat_name = 'webauthn';
+-------------------------+
| COUNT(DISTINCT gu_name) |
+-------------------------+
|                      76 |
+-------------------------+

Do we currently store which domain a credential was set up on?

I think the way to go here is to keep the current login system and the SUL3 login system working in parallel for a while and ask the WebAuthn users to migrate. They won't be able to use SUL3 initially, since their passkeys won't work on loginwiki, but they can log in with the old process, disable the passkey, go to loginwiki, set up a new passkey, and use that with SUL3. Not the most straightforward but WebAuthn users are very likely technically proficient so I think it's fine.

In T354701#9718392, @taavi wrote:

Do we currently store which domain a credential was set up on?

Not in any way that would be obvious to me. The WebAuthn data mainly consists of three binary strings, userHandle, publicKeyCredentialId and credentialPublicKey, none of which sound like further information could be extracted from them.

In T354701#9718408, @Tgr wrote:

I think the way to go here is to keep the current login system and the SUL3 login system working in parallel for a while and ask the WebAuthn users to migrate.

Specifically:

• Add a WebAuthn config flag to disallow creating new credentials, and enable it
• Email all users with current credentials and ask them to disable WebAuthn and use TOTP for now
• After the new login system is live, re-enable credentials creation on the central login wiki only.

Users who ignore the emails won't be able to log in with the new login system. (The old one will be available as a fallback for a while so they won't get locked out.) I think this is preferrable to remove their 2FA without their consent.

@Reedy @taavi what do you think?
(BTW if we think WebAuthn is just not ready and should be rolled back, that should probably be decided first and be included in the messaging.)

This definitely feels a simpler workflow than implementing (temporary) hacks and redirects and workflow changes to support the migration, especially for such a relatively small number of users.

Of course, if we can also get T242031: Allow multiple different 2FA devices over the line and useable, people could have WebAuthn and TOTP...

In T354701#9718408, @Tgr wrote:

They won't be able to use SUL3 initially, since their passkeys won't work on loginwiki, but they can log in with the old process, disable the passkey, go to loginwiki, set up a new passkey, and use that with SUL3. Not the most straightforward but WebAuthn users are very likely technically proficient so I think it's fine.

^ I don't think this is unreasonable for a one time request.

I'm definitely not against asking them to move to TOTP; I don't know if we're going to cause any problems where people may be able to do something that WebAuthn supports, but cannot do TOTP. I suspect we won't know until we ask.

Ideally we have a "deadline" (or target) date, and then can re-evaluate the quantities at that point, potentially digging in further to specific user groups, or explicitly poking certain people. The date helps deal with some of the procrastination, but won't catch everyone.

• Add a WebAuthn config flag to disallow creating new credentials, and enable it

This makes sense as we can also leave it enable on private wikis for people to continue using, without any necessary changes.

Considering most of the big issues with WebAuthn is due to not being able to login to "other" wikis, it will fix that big pain point.

In T354701#9718392, @taavi wrote:

Do we currently store which domain a credential was set up on?

In T244088#5871932, @ItSpiderman wrote:

I have tested this and can confirm the issue. RP id (domain in this case) is baked into the credential so there is no way to use the same key on multiple domains currently.
What we could do is t make relying party id configurable, so that all wikis using the same DB could set the same key, and therfore use the same keys between each other.

In T354701#9753380, @Reedy wrote:

I don't know if we're going to cause any problems where people may be able to do something that WebAuthn supports, but cannot do TOTP.

I think the only thing like that would be a hardware key, and someone owning a hardware key but not owning a mobile device seems unlikely.

In T354701#9718392, @taavi wrote:

Do we currently store which domain a credential was set up on?

In T244088#5871932, @ItSpiderman wrote:

I have tested this and can confirm the issue. RP id (domain in this case) is baked into the credential so there is no way to use the same key on multiple domains currently.

It is baked into it (in the sense that the browser can validate that the credential was created for that domain), but is it retrievable from it? I think it's just a signature calculated from some data structure. The FIDO CTAP spec doesn't quite spell that out, but it does say that the credential is opaque to the host.

Do you have any (even rough) estimates of when the new system using loginwiki would be ready to be used? I feel like if we're going to mass-message people about this it would be nice to have anything more than "sometime hopefully relatively soon".

In T354701#9755324, @Tgr wrote:

In T354701#9753380, @Reedy wrote:

I don't know if we're going to cause any problems where people may be able to do something that WebAuthn supports, but cannot do TOTP.

I think the only thing like that would be a hardware key, and someone owning a hardware key but not owning a mobile device seems unlikely.

I would concur, but I don't want to completely assume this :)

In T354701#9755335, @taavi wrote:

Do you have any (even rough) estimates of when the new system using loginwiki would be ready to be used? I feel like if we're going to mass-message people about this it would be nice to have anything more than "sometime hopefully relatively soon".

A quarter, maybe two.

With multi-credentials support about to land, we could also just ask them to make sure they have a version of their verifier bound to login.wikimedia.org; but if T363695: Create a Wikimedia login domain that can be served by any wiki pans out, that would not be the right domain. Can they just use wikimedia.org? That's just a config change at this point, right? (Or would such a config change break existing credentials?)

Change #1029534 had a related patch set uploaded (by ArielGlenn; author: ArielGlenn):

[mediawiki/extensions/WebAuthn@master] Add ability to disable registration of new keys or enabling the module

https://gerrit.wikimedia.org/r/1029534

Change #1029512 had a related patch set uploaded (by ArielGlenn; author: ArielGlenn):

[mediawiki/extensions/OATHAuth@master] add a check if a module is available for enabling

https://gerrit.wikimedia.org/r/1029512

Change #1029512 merged by jenkins-bot:

[mediawiki/extensions/OATHAuth@master] add a check if a module is available for enabling

https://gerrit.wikimedia.org/r/1029512

Change #1029534 merged by jenkins-bot:

[mediawiki/extensions/WebAuthn@master] Add ability to disable registration of new keys or enabling the module

https://gerrit.wikimedia.org/r/1029534