Creating this as a parent task of {T244088}
Basically, as is, if you enable WebAuthn on enwiki, you can't login to dewiki using the same WebAuthn credentials...
>>! In T244088#5875266, @ItSpiderman wrote:
> The patch above will let you manually configure the relying party name and id (domain). It can be set to the root part of the domain, to make WebAuthn work for multiple sub-domains, while without it, it can be used on one specific subdomain only. So, it does add some functionality, but still not as much as you would need.
>
> Also, beware, that all single-domain-specific keys (all keys that are registered so far), cannot be used anymore if configuration related to the RP is changed. This would require all users to re-register their keys.
This may help with *.wikipedia.org, but it doesn't help with *.wikimedia.org etc.
We need to come up with a long term plan on how to deal with this (which is probably like doing a redirect/similar to loginwiki (or meta? or ??); or some other sort of login portal (ala how google do it)) for WebAuthn.
The likes of fishbowl and private wikis are fine, wikitech will become a problem when we make it a CA wiki later, but we can cross that bridge later.
In the meantime, we should probably look at adding to the WebAuthn messages to notify people of this, and that they need to login where they enabled it to take advantage of this, pending a longer term solution
This is a UX problem, and as such, is yet another blocker to wider rollout of 2FA for the general population