Thanks for pointing me to the considered alternatives, Daniel. I'm sympathetic to the critique that this could be decomposed into useful underlying APIs, which I understand to be a large part of the TAG's feedback. Have y'all made progress on adding those underlying capabilities in more granular ways in parallel? Are you planning to?
Regardless LGTM3 on this overall package, assuming we have intent to answer the charge regarding decomposed primitives as well. Best, Alex On Tuesday, February 10, 2026 at 9:41:55 PM UTC-8 Yoav Weiss wrote: > 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/63cc5c64-a4b3-465a-8320-e1e33109efb5n%40chromium.org.
