LGTM2 I'd love to see this ship. It'd also be great to have this spread to more platforms :D
On Wed, Feb 11, 2026 at 2:25 AM Daniel Rubery <[email protected]> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXLL8OZw3JqWm-xa%3Dk2AZ4k5h5bBdtFWFmE%2BvbN%2B1hMZ3GFg%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/CAOmohSKGDSC8pE4C%3DPLZYMkL6WjeAGECeAHjuCW3FjE5dnrLNw%40mail.gmail.com.
