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

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

Thank you for the feedback!

We've taken a little time to go through this. This proposal definitely shifts complexity out of the browser, but we believe that it pushes too much complexity onto the server. Given the failures of previous attempts at device binding, we are aiming to keep server-side adoption costs low, and moving all management of refreshes to the server increases adoption costs substantially. We believe that requiring servers to coordinate all the pending refreshes will make it impossible for large sites such as Google to actually adopt. In Chrome's implementation, the browser defers refresh operations if there is one already pending for the same session. I will soon mention that explicitly in the spec as a recommendation ([PR](https://github.com/w3c/webappsec-dbsc/pull/193)).

In particular, you suggest "That can be managed by directing refresh requests to a resource on that system that does not have Signed cookies associated with it. That resource can coordinate any cookie refreshes, forwarding requests to the affected path as necessary." We do not believe this scales well. Given this resource's critical function in user authentication, sites need this resource to be highly available. Being both highly available and consistently only letting one refresh progress is extremely challenging in a distributed system. Failures of consistency for well-meaning sites or careless sites omitting this functionality can lead to the browser monopolizing the TPM, a shared resource on the machine. By making refresh logic more explicitly browser-mediated, we can naturally add some behaviors to reduce TPM load:
- Per-session quotas for TPM signatures
- Holding one refresh while another is pending
- Proactive refresh when the browser isn't doing many TPM operations

We have some thoughts on the latency considerations and config representation soon to come, but this point is the major difference between the two proposals. We believe the substantial reduction in server-side complexity justifies the complexity in the browser. Additionally, if you agree we want browser mediation on signatures, we believe it's better to have a separate abstraction there (a "device bound session") rather than muddling the existing abstraction (giving "signed cookies" significantly different behavior than regular cookies).

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

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