> That said, if I were doing a from-scratch authentication implementation today, I'd probably pick something like biometrics via FIDO2 instead of smart cards...

Traditional smart cards like CAC and PIV can include a user X.509 certificate on the device. FIDO doesn't include this capability. That means FIDO keys have to be registered separately with each and every service[1]. This is deliberate as FIDO tokens can generate a unique key per service--for services authenticated via a web browser this is precisely what happens. But the choice means FIDO doesn't work well for building a generic, federated PKI system.

FIDO has a laser focus on solving user authentication problems for website operators, all managing their user databases independently. The saliency of this approach has at least as much to do with removing degrees of freedom that vendors could abuse to fragment the hardware space than in the technical security of things. Traditional smart cards never lived up to their promise precisely because companies like Saicoo actively sabotaged interoperability and ecosystem simplicity in attempts to leverage vendor lock in.

[1] Or those services must all be able to contact a shared online user database, or a certificate has to be distributed separately (e.g. as with OpenSSH). (But I don't think a FIDO token can even sign something like an X.509 certificate, at least not without defining a new signature algorithm OID.) Both are problematic for use cases like CAC or national identity cards.

It was also deliberate in the sense that they specifically wanted to make it impossible to link different identities on the same key in order to protect privacy. So you can be user1 and user2@ without the site being able to tell from the authentication process alone. (Obviously cookies, IPs and other side-channels exist, but if you protect against that, FIDO won't give you away.)

> at least not without defining a new signature algorithm OID

Yes, that's what you would need to do if you wanted this.

OpenSSH comes with tooling that will sign arbitrary files, and can use either conventional SSH key files (for which it has a safety rationale, explaining why this can't weaken their security for their original authentication purpose if the signature algorithm works as intended) or a FIDO device.

Our chip id cards have been in service since 2002 though, and work fine so I don't think it was a mistake to choose this technology.

I'm not sure how FIDO2 would work for most uses which are not web based, and identification via biometrics is certainly not something I'm looking forward to.