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

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

> deferral is a requirement for DBSC to be adoptable

I continue to struggle with this claim.  Not because I don't agree with it, but the way in which it is used to justify the design you propose.

The challenge here is that cookies expire and applications that depend on those cookies don't want to engage the refresh mechanism for certain flows.  They need to be able to defer the refresh to a time where they are better able to cope with the various side effects of that refresh (like the need to redirect requests a few times).  Your claim is that only the user agent is in a position to be able to engage that deferral.

I don't accept that argument.  Let's break this down a little more.  The site insists that the browser show one of two levels of proof.  A high-assurance signal has a high cost and long lifetime; we can call this a proof.  The site then takes a high assurance signal and issues a short-lived low-assurance signal to the browser to use in lieu of the high-assurance one; we can call this a token.  The site tells the browser that this token is good for some short period, until a certain time.  After that, the browser will stop offering the token and the site will be forced to engage the process for obtaining a proof instead.

If that is the only mechanism you have, then that is disruptive at the point that the token times out.  But there's nothing preventing the site from signaling a much longer lifetime for tokens than it would like.  The token itself can have a timestamp or some other way of indicating that it is stale (this is trivial to accomplish: encrypt a timestamp to yourself).  Then, the *site* can determine whether tokens are too old.

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.

That's your "stale-while-revalidate" notion, but the browser isn't engaged.  The site makes the call.

(I am not following your `assert_in_header` paragraph, sorry.  I don't think that it would be a good idea to have the same key signing stuff that goes to different origins, if that is what you are suggesting.)

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

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