>higher security around sensitive things like banking and email
There are no guard rails built in to make sure this isn't used by everyone and their dog as long as it makes site automation just a bit more difficult. Also kiss goodbye to browsing the internet without a governement/bigcorp™ approved TPM.
If you check the spec [0] you will see that unlike most new web tech this one doesn't provide any DRM-adjacent functionality. There's absolutely no technical measure in the spec that could be leveraged to force an implementation to use a TPM. If user choice is disrespected that is squarely on the implementation (ie the browser) and has nothing to do with either the protocol or the server.
Honestly this fairly simple scheme looks a lot like what I wish webauthn could have been.
> makes it more or less useless as a security measure
Define "security". This is incredibly useful for mitigating bearer token exfiltration which is the stated purpose. It's also the same way ssh keypairs work and those are clearly much more secure than passwords.
It's only "insecure" from the perspective of a service host who wants to exert control over end users.
Even webauthn leaves attestation as an optional thing. Even in the case that the service operator requires it, so long as they don't engage in vendor whitelisting you can create a snakeoil authority on the fly.
The main advantage this has over webauthn is that it is so much simpler.
There are no guard rails built in to make sure this isn't used by everyone and their dog as long as it makes site automation just a bit more difficult. Also kiss goodbye to browsing the internet without a governement/bigcorp™ approved TPM.