this is probably a dumb question, but why not just store a secret seed that is used with an on device prng to generate as many secrets as you need where a sequence id gets shared with the counterparty?
I'm pretty sure that is how non-resident keys work on some platforms (like the first gen yubico U2F tokens).
The main feature of resident (aka discoverable) keys is that the RP doesn't need to know anything about which key is about to be used, so it can just say "send me an auth for example.com", and the browser and key handle the rest.
However, with non-discoverable keys, the RP has to provide a reference to the key, which could actually have encrypted private key matter in it.
It's a challenge-response with nonces. There is also the browser's role to ensure that a given RP's requests are marked with the origin (domain) they came from, so auth.example.com and auth.example.evil don't overlap. (U2F is mostly concerned about malicious sites, and less about malicious browsers and other nastyware)
