There's nothing in this spec that says there needs to be a restriction of one session per TPM. There isn't even anything that forces the client to use a TPM. It just requires the client to generate a key pair, and then use that to sign challenge responses. There's no way for the server to know which TPM was used to store that private key, nor whether one was even used.
> There's no way for the server to know which TPM was used to store that private key, nor whether one was even used.
I was all ready to disagree with you but apparently you're correct. Color me surprised.
> DBSC will also not prevent an attack if the attacker is replacing or injecting into the user agent at the time of session registration as the attacker can bind the session either to keys that are not TPM bound, or to a TPM that the attacker controls permanently.
This is a very pleasant surprise. I've grown accustomed to modern auth protocols (and other tech stacks as well) having DRM functionality baked into them where they can attest the vendor of the device or the software stack being used to perform the auth. It's become bad enough that at this point I just reflexively assume that any new web technology is hostile to user autonomy.
