The issue of PCs being seen as less secure cannot be fixed with a fido card.
I don't think so. There are ways of tightening the security model so that even attacks on a compromised system are highly impractical.
Neither is there a need to poorly reinvent the wheel by using a fido card.
This isn't reinventing the wheel. The technology already exists, and it's already in widespread use.
Bank cards already have embedded security chips. If the real issue was authentication (It most certainly is not) at worst all you would need is a cheap card reader that costs $15.
No, no, and...good lord...no. Honestly I'm not quite sure where to start telling you what's wrong with this idea, but in fact, THIS is reinventing the wheel, not to mention sticking a square peg into a round hole. Why do I say that? A lot of reasons...Payment cards don't have a standard protocol usable to sign arbitrary messages. Technically there's kind of one usable by the terminal, but you're talking 32 bits of entropy, and even then, that's a ... maybe but don't count on it? Because it depends on the card. Some cards may have additional applications you can select and...ahh...don't bother. Those are a fucking mess of proprietary shit, and that's before you even get to the bureaucratic red tape. I've written software that does the authentication bits using FIDO2 over NFC, and thousands currently use it in a production environment. And you know what? It's really easy, and really well documented. You don't need to pay anybody for the documentation, or for permission just to implement. There are paid certification programs, but they're only necessary in some very limited circumstances that most people, even most developers, don't need to worry about.
But...well...Let me give you a little preview of what you're asking for with payment cards:
https://www.eftlab.com/knowled...
Now...of those application identifiers, how many of them, to your count, are for these payment cards that you're telling me you want to use? After you do that, go dig up the documentation for each of them, if it is even public at all or you're lucky enough that somebody reverse engineered it. Namely, the PDUs, their inputs, their outputs, including all TLVs or other command payload length specifiers that each may or may not deal with. Each of them are different, some are way, way different.
Oh, and we haven't gotten to implementation yet. And how many of these have attestation keys separate from the ephemeral signing keys? Make sure you get the PDUs from all of those as well, plus any relevant gotchas and quirks.
Oh oh oh and...we haven't even gotten to user privacy yet! What do you plan to do to ensure that, say, your payment card that you used to authenticate to say, protonmail, can't be used for say ad companies, governments, etc, to know that this same card wasn't also used to authenticate to ilikeboobies.com? (oh wait nvm, that's a real website, but you get the idea...) Did I mention that FIDO2 already has very strong protections against exactly this kind of thing?
And this barely scratches the surface. Nor is that AID list anywhere near complete. There probably aren't even any that are complete that you'll find anywhere. Even if you throw up your hands and say "ok so the card can only be used by the issuer's website! It'll be like payment terminals!" except for the fact that you'd need to permit the web browser to have direct access to the transport (i.e. PCSC) so that raw APDUs can be exchanged...umm....yeah, that sounds reeeaaaallly secure...
So tell me again how FIDO2, a technology that has already been in use for over a decade, doesn't rely on obscurity, and can be used to authenticate with literally anything, including things that aren't even connected to the internet at all, reinvents the wheel, but your payment card based authentication somehow does not? In fact, I'd even argue that the key card tesla made is, in many respects, an even more ideal choice for this than a payment card, because at least it can do message signing.