I guess the approaches taken with U2F tokens here (and FIDO2) makes sense - have more than one token enrolled, and allow either to be used.
It's not perfect and there are usability issues around this, but they're mostly solvable. Needing both keys around to enrol into each service can be an issue, but this could be addressed by letting a user enrol other public keys as a delegate, and present a signed delegation token allowing that token to enrol a public key on behalf of an off-site token.
Revocation is the next issue - how do you revoke either of your tokens if stolen or compromised? PKI had this issue and ended up down the CRL Vs OCSP approaches. Clearly you need to be able to revoke without the token being present (maybe storing a signed revocation for A on your B token), and some kind of gossip-based network to spread the signed revocation around. That might avoid centralising it.
As long as your "chip" is designed as an ISO smartcard, you can also rely on pin protection (I'll ignore the implanted under skin aspect, other than to observe that does adjust the threat model as deniability around knowing the PIN is lost at that point. A duress PIN that validly unlocks but generates different keys would be a potential solution here for where mistaken identity can be used as an escape from an adversary).
Agreed, although most of this will end up wrapped up into the token and system itself, I suspect.
U2F is pretty much a "key" (some even visually looking like keys) that are used pretty much like a physical key - put the key into the keyhole (USB port), and press the flashing light. Done.
That level of UX is what we all need to build towards!
It's not perfect and there are usability issues around this, but they're mostly solvable. Needing both keys around to enrol into each service can be an issue, but this could be addressed by letting a user enrol other public keys as a delegate, and present a signed delegation token allowing that token to enrol a public key on behalf of an off-site token.
Revocation is the next issue - how do you revoke either of your tokens if stolen or compromised? PKI had this issue and ended up down the CRL Vs OCSP approaches. Clearly you need to be able to revoke without the token being present (maybe storing a signed revocation for A on your B token), and some kind of gossip-based network to spread the signed revocation around. That might avoid centralising it.
As long as your "chip" is designed as an ISO smartcard, you can also rely on pin protection (I'll ignore the implanted under skin aspect, other than to observe that does adjust the threat model as deniability around knowing the PIN is lost at that point. A duress PIN that validly unlocks but generates different keys would be a potential solution here for where mistaken identity can be used as an escape from an adversary).