Is this not possible with current designs?
However the main issue I have is that the user cannot import their own secret into the yubikey, so you cannot choose to use your own secret vs the factory generated one, or choose to have multiple yubikeys using the same secret, which would be useful as you wouldnt need to enrol multiple secrets with each service.
Where would you get this secret from in a secure way? How would you prevent a nefarious actor from exporting it and importing it into their own yubikey or similar?
That's what I meant. How exactly would one safely store this secret? How would you prevent an adversary from extracting the secret from the storage?
I'm not trying to be pedantic here, I'm just failing to see how this can be realistically implemented without significantly lowing the overall security. But this is also not my domain, so I'd like to learn.
If you're asking about the structure of the bits you'd need to move into the device in a verifiable way, there are standard APIs like PKCS #11 for interacting with HSMs.
You would then need a computer and a PKCS #11 client application. If you don't have a computer you can trust to pass keyboard inputs to a USB port without being intercepted, you've got problems that a yubikey will not solve.
Thanks, that was the piece I was missing.