webappsec-dbsc

It is not based on TB but it is heavily informed by those efforts. See here: https://github.com/w3c/webappsec-dbsc#what-makes-device-boun... However, DBSC as an API and protocol is similarly agnostic about key storage. There is no attestation and the User Agent is fully responsible for selecting key storage that provides the best protection.

> 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...

Glad to hear it. I feel the library could be improved, and if your server runs on something other than Node.js, you'll have to put together some straightforward crypto code, so feel free to file an issue on the repo[1] if you have any questions or requests. The point of it is not at all to compete with Google, but it could serve as a reasonable stopgap that's easy to implement (no new endpoints, no roundtrips) and should protect against all of today's cookie stealers, which would have to become a lot more sophisticated to beat it. I created a discussion on DBSC's spec repo yesterday that has a more direct comparison vs. Google's proposal[2] that you can check out. [1]https://github.com/zainazeem/session-lock [2]https://github.com/WICG/dbsc/discussions