The "world stop" is pretty easy to implement from a javascript standpoint, [+following discussion on JS]

The problem is that we, and many others, have tons of legacy apps, running on a large number of frameworks, RPC libs, various middleware and data-sync libraries, etc. (raw XHRs in top-level application code seem somewhat rare nowadays); and all this is maintained by a large number of teams with many conflicting priorities. A solution for binding that requires deep rewrites or replacements of those components, esp. time-coordinated for websites that use a common auth stacks across many apps (like we do), is just not going to happen in the foreseeable future.

The same issue applies for independent small developers that rely on open-source or SaaS stacks. They'd be fully dependent on those stacks to provide what's necessary, and then they'd have to do the difficult migration of integrating all this error handling and refresh logic with their business logic (or at least accommodating it).

I guess my thought was to implement DBSC using JavaScript (based on some generic capabilities such as generating cookie values synchronously from a function, TPM API etc) rather than baking the entire functionality of DBSC into the browser. The downside is each webapp would need the DBSC library added to ensure the cookies/tokens were generated, but I don't think any existing code in app would need to change or be aware of it.

I think you could implement DBSC in JS assuming you had a TPM JS API and the whole app flow went through JS. That is a different problem than we are trying to solve.

DBSC appeals to me because it reduces the likelihood of errors by developers during implementation. When dealing with a multitude of APIs that developers should use to secure user sessions, there will invariably be a variety of implementations, some of which may be less than ideal. Furthermore, abandoned libraries become an additional concern. With DBSC, there should also be minimal or no client-side JavaScript. This translates to framework agnosticism and allows the browser to refresh the session even without the website being opened.

Afterwards, I think implementing more security-focused web APIs so developers can create their own implementations would be awesome. But having one incredibly solid way to stop session hijacking that's easy to implement and has awesome defaults is something that we badly need as soon as possible.

So this is probably a dumb question - so apologies in advance, but why not handle the JWT as its currently being handled today with the caveat that it has to have a valid ECDSA Signature?

The client could return the following headers:

Authorization: Bearer jwt
x-jwt-base64: base64 encoding of the jwt
x-jwt-signature: ecdsa signature of the base64 encoded jwt

If the signature fails, it gets 403'd; all other logic is handled as it is currently handled today.

Yeah, certainly you could just create an API like SubtleCrypto which specifically asks implementors to use TPM (or equivalent) storage.

This is more or less what we originally conceived of, as @arnar said above. "Just the basics" a la (and inspired by) WebCrypto but with TPM backing (and a purpose-built API just to ensure that).

I was originally a strong advocate of this approach, where the browser does less and more is done in the webapp, so I am very sympathetic to this argument. As Arnar said above, I don't think the problem is per se TPM access but rather a question of how best to get the complicated bits around state management (of the bearer token) working right, and whether it's better for every website to have to do it themselves (presumably many with shared libraries, of course) or for browsers to just do it correctly.

Aside from the difficulty argument Arnar alludes to above, I will also note that browsers can of course just be smarter in general about things web apps cannot know, such as:

• optimizing bearer token refreshes in anticipation of page loads (like when a user starts typing a URL into the nav bar)
• optimizing bearer token refreshes across origins to deconflict TPM usage

Of course, this is a bit similar to another discussion we had on this repo, about the limitations of TPMs. If TPMs were faster and higher throughput, you might not really care about those constraints, but, well, here we are.

We are considering a JS API for DBSC at some point in the future as well.

I would love to see the day that the browser allows users to register OAuth providers (or others) directly into their browser, and then calling navigate.login() in a webapp would abstract away which provider was actually being used and let the user fully decide. It also would solve the problem of real estate in the "login box" since all providers would technically fit (because you only need one button "Log in with Browser". But I would much prefer to see a full proposal for that feature done correctly, rather than some partial implementation looking only at the end of the flow looking only at sessions. But if that future that is coming, and everyone believes that this exact work, in this exact form will actually bring that reality closer, then I'm all for it. Right now, I'm not drawing the connection though :(

@wparad are you familiar with FedCM (MDN)? That at least has some partial ideas on the real estate problem (often called the "Nascar problem"). Abstracting from the RP's choice of an IdP is harder, because in general RPs need to make some trust decisions there.

There may very well be a future, and not even such a distant one, where OAuth sign-in and authorization plays nicely with DBSC, carrying device-bindings with the IdP/AS over to the relying party. But DBSC is definitely not trying to solve the authentication problem (except in that many of us, myself included, work on things like WebAuthn and FedCM as well)

I see DBSC as kind of orthogonal to signing in, and would think the way forward is to work with for example WebAuthn and FedCM for that since there is great progress happening there. We would prioritize interoperability with existing standards instead of inventing again what others have done.