Re: [w3ctag/design-reviews] Early Design Review for Device Bound Session Credentials (Issue #1052)

drubery left a comment (w3ctag/design-reviews#1052)

> If there are situations where it would be too disruptive to reject a token, the site can make a call to defer token renewal until after the present exchange is complete. For lower-stakes transactions, the site can engage the refresh process. That could be a redirect at the tail end of an exchange or a supplemental signal via another channel (like a HTTP response header field) that causes the client side of the application to initiate a refresh.

This would impose significant costs for any site adopting DBSC. Arnar had some thoughts about this kind of approach [here](https://github.com/w3ctag/design-reviews/issues/1052#issuecomment-2975084078). There is no technical blocker to it, but in our estimation, the increased adoption cost will make the feature infeasible for most sites to use.

I do agree that if a site had the right client-side framework that mediated all their network requests, they could achieve the security goals of DBSC with lower complexity. The server could indicate in the response that the token is expired and the client should refresh and retry, the framework would do the refresh and retry, then pass the authenticated response back to the application code. What we're aiming to do with DBSC is to make that mediation part of the browser so that sites don't have to overhaul their client-side code to get the security benefits of DBSC.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1052#issuecomment-3198232952
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1052/3198232952@github.com>