[Vecr]

You can run a software TPM if you browse within a VM.

[kbaker]

~~~~But your VM TPM won't be signed during manufacturing by a trusted root. No attestation.~~~~

OK I take it back, privacy is one of their specified goals:

> Note that the certificate chain for the TPM is never sent to the server. This would allow very precise device fingerprinting, contrary to our privacy goals. Servers will only be able to confirm that the browser still has access to the corresponding private key.

However I still wonder why they don't have TLS try and always create a client certificate per endpoint to proactively register on the server side? Seems like this would accomplish a similar goal?

[arnarbi]

> why they don't have TLS try and always create a client certificate per endpoint to proactively register on the server side

That is effectively what Token Binding does. That was unfortunately difficult to deploy because the auth stack can be far removed from TLS termination, providing consistency on the client side to avoid frequent sign outs was very difficult, and (benign) client side TLS proxies are a fairly common thing.

Some more on this in the explainer: https://github.com/w3c/webappsec-dbsc#what-makes-device-boun...

[IlikeKitties]

And that Software TPM has whos vendor endorsement keys exactly? Ah yes, ones that google won't consider valid.

[gjsman-1000]

Well, it's a good thing Device Bound Session Credentials (DBSC) as proposed here has no way to actually send said endorsement key anywhere; rending the objection irrelevant. The TPM is only for secure storage as verified by the browser itself, not the website being visited.