Ideally we will also be able to prevent users from enabling passkeys unless they are using a physical device.

Any particular reason?

In T399665#11008747, @Reedy wrote:

Ideally we will also be able to prevent users from enabling passkeys unless they are using a physical device.

Any particular reason?

Not all passkeys are syncable and we want to avoid having inexperienced users using a feature that is still in very early development unless they actually know how to use it

I proposed this as a temporary step after talking to @EMill-WMF (but to be clear I didn't run this exact proposal by him yet, so he should weigh in). @EMill-WMF said that we should discourage people from setting up non-portable passkeys (ones that are only in one browser / on one device and are not in a password manager or similar), because the risk of getting locked out is too high, especially while we don't support multiple authenticators and don't provide recovery keys when a passkey is set up. Once we support multiple authenticators, we could then allow non-portable authenticators to be set up as long as the user already has a portable auth method (either a portable passkey, or a hardware key, or a TOTP-based method).

So I suggested we take the following steps:

• Change the current WebAuthn method to only allow physical hardware keys (if possible)
• Rename it to something clearer that is scoped to hardware keys. Users don't know what "web authentication" means, but they at least have a chance of knowing what "hardware key" and "passkey" means, so rename it to "physical security key" or something.
• Rewrite the description to be clearer and less scary, and to focus on how it's meant to be used (with a physical security key). We don't need it to be obscure and scary-sounding to scare away casual users if it's clearly labeled as requiring a hardware device, because the casual users we want to scare away will understand that they don't have that hardware device. (We would still need to explain any other gotchas/risks.)
• Improve the WebAuthn infrastructure so that we can make it less scary to use, e.g. by fixing T244088: Logging in at another wiki than WebAuth was set up fails, and update the warnings accordingly
• Once we have good passkey support (T321708), and we also have multiple authenticator support and have separated out recovery keys (T244348 / T232336), make passkeys available again, but present it to the user as a separate authenticator type. Hardware keys and passkeys both use WebAuthn under the hood, but users don't think about it that way, and they shouldn't have to. At this time, implement whatever restrictions we want/can on syncable vs non-syncable passkeys, or require the user to first set up another method before they set up a passkey

In T399665#11010208, @Catrope wrote:

I proposed this as a temporary step after talking to @EMill-WMF (but to be clear I didn't run this exact proposal by him yet, so he should weigh in). @EMill-WMF said that we should discourage people from setting up non-portable passkeys (ones that are only in one browser / on one device and are not in a password manager or similar), because the risk of getting locked out is too high, especially while we don't support multiple authenticators and don't provide recovery keys when a passkey is set up. Once we support multiple authenticators, we could then allow non-portable authenticators to be set up as long as the user already has a portable auth method (either a portable passkey, or a hardware key, or a TOTP-based method).

So I suggested we take the following steps:

• Change the current WebAuthn method to only allow physical hardware keys (if possible)
• Rename it to something clearer that is scoped to hardware keys. Users don't know what "web authentication" means, but they at least have a chance of knowing what "hardware key" and "passkey" means, so rename it to "physical security key" or something.
• Rewrite the description to be clearer and less scary, and to focus on how it's meant to be used (with a physical security key). We don't need it to be obscure and scary-sounding to scare away casual users if it's clearly labeled as requiring a hardware device, because the casual users we want to scare away will understand that they don't have that hardware device. (We would still need to explain any other gotchas/risks.)
• Improve the WebAuthn infrastructure so that we can make it less scary to use, e.g. by fixing T244088: Logging in at another wiki than WebAuth was set up fails, and update the warnings accordingly
• Once we have good passkey support (T321708), and we also have multiple authenticator support and have separated out recovery keys (T244348 / T232336), make passkeys available again, but present it to the user as a separate authenticator type. Hardware keys and passkeys both use WebAuthn under the hood, but users don't think about it that way, and they shouldn't have to. At this time, implement whatever restrictions we want/can on syncable vs non-syncable passkeys, or require the user to first set up another method before they set up a passkey

Big +1 to this! As a fairly standard user looking at the current UX, I have been easily confused by the difference between security keys, passkeys and web authentication. I like your suggestion of the phrase "physical security key" because until it was explained to me I hadn't realised it was a physical device.

It doesn't have to be a physical device, but we're proposing to currently limit passkeys to physical devices until we get proper Web Authn support

Change #1172423 had a related patch set uploaded (by Mstyles; author: Mstyles):

[mediawiki/extensions/WebAuthn@master] Restrict passkeys to ROAMING

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

Passkeys can be restricted to either roaming authenticators or attached authenticators (stored in browsers). For now we can restrict the passkeys to roaming which will allow users to use a yubikey or their phone or another physical device. It's not clear how this change will impact existing users. More testing is needed to determine that.

After testing on PatchDemo, it doesn't seem that existing browser based passkeys are impacted.

Change #1172719 had a related patch set uploaded (by Mstyles; author: Mstyles):

[mediawiki/extensions/WikimediaMessages@master] Update message for WebAuthn Physical Device Change

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

Change #1172719 abandoned by Mstyles:

[mediawiki/extensions/WikimediaMessages@master] Update message for WebAuthn Physical Device Change

Reason:

Abandoning my change in favor of 1135091, which removes the overrides completely and then will allow the message in the WebAuthn Extension to be shown

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

Before the patch:	After the patch:

(Chrome on Ubuntu. This is in incognito mode but the behavior is the same in normal mode as well.)

In T399665#11033242, @Mstyles wrote:

For now we can restrict the passkeys to roaming which will allow users to use a yubikey or their phone or another physical device.

Wrt accidentally locking yourself out, this will help in the situation where the user sets up 2FA on a desktop computer and then needs to log in on a different desktop computer. What happens if the user sets things up on a desktop, chooses their phone as a roaming device (as most people probably will), and then needs to log in on the phone? Can the mobile browser use its current platform as a roaming authenticator?
What about the opposite direction (I want to set it up on the phone and will need it elsewhere)?

For splitting into separate UI elements, "Yuibkey or phone" doesn't seem like a very coherent category. I guess we can follow the browser UI's lead and call it something like "phone, tablet or security key" but doesn't seem great.

In T399665#11033258, @Mstyles wrote:

After testing on PatchDemo, it doesn't seem that existing browser based passkeys are impacted.

They shouldn't be, we don't call getRegisterInfo() during login.

In T399665#11037015, @Tgr wrote:

Wrt accidentally locking yourself out, this will help in the situation where the user sets up 2FA on a desktop computer and then needs to log in on a different desktop computer. What happens if the user sets things up on a desktop, chooses their phone as a roaming device (as most people probably will), and then needs to log in on the phone? Can the mobile browser use its current platform as a roaming authenticator?
What about the opposite direction (I want to set it up on the phone and will need it elsewhere)?

I tested this a little bit today, and at least on Android, it creates a passkey on my phone that it then stores in the Google Password Manager, which then syncs to my desktop machine (since I'm logged into the same Google account on both, and have sync set up), so both devices can log in fine. I tried storing my passkey in a different Google account without sync set up, and that almost locked me out in that the only way I could get in was by logging in from the phone that had the passkey on it. I think that's weird and dangerous (it means you can no longer log in on the device where you completed the setup flow), but I'm not sure if there's anything we can do to prevent Chrome from presenting this option.

To prevent lockouts, we could ask people to authenticate with the new key once they have set it up (kind of like the confirmation step in the TOTP flow), but that doesn't seem standard for WebAuthn setup flows elsewhere.

For splitting into separate UI elements, "Yuibkey or phone" doesn't seem like a very coherent category. I guess we can follow the browser UI's lead and call it something like "phone, tablet or security key" but doesn't seem great.

Yeah I think that's the biggest issue here. The only control we seem to have is whether we allow roaming authenticators, non-roaming ones, or both. So we'll have to come up with a clear way to describe what a roaming authenticator is, but that might not be easy. One thing we could do is lie: describe it as "hardware security key", don't tell anyone that Chrome will also offer a password manager-based passkey, and hope they don't try.

In T399665#11033258, @Mstyles wrote:

After testing on PatchDemo, it doesn't seem that existing browser based passkeys are impacted.

They shouldn't be, we don't call getRegisterInfo() during login.

@Mstyles and I figured as much, but thought it was worth testing to confirm.

Change #1174048 had a related patch set uploaded (by Mstyles; author: Mstyles):

[operations/mediawiki-config@master] WebAuthn: Add config variable

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

Change #1174101 had a related patch set uploaded (by Mstyles; author: Mstyles):

[mediawiki/extensions/WikimediaMessages@master] Update message for WebAuthn Physical Device Change

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

Change #1172423 merged by jenkins-bot:

[mediawiki/extensions/WebAuthn@master] Restrict passkeys to ROAMING

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

Change #1174048 merged by jenkins-bot:

[operations/mediawiki-config@master] WebAuthn: Limit passkeys to roaming

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

Mentioned in SAL (#wikimedia-operations) [2025-08-14T20:11:09Z] <mstyles@deploy1003> Started scap sync-world: Backport for [[gerrit:1174048|WebAuthn: Limit passkeys to roaming (T399665)]]

Mentioned in SAL (#wikimedia-operations) [2025-08-14T20:13:09Z] <mstyles@deploy1003> mstyles: Backport for [[gerrit:1174048|WebAuthn: Limit passkeys to roaming (T399665)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2025-08-14T20:21:32Z] <mstyles@deploy1003> Finished scap sync-world: Backport for [[gerrit:1174048|WebAuthn: Limit passkeys to roaming (T399665)]] (duration: 10m 23s)

Change #1174101 merged by jenkins-bot:

[mediawiki/extensions/WikimediaMessages@master] Update message for WebAuthn Physical Device Change

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

Change #1190595 had a related patch set uploaded (by Reedy; author: Mstyles):

[mediawiki/extensions/WebAuthn@REL1_44] Restrict passkeys to ROAMING

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

Change #1190608 had a related patch set uploaded (by Reedy; author: Mstyles):

[mediawiki/extensions/WebAuthn@REL1_43] Restrict passkeys to ROAMING

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

Change #1190595 merged by Reedy:

[mediawiki/extensions/WebAuthn@REL1_44] Restrict passkeys to ROAMING

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

Change #1190608 merged by Reedy:

[mediawiki/extensions/WebAuthn@REL1_43] Restrict passkeys to ROAMING

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

Change #1191163 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/WebAuthn@master] Use security-key hint when authenticators are limited to roaming

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

Change #1191163 merged by jenkins-bot:

[mediawiki/extensions/WebAuthn@master] Use security-key hint when authenticators are limited to roaming

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

Change #1191481 had a related patch set uploaded (by Reedy; author: Gergő Tisza):

[mediawiki/extensions/WebAuthn@REL1_44] Use security-key hint when authenticators are limited to roaming

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

Change #1191482 had a related patch set uploaded (by Reedy; author: Gergő Tisza):

[mediawiki/extensions/WebAuthn@REL1_43] Use security-key hint when authenticators are limited to roaming

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

Change #1191481 merged by jenkins-bot:

[mediawiki/extensions/WebAuthn@REL1_44] Use security-key hint when authenticators are limited to roaming

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

Change #1191482 merged by jenkins-bot:

[mediawiki/extensions/WebAuthn@REL1_43] Use security-key hint when authenticators are limited to roaming

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