The credential is not only the user's data. The credential is an agreement for access between the user and the service provider.
The service provider has every right in the world to demand the user prove that they are securely storing the credential in a way that can't be extracted.
> The service provider has every right in the world to demand the user prove that they are securely storing the credential in a way that can't be extracted.
Wait, really? Does this work both ways? Do I get to demand that the service provider store the data it collects about me in a way that can't be extracted? Oh, apparently not[1]...
> The service provider has every right in the world to demand the user prove that they are securely storing the credential in a way that can't be extracted.
I'm so glad people never crammed that into the TOTP protocol. You have recovery codes you can save (which are arguably just as sensitive as the TOTP secret) and a lot of apps let you export the secret entirely.
I used an app on iOS that doesn't let you export them, and it took hours to migrate each entry one-by-one to my new Android device. Even with recovery codes, it was a pain to log in to each site and drill through their menus to disable and set up 2FA again. I should have been wary of that.
> The credential is not only the user's data. The credential is an agreement for access between the user and the service provider.
The credential is, in fact, only the user's data. How does it even make sense that a credential could be an agreement?
> The service provider has every right in the world to demand the user prove that they are securely storing the credential in a way that can't be extracted.
No, nobody has any right to dictate, or even know, how my device stores my data.
You're dictating to your bank they shall not let you money be stolen, right? Perhaps not dictating, but if you thought that was a possibility you would go to anther bank. So they can honour that agreement they are dictating to you how you store your passkeys so they can be reasonably sure people can't use them to steal you deposits. And again not dictating in an absolute sense - you are free to find another way to safeguard your money.
They might demand whatever they want, but it translates into "I want to control what you can do on your system". Which is basically another DRM-like idea. This should not be viewed as an acceptable approach. Because there is no end to it once they get to tell you what you can or can't do with your own system.
Seems like this hot take is coming with a very specific use case in mind. I could see a company wanting fine grained control over how its employees access their privileged employee accounts. I'm not sure attestation needs to be in the spec for that, but I can see why some companies might want it in the spec for that. Ideally they would just have the right mix of policies, incentives, and culture to make sure none of the employees are grossly negligent about security.
Their customers' accounts, on the other hand, are a different story. They should have freedom to choose. Companies that try to restrict that freedom should be punished in the market, or, in cases of monopoly, by the FTC. I suppose that doesn't mean it definitely shouldn't be an option in the spec, though..
Even for companies, attestation isn't necessary. If your employer wants to make sure that your VPN passkey is really on a YubiKey, then they should generate it on it for you before they give it to you.
The credential is not only the user's data. The credential is an agreement for access between the user and the service provider.
The service provider has every right in the world to demand the user prove that they are securely storing the credential in a way that can't be extracted.