The explainer does have some alternatives listed here <https://github.com/w3c/webappsec-dbsc/blob/main/README.md#alternatives-considered>. The advantage over token binding is that this happens at the application layer, instead of within TLS. The advantage over WebCrypto is that it's better integrated into existing auth flows. A sufficiently powerful framework that could defer and retry all network requests could rely on an extension to WebCrypto to provide TPM-backed keys. But such a framework needs very deep hooks to cover all network requests. That makes it prohibitively expensive for a site to adopt. DBSC makes that much easier for web developers by trying to fit into their existing authentication frameworks. I can also add the proposal from the TAG to that list of alternatives, with the tradeoffs discussed previously in this thread.
We haven't published a formal writeup of OT feedback anywhere, but we did solicit statements from both Okta and Snap here <https://github.com/w3ctag/design-reviews/issues/1052#issuecomment-3208321722> . Thanks, Dan Rubery On Mon, Feb 9, 2026 at 11:22 AM Alex Russell <[email protected]> wrote: > Thanks for the context, Sam. I'm concerned that the Explainer doesn't > outline any considered alternatives. Where can I read up on why this is the > best possible design in this space? Has a summary of OT feedback been > published anywhere? > > Best, > > Alex > > On Monday, February 9, 2026 at 10:47:48 AM UTC-8 Rick Byers wrote: > >> Thanks Arnar and Sam for the additional detail and supportive color. It >> makes sense to me. >> >> IMHO we are way past due for making auth more secure on the web. I've >> found this W3C preso from Entersekt >> <https://drive.google.com/file/d/1qxiGuKfwl8URcxAcG4ajm_3zH5xm9PBv/view> to >> be compelling, they say (slide 6) that banking is actively moving away from >> the web due to the lack of security relative to native platforms (which is >> obviously about more than just cookie theft, but it's a start). Yesterday >> my brokerage, qtrade.ca, sent me a security warning about the hostility >> of the web including the guidance "Whenever possible, sign in using our >> mobile app". Anything we have reason to believe can help with sites >> adopting more secure authentication is urgent in my view. Perhaps the best >> thing we can do to help is try to build partnerships with some of these >> more "regular" web apps and understand what we can do to help them gain the >> security benefits of DBSC? I hope we will be able to publish some case >> studies about what we learn in the Google context. >> >> Rick >> >> On Mon, Feb 9, 2026 at 1:26 PM Arnar Birgisson <[email protected]> wrote: >> >>> I think it's worth noting that the design choice for browser-initiated >>> refreshes, which was TAG's biggest gripe, is not there only because of >>> partner feedback. >>> >>> The two reasons were: >>> a) At scale, where one auth system serves a large set of apps with >>> different ownership, it's not feasible to do the kind of migration that >>> switching to server-initiated refreshes would require. >>> >>> b) For smaller and "regular" webapps that build on 3rd party frameworks, >>> there isn't a way for frameworks to ship and migrate from cookie-based auth >>> to server-initiated refreshes without a lot of work from the app developer. >>> That problem is compounded when apps are built on a stack of frameworks. >>> >>> Reason a) is obviously motivated by Google, but it is well supported by >>> partner feedback. But by its nature, we have no partners looking at DBSC >>> from the PoV of b). Besides TAG, very few people outside Google have >>> thought enough about DBSC to understand the challenges of b), and that's >>> the discussion that was most challenging with TAG. It's at least my opinion >>> that client-initiated refreshes are the *less* risky option for future >>> adaptability. >>> >>> cheers, >>> Arnar >>> >> >>> On Mon, Feb 9, 2026 at 10:08 AM Sam Goto <[email protected]> wrote: >>> >>>> I haven't been directly involved with DBSC personally, asides from >>>> rooting from the side lines, so I just wanted to stop by to show some >>>> neutral support for DBSC on this thread and to try to add some comfort to >>>> the architectural design risks that are being taken. >>>> >>>> DBSC has a concrete chance of helping with one of the biggest problems >>>> in authentication on the Web, cookie theft. The fact that the team involved >>>> has found a mechanism that can concretely help users at scale by satisfying >>>> hard requirements from real-world developers seems to me like a checkpoint >>>> worth capturing. >>>> >>>> I empathize with the tension described in the TAG review, but that >>>> didn't seem to me like an irreversible technical choice, whereas closing >>>> the window of opportunity to capture developer appetite and build a >>>> community around it does. I'm pretty confident that DBSC, if it succeeds, >>>> will go over a massive amount of API iterations and might look very >>>> different from what's being proposed here, and that's OK. What I think is >>>> most important is that with this baseline, the team can create a baseline >>>> and gather real-world deployment and implementation experience to shape how >>>> things plays along. >>>> >>>> I hope this helps, >>>> >>>> Sam >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Monday, February 9, 2026 at 9:41:50 AM UTC-8 Mike Taylor wrote: >>>> >>>>> >>>>> On 2/9/26 11:29 a.m., Rick Byers wrote: >>>>> >>>>> Ok LGTM1 to ship subject to working to get the WPTs passing on wpt.fyi >>>>> one way or another. >>>>> >>>>> On Fri, Feb 6, 2026 at 5:16 PM Daniel Rubery <[email protected]> >>>>> wrote: >>>>> >>>>>> > Thanks! Have a wpt.fyi URL? >>>>>> >>>>>> Here's our tests: >>>>>> https://wpt.fyi/results/device-bound-session-credentials?label=experimental&label=master&aligned. >>>>>> It seems there's something wrong with the harness there, so we'll look >>>>>> into >>>>>> that. (My guess is that it's a result of DBSC being Finch-controlled and >>>>>> using a VirtualTestSuite, which would improve the moment we ship) >>>>>> >>>>> >>>>> Ah yes, generally we expect new web platform features to be >>>>> status=experimental RuntimeEnabledFeatures >>>>> <https://chromium.googlesource.com/chromium/src/+/main/third_party/blink/renderer/platform/RuntimeEnabledFeatures.md>, >>>>> and that ensures they're enabled by default in most of our web platform >>>>> tests (virtual/stable turns them off), and also enabled for web developers >>>>> who are testing with --enable-experimental-web-platform-features. It's not >>>>> a strict requirement but you might see if you can easily wire it up to >>>>> enable in that case in addition to the finch knob. But as long as you are >>>>> following finch best practices of enabling by default in code before >>>>> pushing finch to 100% then IMHO it's not a big deal. >>>>> >>>>> I see >>>>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/runtime_enabled_features.json5;l=1908-1914?q=runtime_enabled_features.json >>>>> is already set to "experimental" - but I'm not sure if the "origin_trial" >>>>> keys prevent this from running on wpt.fyi w/o an OT token... >>>>> >>>>> >>>>> > Please correct this to unsatisfied. >>>>>> >>>>>> > I read the TAG feedback and interpret it as preferring a different >>>>>> architecture than what our customers have told us they prefer. Does that >>>>>> seem right? Or is there another reason why we disagree on the suggestion >>>>>> to >>>>>> prefer a lower-level design? >>>>>> >>>>> >>>>> Jeffrey: >>>>> >>>>>> Yep. The TAG's review is effectively a prediction that the way the >>>>>> architecture is tailored to our current partners makes it easier for them >>>>>> to adopt, at the cost of making the system harder to adapt to future >>>>>> needs. >>>>> >>>>> >>>>> Daniel: >>>>> >>>>>> Corrected to "Issues open" (I don't see an Unsatisfied option). Your >>>>>> understanding is correct. We believe that the higher-level design makes >>>>>> it >>>>>> easier to deploy and more extensible for the future. Feedback from our >>>>>> Origin Trials certainly supports the ease of deployment. >>>>>> >>>>> >>>>> Thanks, makes sense to me. This is such a common tension in web >>>>> platform design. FWIW I personally consider being too primitive-focused in >>>>> the past to be my biggest technical career mistake >>>>> <https://docs.google.com/presentation/d/19bz4CDrpOtxaqFe1tcrX1O3aBH40LU_i6hLtr-dfBDc/edit?slide=id.g34981a5734f_0_24#slide=id.g34981a5734f_0_24>. >>>>> I think it's easier to recover from being too high-level (as we've done >>>>> with, say, Wasm, Service Worker and CSS custom paint) than from being too >>>>> low-level (as we've struggled to do with cookies and iframes). So while I >>>>> respect TAG's expertise, I'm not going to lose any sleep over shipping >>>>> despite their concern here. Building a self-sustaining flame >>>>> <https://medium.com/@komorama/the-self-sustaining-flame-84326d2e1645> >>>>> of adoption and leaning into the feedback from the partners who are >>>>> motivated to iterate with us is our best overall defense. >>>>> >>>>> On Fri, Feb 6, 2026 at 2:03 PM Rick Byers <[email protected]> wrote: >>>>>> >>>>>>> Very happy to see this shipping! Just a couple questions. >>>>>>> >>>>>>> On Fri, Feb 6, 2026 at 4:56 PM Daniel Rubery <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> One correction here: our web platform tests are now complete. >>>>>>>> >>>>>>> >>>>>>> Thanks! Have a wpt.fyi URL? >>>>>>> >>>>>>> On Friday, February 6, 2026 at 1:31:57 PM UTC-8 Chromestatus wrote: >>>>>>>> >>>>>>>>> *Contact emails* >>>>>>>>> [email protected], [email protected], [email protected] >>>>>>>>> >>>>>>>>> *Explainer* >>>>>>>>> https://github.com/w3c/webappsec-dbsc/blob/main/README.md >>>>>>>>> >>>>>>>>> *Specification* >>>>>>>>> https://w3c.github.io/webappsec-dbsc >>>>>>>>> >>>>>>>>> *Summary* >>>>>>>>> To enhance user security and combat session theft, Chrome is >>>>>>>>> introducing [Device Bound Session Credentials (DBSC)]( >>>>>>>>> https://developer.chrome.com/docs/web-platform/device-bound-session-credentials). >>>>>>>>> This feature allows websites to bind a user's session to their >>>>>>>>> specific >>>>>>>>> device, making it significantly harder for stolen session cookies to >>>>>>>>> be >>>>>>>>> used on other machines. >>>>>>>>> >>>>>>>>> *Blink component* >>>>>>>>> Blink >>>>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%22> >>>>>>>>> >>>>>>>>> *Web Feature ID* >>>>>>>>> Missing feature >>>>>>>>> >>>>>>>>> *Motivation* >>>>>>>>> Reduce session theft by offering an alternative to long-lived >>>>>>>>> cookie bearer tokens, that allows session authentication that is >>>>>>>>> bound to >>>>>>>>> the user's device. This makes the web safer for users in that it is >>>>>>>>> less >>>>>>>>> likely their identity is abused, since malware is forced to act >>>>>>>>> locally and >>>>>>>>> thus becomes easier to detect and mitigate. At the same time the goal >>>>>>>>> is to >>>>>>>>> disrupt the cookie theft ecosystem and force it to adapt to new >>>>>>>>> protections. >>>>>>>>> >>>>>>>>> *Initial public proposal* >>>>>>>>> https://github.com/WICG/proposals/issues/106 >>>>>>>>> >>>>>>>>> *TAG review* >>>>>>>>> https://github.com/w3ctag/design-reviews/issues/1052 >>>>>>>>> >>>>>>>>> *TAG review status* >>>>>>>>> Pending >>>>>>>>> >>>>>>>> >>>>>>> Please correct this to unsatisfied. >>>>>>> >>>>>>> I read the TAG feedback and interpret it as preferring a different >>>>>>> architecture than what our customers have told us they prefer. Does that >>>>>>> seem right? Or is there another reason why we disagree on the >>>>>>> suggestion to >>>>>>> prefer a lower-level design? >>>>>>> >>>>>>> >>>>>>>>> *Origin Trial Name* >>>>>>>>> Device Bound Session Credentials >>>>>>>>> >>>>>>>>> *Chromium Trial Name* >>>>>>>>> DeviceBoundSessionCredentials >>>>>>>>> >>>>>>>>> *Origin Trial documentation link* >>>>>>>>> https://github.com/w3c/webappsec-dbsc/blob/main/README.md >>>>>>>>> >>>>>>>>> *WebFeature UseCounter name* >>>>>>>>> kDeviceBoundSessionRegistered >>>>>>>>> >>>>>>>>> *Origin Trial Name* >>>>>>>>> Device Bound Session Credentials 2 >>>>>>>>> >>>>>>>>> *Chromium Trial Name* >>>>>>>>> DeviceBoundSessionCredentials2 >>>>>>>>> >>>>>>>>> *Origin Trial documentation link* >>>>>>>>> https://github.com/w3c/webappsec-dbsc/blob/main/README.md >>>>>>>>> >>>>>>>>> *WebFeature UseCounter name* >>>>>>>>> kDeviceBoundSessionRequestInScope >>>>>>>>> >>>>>>>>> *Risks* >>>>>>>>> >>>>>>>>> >>>>>>>>> *Interoperability and Compatibility* >>>>>>>>> *No information provided* >>>>>>>>> >>>>>>>>> *Gecko*: No signal ( >>>>>>>>> https://github.com/mozilla/standards-positions/issues/912) >>>>>>>>> >>>>>>>>> *WebKit*: No signal ( >>>>>>>>> https://github.com/WebKit/standards-positions/issues/281) >>>>>>>>> >>>>>>>>> *Web developers*: Positive ( >>>>>>>>> https://github.com/mozilla/standards-positions/issues/912#issuecomment-2204012985 >>>>>>>>> ) >>>>>>>>> >>>>>>>>> *Other signals*: >>>>>>>>> >>>>>>>>> *WebView application risks* >>>>>>>>> >>>>>>>>> Does this intent deprecate or change behavior of existing APIs, >>>>>>>>> such that it has potentially high risk for Android WebView-based >>>>>>>>> applications? >>>>>>>>> *No information provided* >>>>>>>>> >>>>>>>>> >>>>>>>>> *Debuggability* >>>>>>>>> *No information provided* >>>>>>>>> >>>>>>>>> *Will this feature be supported on all six Blink platforms >>>>>>>>> (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?* >>>>>>>>> No >>>>>>>>> The initial support for TPMs is Windows-only. This feature will >>>>>>>>> eventually support all platforms, as we integrate with the >>>>>>>>> OS-specific key >>>>>>>>> generation/usage mechanisms. >>>>>>>>> >>>>>>>>> *Is this feature fully tested by web-platform-tests >>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>>>>>>>> No >>>>>>>>> >>>>>>>>> >>>>>>>>> *Flag name on about://flags* >>>>>>>>> enable-standard-device-bound-session-credentials, >>>>>>>>> enable-standard-device-bound-session-persistence, >>>>>>>>> enable-standard-device-bound-session-credentials-refresh quota >>>>>>>>> >>>>>>>>> *Finch feature name* >>>>>>>>> DeviceBoundSessions >>>>>>>>> >>>>>>>>> *Rollout plan* >>>>>>>>> Will ship enabled for all users >>>>>>>>> >>>>>>>>> *Requires code in //chrome?* >>>>>>>>> False >>>>>>>>> >>>>>>>>> *Tracking bug* >>>>>>>>> https://crbug.com/355059881 >>>>>>>>> >>>>>>>>> *Estimated milestones* >>>>>>>>> Shipping on desktop 145 >>>>>>>>> Origin trial desktop first 135 >>>>>>>>> Origin trial desktop last 139 >>>>>>>>> Origin trial desktop first 142 >>>>>>>>> Origin trial desktop last 144 >>>>>>>>> DevTrial on desktop 135 >>>>>>>>> >>>>>>>>> *Anticipated spec changes* >>>>>>>>> >>>>>>>>> Open questions about a feature may be a source of future web >>>>>>>>> compat or interop issues. Please list open issues (e.g. links to known >>>>>>>>> github issues in the project for the feature specification) whose >>>>>>>>> resolution may introduce web compat/interop risk (e.g., changing to >>>>>>>>> naming >>>>>>>>> or structure of the API in a non-backward-compatible way). >>>>>>>>> *No information provided* >>>>>>>>> >>>>>>>>> *Link to entry on the Chrome Platform Status* >>>>>>>>> >>>>>>>>> https://chromestatus.com/feature/5140168270413824?gate=5110303886409728 >>>>>>>>> >>>>>>>>> *Links to previous Intent discussions* >>>>>>>>> Intent to Prototype: >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/60bae138-43ee-4525-a549-461f241e9ae5n%40chromium.org >>>>>>>>> Intent to Experiment: >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/515ba278-c5fc-4ee0-8e88-21f34851778an%40chromium.org >>>>>>>>> Intent to Experiment: >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXLL9AD6SSyUXpDcSB9m8y9nVnnNzAMTK6qmui%3DzKnM8G_5A%40mail.gmail.com >>>>>>>>> >>>>>>>>> >>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>> <https://chromestatus.com>. >>>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "blink-dev" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to [email protected]. >>>>>>>> To view this discussion visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2e43fba2-6da6-4cce-817d-9dd998ccb50cn%40chromium.org >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2e43fba2-6da6-4cce-817d-9dd998ccb50cn%40chromium.org?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "blink-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> >>>>> To view this discussion visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9degdS%2BRRgWOsr99ZfZLZFObkN95GonAM7C%2BU9ZA9MDQ%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9degdS%2BRRgWOsr99ZfZLZFObkN95GonAM7C%2BU9ZA9MDQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXLL8OZw3JqWm-xa%3Dk2AZ4k5h5bBdtFWFmE%2BvbN%2B1hMZ3GFg%40mail.gmail.com.
