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).
To protect against damage—which is a very real possibility, of course—I'd put identical chips in each hand, and if one fails or gets damaged, then you'd have to rotate keys by replacing both chips.
And you could have a third identical chip/key (or a different private key on another device in a safe somewhere) as a further backup, as my sibling comment recommends.
Clearly the verified URL origin of something in the real world is complex, but there are ways to potentially make this work. Devices might have certificates for a URI, and this URI could be verifiable and convey attributes like the GPS coordinates to within 25m, that you can verify before authenticating. Users could presumably also whitelist certain origins (garagedoor.home.mydomain.net)
All of this apart from the subdermal part actually could work out well - a small number of people already do this via U2F, or even traditional smartcards.
My current solution is that the device has three functions: encrypt/sign with private key, decrypt with private key, and send public key. They would be protected by a PIN—probably a six-digit alphanumeric pin. You might want to rate limit PIN attempts to one per second, as well.
With this scheme, I can't see how it would compromise privacy or security. No one can just scan your hand and know your identity, since you need the PIN to get your public key. And since all encryption/decryption happens on the chip, the chance that your private key gets stolen is pretty much as low as possible.
If you see any flaws with this scheme—I certainly wouldn't be surprised if there are, I just can't see any right now—please critique away!
