Anyway, unclear to me how this is better than x509 client certs, except that the author probably doesn't know about them.
FIDO is the banking world's version of the Intel Management Engine and HDCP.
https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-RD-v1...
In my experience, the vast majority of (consumer) RPs do not require specific batch attestation, which is why you can make your own FIDO key: https://github.com/google/OpenSK.
I am under the impression support for attestation was controversial in FIDO--it's clearly useful for enterprise scenarios (e.g. where an enterprise requires some silly certification like FIPS: https://support.yubico.com/hc/en-us/articles/360016614760-Ac...), but there's always the risk that consumer-facing RPs require it for no good reason.
My employer requires FIPS certification due to FedRAMP; I'd be interested in how you would propose to change FIDO such that--as now--I can use a single key for work and for all my consumer needs while eliminating attestation. (One obvious option is for my employer to issue already-enrolled keys and disallow self-enrollment, but that has other headaches...)
The point is that it takes that choice out of the users' hands.
Choosing which manufacturer's hardware to use, or even to make their own, is the user's choice to make.
> use a single key for work and for all my consumer needs
You shouldn't. That's like expecting to be able to use your work laptop for personal stuff.
Unclear to me why you think the user--and not the IdP--should have the final say here.
> You shouldn't. That's like expecting to be able to use your work laptop for personal stuff.
Except FIDO identities are unlinkable even if using the same hardware.
I understand for a corporate setup employees are threat vectors. But that depressing outlook isn't how most people view the consumer space. We want: consumer x signed this auth challenge. We do not want: authority Y said consumer X signed this auth challenge. That’s just CA SSO style oligarchy repeated.
Why wouldn't you trust the consumer and their preferred authentication agent to participate in an authentication challenge? Consumer apps don’t need to ensure that consumers are using a hardware token device they just need to arrange an authentication dance that doesn't involve a shared secret.
But like I said, most consumer IdPs aren’t doing attestation checks, and it’s discouraged, so I think you’re making a big deal of it. :)
If a bank feels the need to control the hardware I use, they must provide that hardware. Their needs absolutely do not entitle them to impose codesigning/bootloader-locking requirements on my other devices, such as my phone or my laptop.
> aren’t doing attestation checks, and it’s discouraged
That will change. If it weren't, they wouldn't have bothered putting it into the spec. Or they could have used symmetric cryptography for attestation, like the bank-issued token cards and the chip in your chip-and-PIN card do.
And the reason I can do that is because my work cares that I use a FIPS compliant key, but nobody else does—because consumer RPs don’t do this.
Have you encountered any consumer RP enforcing attestation? Or is this concern of yours totally speculative?
I don’t know what this Bank of America card you refer to is, but presumably it was phishable auth, since it had an LCD key? Without a standard supported by user-agents, I don’t know how someone would enforce an out-of-band/unphishable auth mechanism like FIDO+Webauthn on their own, but I’m curious to hear you explain it!
Even Microsoft's half-arsed explanation of how this works inside Azure AD says you should probably not use it.
And I tell Firefox "No" when it asks me during enrollment if the site is allowed attestation from my devices, there are no public sites I've used where this was rejected as unacceptable, that includes GitHub, Google's sites, Facebook, and Login.gov.