> 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...

> 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.