[md_]

FIDO keys are also unlinkable across origins (or identities!), but unlike in this scheme, that property doesn't rely on the user knowing to not reuse keys.

Anyway, unclear to me how this is better than x509 client certs, except that the author probably doesn't know about them.

[octoberfranklin]

Device attestation certificates, for starters. FIDO prevents user-controlled hardware. That's the whole point of FIDO, and why it's awful.

FIDO is the banking world's version of the Intel Management Engine and HDCP.

https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-RD-v1...

[md_]

I'm not sure what you're replying to--this scheme is much closer to self-signed X509 client certs, not FIDO. But regarding FIDO, it does not prevent user-controlled hardware; it's up to RPs to choose if they require specific device manufacturers or not.

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

[tialaramex]

The WebAuthn spec. explicitly tells RPs not to do this (attestation) unless they're sure they really need 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.

[octoberfranklin]

> it's up to RPs to choose if they require specific device manufacturers or not.

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.

[md_]

> The point is that it takes that choice out of the users' hands.

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.

[dcow]

Because for consumer auth we just go back to the CA oligarchy and client certs nobody uses if we rely on trusting vendor attestation.

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.

[md_]

It depends a lot on the situation. I think it’s reasonable, for example, for banks who have different liability standards depending on how transactions are authenticated to require batch attestation.

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