A new site, dbsc.dev, lets developers test whether their browser supports Device Bound Session Credentials (DBSC), a protocol with no JavaScript feature-detection hook since it's driven entirely by HTTP headers and server behavior. The tool sends a real registration header, watches for the browser's signed response, and shows the full exchange (decoded JWTs, device public key, refresh cycle) for debugging. It also exposes dbsc-php, an open source PHP library extracted from Report URI's production DBSC integration. Chrome is currently the only browser implementing DBSC, now on both Windows and macOS, while Firefox and Safari have no support.
Table of contents
A Feature You Cannot Feature-DetectWatching For The AnswerThe Bit I Actually Wanted To BuildWatching A Refresh Happen LiveWhy You Might Actually Use ItOn PrivacyUnder The HoodClient SupportSourcesQuestions this post answers
Which browsers currently support Device Bound Session Credentials (DBSC)?
Chrome is the only browser that implements DBSC, with general availability on Windows and support that has since landed on macOS as well. Firefox and Safari have no implementation at all. Because DBSC has no JavaScript feature-detection API, verifying support in any browser requires actually triggering a real registration exchange and observing whether the browser responds. Track cross-browser support shifts for security features like DBSC by following updates on daily.dev.
Why can't I use JavaScript to detect if a browser supports DBSC?
DBSC provides no client-side API such as a navigator property, constructor, or promise to check against, because the entire protocol is driven by HTTP headers exchanged between server and browser rather than by page-level JavaScript. A server sends a Secure-Session-Registration header, and a supporting browser silently generates a key pair and posts a signed response without any page involvement; unsupporting browsers simply ignore the header and continue with normal cookie auth. Developers debugging device-bound session flows can follow protocol-level explainers like this via daily.dev.
Where does the device public key appear in a DBSC registration JWT?
The device public key appears in the JWT header as a jwk field alongside "typ": "dbsc+jwt", not in the payload. The payload itself is nearly empty, typically containing only a signed challenge under a jti claim. This detail matters for anyone implementing the server side of DBSC, since it's easy to assume the key travels in the payload. Implementers wiring up DBSC on their own servers can compare notes on wire-protocol quirks via daily.dev.