> … so the only thing that an authenticator could display on your screen is "do you want to authenticate as user x to website y" …
That is exactly why you want it.
Consider, for a moment, that you have a key which is used to log in to your bank account and some other, much less critical site. Perhaps a GitHub account where you store some hobby projects.
Without an unforgeable indication on the authenticator to show what you're logging in to, malware can wait until you're logging in to the second site, and thus expecting a prompt to use the authenticator, but actually trigger the authentication process for your bank off-screen. You tap the button or whatever on the authenticator thinking that you're logging in to your GitHub account but actually all your money is being siphoned off to who-knows-where.
A key that signs whatever request is presented to it without any indication to the user of what the request actually was is dangerous.
If you have malware on your computer (that can compromise the browser), it can just wait until you actually log in to your bank and then grab the session cookie/proxy away your authentication.
It's a different story if the operation you are confirming with a security key actually can be rendered on the display, e.g. "pay $100 to someshop.com" (as in SPC [1]). In that scenario, there is actually nothing to steal except for the signed message itself, which would be useless to anybody that's not someshop.com, but given that WebAuthN almost always just yields a session cookie, I don't really see the benefit.
> If you have malware on your computer (that can compromise the browser), it can just wait until you actually log in to your bank and then grab the session cookie/proxy away your authentication.
Sure, but you might never log in to your bank from this particular computer precisely because you don't trust it. But you think it's fine to log in to your hobby account since that doesn't store anything you really consider important.
If you assume there is never any malware on the host then you don't need the key at all—the host can store the secrets and handle the authentication on its own.
Oh, that's a good point – I personally never use my security key at untrusted computers, but I guess this could be a somewhat common use case.
> If you assume there is never any malware on the host then you don't need the key at all—the host can store the secrets and handle the authentication on its own.
True, a permanently plugged in authenticator is largely equivalent to just using a password manager (which also prevents against skimming, if used exclusively via autofill, never via copy/paste), but unlike a password mananger, it makes unsafe actions explicitly impossible for non-sophisticated users. I'd consider this a strong advantage.
That is exactly why you want it.
Consider, for a moment, that you have a key which is used to log in to your bank account and some other, much less critical site. Perhaps a GitHub account where you store some hobby projects.
Without an unforgeable indication on the authenticator to show what you're logging in to, malware can wait until you're logging in to the second site, and thus expecting a prompt to use the authenticator, but actually trigger the authentication process for your bank off-screen. You tap the button or whatever on the authenticator thinking that you're logging in to your GitHub account but actually all your money is being siphoned off to who-knows-where.
A key that signs whatever request is presented to it without any indication to the user of what the request actually was is dangerous.