The problem with this approach is that the same identity is used by every destination, so sites can swap notes to see where you've been and draw correlations that you may not want to expose.
There are several ways to solve this issue, such as the one used in the FIDO U2F security key. In this case, the device contains a symmetric key (not an asymmetric key pair) and the necessary crypto hardware such that the secret key never needs to leave the device.
On site enrollment, the device creates a new public/private key pair and sends the public key to the server along with a "key ID" for that key. On authentication, the site sends to the browser the "key ID" for that user and expects the response to be signed with the corresponding public key.
But instead of storing the private key corresponding to each key ID, the ID is itself the private key encrypted with the device's secret symmetric key.
There are additional features to the protocol to make phishing impossible, but those are beyond the scope of this answer.
Note that this is only safe because the secret never leaves the hardware. The same principle is true for any hardware security token; it's the fundamental difference between a true security key and something like a thumb drive; a storage device can be copied. This is at odds with human-implanted keys because the hardware necessary to do actual crypto calculations while being powered by NFC requires too much area to comfortably fit under the skin.
Using a protocol like this one gives you the added advantage that it's already supported by other peoples' sites, so all you have to worry about is your local implementation. But it's not so good for SSH keys and such. If you're going to use it as an SSH key, you've got to get it to somehow communicate with your key agent (which probably means writing a new key agent).