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

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

[This](https://tess.oconnor.cx/2025/06/complexity) was on my reading list today.  It seems pertinent to mention it.  We seem to be coming at the complexity question from different angles.  I see [this](https://raw.githubusercontent.com/w3c/webappsec-dbsc/main/reg_and_refresh.svg) and [this](https://github.com/w3c/webappsec-dbsc/blob/main/README.md#session-registration-instructions-json) as pretty significant sources of complexity.

My first goal is to remove the reliance on the browser clock to drive refreshes.  That seems like a pretty significant flaw in the proposed design, because servers cannot predict when refreshes will occur.  (At least not without incurring a bunch of complexity: you can read the browser clock from JS, pass that back to the server, and update the expiration time.)

> We do not believe this scales well.

I suggest that you are criticizing an aspect of the complexity that is emergent, not inherent.  That is, the suggestion that I make isn't normative: a server can choose any approach it deems appropriate for refreshes.  I don't agree with your assertions that the availability properties are different: the design you propose creates a resource with similar availability requirements.

A rate limit on TPM accesses is sufficient.  It is probably essential.  Modulo concerns about creating a cross-site information leak when multiple sites concurrently access the TPM in order to determine whether they are interacting with the same device. After all, if you refuse to sign a request and are forced to delay or retry requests, the request that is eventually made will include updated cookies that will convince the server that you have recently signed successfully.  The question is then only whether to delay (at the browser end, by serializing requests) or make requests without signatures (which will need to be retried somehow).

That leaves proactive refreshes.  I don't see that as viable, frankly.  The browser isn't in a position to predict any future usage of the application that might depend on TPM interaction.  For instance, just because there is ongoing interaction with a site that has requested signatures, that doesn't mean that hitting the TPM is necessary.  In the end, any knowledge about what level of TPM access is needed is the application's business.  That means we can/should leave that to sites to manage.

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

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