[tialaramex]

For FIDO (and thus WebAuthn, and thus to make this actually practical beyond a toy that only works for some particular Yubico product) the keys are random per enrollment. This is intentional because it means that you can't be tracked, since "your" key on Facebook and "your" key on GitHub are no more related to each other than "my" key on Facebook is to "your" key on GitHub.

Google have apparently some plans to address this problem in the medium term. Adam Langley has written vaguely on this subject before. In the short term, their priority is the trick he wrote about most recently - if your Android phone is enrolled as a Security Key with Google, and it's signed in to Google because it's an Android phone, and you use Chrome on a desktop, which is also signed into Google, the Chrome can use Bluetooth to determine if the phone is physically nearby and if so propose to authenticate your desktop Chrome to a remote web site using the Android phone. Elegant, albeit not suitable for those who fear lock-in.

[gruez]

>This is intentional because it means that you can't be tracked, since "your" key on Facebook and "your" key on GitHub are no more related to each other than "my" key on Facebook is to "your" key on GitHub.

I get the motivation behind it, but the mechanism I proposed in the last comment still preserves those properties? Each site would still get its own derived ECDSA public key. The master ECDSA public key would only be shown to the user and is to be kept within the browser. If a user wants to enroll a not-present security token, the browser will take the ECDSA public key and derive a public key to present to the site, so the site still can't track users using security tokens.

[tialaramex]

To complete enrollment you need to know the corresponding private key, live.

The relying party says "I am some.example and I want to enroll a Security Key, but, not ones which recognise these huge random-looking IDs that are already enrolled: 12345678, 34561234. I also picked this random nonsense XYZXYZXYZ. Go for it" and your browser talks to your Security Keys until it finds one that isn't already enrolled, gets that one to sign the appropriate message and sends back, "I am a web browser, I checked that you are some.example. I picked my own random nonsense XXXZZZ, and a Security Key picked public key ABCDEF, then to prove it knows the private key it signed this message for some.example mentioning XYZXYZXYZ and XXXZZZ and with bitflags it understands enough to know what it's signing. It says the resulting credentials have random-looking ID 98765431. Thanks". /s/Security Key

If the Security Key cost less than a low-end Yubikey, it has no storage. That random-looking ID is in some sense your private key for the site, but suitably encrypted, e.g. with AES in Galois/Counter Mode, so that the device needn't remember it, when a site asks keys to authenticate, it must provide the ID they're authenticating against, and so they can do AES GCM, figure out if they minted this ID, and if so recover the private key and authenticate. This is fiendishly clever, but so far as I can see renders your idea impossible.

[gruez]

>you need to know the corresponding private key, live.

This seems like the main blocker. Why is that required? In theory all the site needs is a public key to verify against.

[tialaramex]

If you have questions about why the WebAuthn protocol works the way it does, it seems like you'd want to first read the protocol in detail and then if you still have questions ask its maintainers.