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

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

Thanks! I've discussed this a little and have answers for your questions
1. We believe that for alignment with cookies that are only in headers, we should have a header-only way to register new sessions. This will also be easier for some sites to deploy. A JS API is strictly more powerful though, and does seem like valuable follow-up work.
2. It's possible we could integrate with WebAuthn in the future, but WebAuthn aims for fairly different key management properties (for example, passkey syncing is valuable, but DBSC key syncing is counterproductive). @arnar has some more details on the nuances of silent mediation.
3. We hope that DBSC as written can help these institutions, but it will depend on the specific benefits the services get from using an app. Some of these apps are doing TPM attestation, which we are not planning to expose to arbitrary sites. 
4. We are actively exploring other OS-mediated key storage mechanisms (e.g. VBS keys on Windows). Our goal with the spec is to leave the decision of acceptable key storage mechanisms up to the user agent, including use of unprotected software keys if fingerprinting becomes a significant risk.

Regarding the Sec- prefix, I do think there is value on some of the request headers. In https://github.com/whatwg/fetch/pull/1818, it's stated "a server needs to depend on the accuracy of the information in the header." I definitely think it's better if servers can rely on the value of Sec-Session-Id. I don't have a strong use case for Sec- on Sec-Session-Response, as servers should be carefully validating the value of that header.

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

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