Let me give you a little more of a fleshed-out use-case, then, as well as some alternative designs that come to mind. Let's imagine I'm a consumer bank. I want

Let me give you a little more of a fleshed-out use-case, then, as well as some alternative designs that come to mind. Let's imagine I'm a consumer bank. I want the following features: * I ship users a FIDO key when they sign up for an account. * Users can register additional keys they bought or already have, and can use my key elsewhere. * I consider malware on the user's computer to be in the scope of my threat model, and so I want all risky transactions (like transferring money) to come with a secure test of user presence. I believe that the above three constraints are sufficient to motivate the current design. Why? Well, let's say we do the obvious and just eliminate attestation. If the design otherwise remains unchanged, there's nothing to prevent clever malware from piggybacking a legitimate user presence tap to add a malicious, software-only authenticator to the user's account, which can then approve future transactions.[1] Currently, however, I can simply require that authenticators all be non-self-signed, restricting to those that come with real hardware-backed security. So now I have a few options. I can: a) Disallow enrolling new authenticators. I think this is the worst option, because it means that the FIDO ecosystem would basically revert to (at worst) "an authenticator per relying party", which is expressly something it aims to avoid. (Think, keyrings full of USB fobs!) b) Declare malware out of scope. I find this unsatisfying, since it suggests we might as well just replace FIDO with USB keys with X509 client certs, but see my footnote [1]--maybe at the limit these are equivalent? c) Do what the FIDO Alliance seem to have done: create batch attestation, but discourage RPs from using it spuriously. I think (c) is fairly reasonable, but as I said, I do find the entire malware argument sort of unsatisfying in a way, so, shrug. [1] Arguably, if this is an attack you are concerned about, malware can also just piggyback presence to directly trigger transfers and other abuse, of course, so maybe this argument is a weak one? But I think an RP might reasonably want to say that "malware can do anything malicious within 10 seconds of a tap on your key, but if you think someone might have hacked your account, just remove your key and call customer support." If malware can add new software-only authenticators, it violates this functionality.