RE: Formal Proposal: A Deterministic (No-Token) Alternative to DBSC

Hi all,

As promised, please see the video linked below which explains our vision at a high level.
Video: https://winmagic.com/en/resources/knowledge-center/videos/


Additionally, our newly published article provides a deeper technical explanation of our concepts, specifically how login and session protection can be addressed by ONE solution.
Cyber Defense Magazine (March 2026, pgs. 259–265):  https://www.cyberdefensemagazine.com/newsletters/march-2026/mobile/index.html#p=259


I hope this helps frame our recent submission. We look forward to your response.

Cheers

Thi Nguyen-Huu | CEO

Tel: +1 905.502.7000 x 3288  |  Toll Free: 888.879.5879
thi.nh@winmagic.com<mailto:thi.nh@winmagic.com> |  www.winmagic.com<http://www.winmagic.com/>

WinMagic Corp. | 11-80 Galaxy Blvd.
Toronto, ON  |  M9W 4Y8 |  Canada | www.winmagic.com<http://www.winmagic.com/>
[cid:image001.png@01DCAB25.8383B9E0]<http://www.facebook.com/WinMagicInc>  [cid:image002.png@01DCAB25.8383B9E0] <https://twitter.com/winmagic>   [cid:image003.png@01DCAB25.8383B9E0] <http://www.linkedin.com/company/winmagic>   [cid:image004.png@01DCAB25.8383B9E0] <https://www.winmagic.com/blog/>
[A person typing on a computer  AI-generated content may be incorrect.]<https://winmagic.com/en/zero-trust-mandates-next-gen-iam-here-is-why/>

From: Thi Nguyen-Huu
Sent: Monday, March 2, 2026 7:37 PM
To: Daniel Rubery <drubery@chromium.org>
Cc: dveditz@mozilla.com; public-webauthn@w3.org; public-webappsec@w3.org; Sergei Nikitin <sergei.nikitin@winmagic.com>
Subject: RE: Formal Proposal: A Deterministic (No-Token) Alternative to DBSC

Hi Dan and all,

I had some time to think about your points and came up with the below. If more feedback or questions arise we will discuss further.

Thank you for the thoughtful response and for sharing the DBSC perspective. It’s helpful to walk through these architectural trade-offs together.
I’d like to offer a few observations:
1. On the Malware Challenge: We believe that if malware has sufficient privilege to access memory at the transport layer, it likely has the same access to session cookies or private keys within the browser's memory space. In either model, the true security anchor is the TPM. When we bind identity to the silicon, the private key remains protected from exfiltration regardless of whether we are at the application or transport layer.
2. On Implementation Complexity: This leads us to the question of how to best implement that hardware binding. DBSC is a sophisticated approach to protecting existing cookie-based sessions. However, we’ve found that by utilizing mTLS with the TPM (for which we’ve provided a reference implementation), we can achieve that same hardware-anchored security using the internet’s native transport language.
The advantage we see is that it requires no new protocol changes or added application-layer overhead. It simply directs the existing mTLS "handshake" to the TPM instead of a software file.

To clarify the point regarding TLS termination, I’d like to offer a perspective on how mTLS naturally aligns with existing infrastructure:
3. The Proxy as the Secure Entry Point: In architectures where a Proxy terminates TLS, that Proxy effectively serves as the "Front Door" for the application. For a connection to be secure, the Proxy must perform the same robust handshake that a backend server would. Since most modern Proxies (such as Nginx, HAProxy, or Cloudflare) already provide mature support for mTLS, they are already equipped to verify the TPM-bound identity from the endpoint at the transport layer.
4. Bringing Infrastructure to Par: If a specific Proxy or middleware does not yet support mTLS, updating it to do so simply brings it to parity with industry-standard security practices. This is a foundational improvement that benefits the entire network stack, rather than a specialized change for a single protocol.
5. Comparative Complexity: From our observation, DBSC requires significant new logic at both the Proxy and Server levels to parse new cookie formats, manage session-binding assertions, and verify Proof of Possession (PoP) tokens at the application layer. By contrast, the mTLS + TPM approach utilizes the existing, standardized handshake logic. It requires no new protocol changes; it simply utilizes the hardware already in most endpoints (TPM/Secure Enclave) to create a continuous identity pulse.

We believe that instead of adding new layers to the application, we can achieve a more direct and stable result by letting the transport layer do its job.

We have mostly described a solution to protect the session after a (FIDO2 or any) authentication while negating the reliance on vulnerable bearer tokens. The benefits of transport layer protocol actually extend much more than that. We would be glad to elaborate more in some presentation if it’s helpful.

Best regards,

Cheers

Thi Nguyen-Huu | CEO

Tel: +1 905.502.7000 x 3288  |  Toll Free: 888.879.5879
thi.nh@winmagic.com<mailto:thi.nh@winmagic.com> |  www.winmagic.com<http://www.winmagic.com/>

WinMagic Corp. | 11-80 Galaxy Blvd.
Toronto, ON  |  M9W 4Y8 |  Canada | www.winmagic.com<http://www.winmagic.com/>
[cid:image001.png@01DCAB25.8383B9E0]<http://www.facebook.com/WinMagicInc>  [cid:image002.png@01DCAB25.8383B9E0] <https://twitter.com/winmagic>   [cid:image003.png@01DCAB25.8383B9E0] <http://www.linkedin.com/company/winmagic>   [cid:image004.png@01DCAB25.8383B9E0] <https://www.winmagic.com/blog/>
[A person typing on a computer  AI-generated content may be incorrect.]<https://winmagic.com/en/zero-trust-mandates-next-gen-iam-here-is-why/>

From: Thi Nguyen-Huu
Sent: Monday, March 2, 2026 1:36 PM
To: 'Daniel Rubery' <drubery@chromium.org<mailto:drubery@chromium.org>>
Cc: nadalin@microsoft.com<mailto:nadalin@microsoft.com>; dveditz@mozilla.com<mailto:dveditz@mozilla.com>; mwest@google.com<mailto:mwest@google.com>; public-webauthn@w3.org<mailto:public-webauthn@w3.org>; public-webappsec@w3.org<mailto:public-webappsec@w3.org>; Sergei Nikitin <sergei.nikitin@winmagic.com<mailto:sergei.nikitin@winmagic.com>>
Subject: RE: Formal Proposal: A Deterministic (No-Token) Alternative to DBSC

Hi Dan and all,

Thank you very much for your feedback, Dan. I really appreciate it.

Can we wait for more feedback and comments before we can address more or all comprehensively?

We should have by tomorrow a video which might make this easier to understand. The video won’t answer Dan’s deeper question/comment though. And we will. Thanks.

Cheers

Thi Nguyen-Huu | CEO

Tel: +1 905.502.7000 x 3288  |  Toll Free: 888.879.5879
thi.nh@winmagic.com<mailto:thi.nh@winmagic.com> |  www.winmagic.com<http://www.winmagic.com/>

WinMagic Corp. | 11-80 Galaxy Blvd.
Toronto, ON  |  M9W 4Y8 |  Canada | www.winmagic.com<http://www.winmagic.com/>
[cid:image001.png@01DCAB25.8383B9E0]<http://www.facebook.com/WinMagicInc>  [cid:image002.png@01DCAB25.8383B9E0] <https://twitter.com/winmagic>   [cid:image003.png@01DCAB25.8383B9E0] <http://www.linkedin.com/company/winmagic>   [cid:image004.png@01DCAB25.8383B9E0] <https://www.winmagic.com/blog/>
[A person typing on a computer  AI-generated content may be incorrect.]<https://winmagic.com/en/zero-trust-mandates-next-gen-iam-here-is-why/>

From: Daniel Rubery <drubery@chromium.org<mailto:drubery@chromium.org>>
Sent: Monday, March 2, 2026 1:20 PM
To: Thi Nguyen-Huu <thi.nh@winmagic.com<mailto:thi.nh@winmagic.com>>
Cc: nadalin@microsoft.com<mailto:nadalin@microsoft.com>; dveditz@mozilla.com<mailto:dveditz@mozilla.com>; mwest@google.com<mailto:mwest@google.com>; public-webauthn@w3.org<mailto:public-webauthn@w3.org>; public-webappsec@w3.org<mailto:public-webappsec@w3.org>; Sergei Nikitin <sergei.nikitin@winmagic.com<mailto:sergei.nikitin@winmagic.com>>
Subject: Re: Formal Proposal: A Deterministic (No-Token) Alternative to DBSC

You don't often get email from drubery@chromium.org<mailto:drubery@chromium.org>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
CAUTION:This email originated from outside of the organization. Do not click links, open attachments or respond unless you recognize the sender and know that the content is safe.

Hello,

Chiming in from the DBSC perspective. By giving up the regular challenges, I don't think you're getting the security properties you want. With pre-shared keys, local malware can steal the symmetric key and use it from a different device. That forces you to regularly rotate the symmetric key. Protecting that rotation is challenging and leads to exactly the complexity you claim to avoid.

At a high-level, it is definitely attractive to try to make an authenticated transport layer, and has been attempted before (you even mention Token Binding in your whitepaper). DBSC operates at the application layer because TLS termination frequently happens at a distance from authentication checks. Various enterprise middleware and reverse proxies do this, and need to be updated to propagate the identity information across the transport. Cookies are the current standard for authentication, and are transmitted at the application layer. That makes it significantly more feasible to attach the device binding at the application layer.

Thanks,
Dan Rubery


On Mon, Mar 2, 2026 at 8:40 AM Thi Nguyen-Huu <thi.nh@winmagic.com<mailto:thi.nh@winmagic.com>> wrote:
Dear Anthony, Dan, and Mike,

With the release of Chrome 145 and the graduation of DBSC to stable , we are submitting an alternative architectural approach that eliminates the "Procedural Ceremony" of session management.
Our proposal, PADIT (Post-Authentication Device Identity in Transaction), moves identity assurance from the application layer to a hardware-bound mTLS connection. By utilizing the FIDO2 PRF extension or TPM keys as entropy for a TLS 1.3 External PSK handshake, we establish a deterministic state where the existence of the communication is the mathematical proof of identity.

Attached for your review:

  *   Formal Letter: Outlining why the transport layer is the natural home for identity.
  *   The PADIT Whitepaper: A deep dive into the "No-Token" transport-layer approach.
  *   Whitepaper: "Architecting for a Secure Internet," detailing the roadmap for DIT (Device Identity) and LIT (Live Identity).

We have simultaneously reached out to the IETF TLS Working Group regarding the transport-layer implications and request the opportunity to present this model at an upcoming WebAuthn or WebAppSec meeting.

Sincerely,
Thi Nguyen-Huu
Founder and CEO, WinMagic Corp.

Tel: +1 905.502.7000 x 3288  |  Toll Free: 888.879.5879
thi.nh@winmagic.com<mailto:thi.nh@winmagic.com> |  www.winmagic.com<http://www.winmagic.com/>

WinMagic Corp. | 11-80 Galaxy Blvd.
Toronto, ON  |  M9W 4Y8 |  Canada | www.winmagic.com<http://www.winmagic.com/>
[cid:image001.png@01DCAB25.8383B9E0]<http://www.facebook.com/WinMagicInc>  [cid:image002.png@01DCAB25.8383B9E0] <https://twitter.com/winmagic>   [cid:image003.png@01DCAB25.8383B9E0] <http://www.linkedin.com/company/winmagic>   [cid:image004.png@01DCAB25.8383B9E0] <https://www.winmagic.com/blog/>
[A person typing on a computer    AI-generated content may be incorrect.]<https://winmagic.com/en/zero-trust-mandates-next-gen-iam-here-is-why/>