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

Hi Simone,

I am the Product Manager at WinMagic.

We are preparing a formal Threat Model document that follows the structure outlined in RFC 3552 Section 3 and the W3C Threat Modeling Guide. It will cover: 
- Asset identification (session integrity, key material, endpoint posture)   
- Threat actor tiers (remote attacker, local user-mode malware, kernel-level compromise, malicious relying party, network attacker)   
- Specific attack scenarios (credential exfiltration, AitM proxy, session hijacking, session persistence after posture change) 
- Residual risk analysis (what DIT/LIT does NOT protect against, and why)   
- Privacy analysis including same-origin isolation, cross-origin tracking surface, and data minimization 

We expect to have this ready for your review in the next few days. In the meantime, if there is a specific threat scenario or privacy concern you'd like us to prioritize, please let us know and we will address it first. 

Thank you for pushing us toward the rigor this proposal deserves.

Best regards,

John O’Leary, CCSP  | Product Manager  
Email: john.oleary@winmagic.com | Toll Free: 888.879.5879 

WinMagic Corp.  |  80 Galaxy Blvd., Unit 11
Toronto, Ontario  |  M9W 4Y8 |  Canada
www.winmagic.com

Authenticate. Encrypt. Achieve.
________________________________________




-----Original Message-----
From: Simone Onofri <simone@w3.org> 
Sent: Wednesday, March 4, 2026 6:12 AM
To: Thi Nguyen-Huu <thi.nh@winmagic.com>
Cc: Daniel Rubery <drubery@chromium.org>; dveditz@mozilla.com; public-webauthn@w3.org; public-webappsec@w3.org; Sergei Nikitin <sergei.nikitin@winmagic.com>; John O’Leary <John.OLeary@winmagic.com>
Subject: Re: Formal Proposal: A Deterministic (No-Token) Alternative to DBSC

[Some people who received this message don't often get email from simone@w3.org. Learn why this is important at 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.


Hi Thi,

It is easier to explain with a Threat Model, which is why I asked for it. It is a concept we have in W3C [1], and the IETF has it as well [2].

Otherwise, we risk discussing partial aspects and losing sight of the overall picture.

What I asked (and why) is explained here [3].

Thank you,

Simone

[1] https://www.w3.org/TR/security-privacy-questionnaire/#threats

[2] https://datatracker.ietf.org/doc/html/rfc3552#section-3

[3] https://www.w3.org/TR/threat-modeling-guide/


> On 4 Mar 2026, at 03:00, Thi Nguyen-Huu <thi.nh@winmagic.com> wrote:
>
> Hi Simone and all,
>
> Actually, maybe it's easier to explain "how it works" in some simple terms:
>
> 1) Usually we have TLS, then FIDO2, then more TLS sessions.
>
> 2)  With DIT (Device Identity in Transaction): we use mTLS with a TPM device key, then FIDO2, then more mTLS sessions. ==> These sessions are secure as the FIDO2 authentication has verified that the user is using the device (mostly).
>
> 3) LIT (Live Identity in Transaction):
> First we need to describe the Live Key Traditional user verification 
> requires user interaction.
> The breakthrough: The Live Key. A long lived, policy governed cryptographic key - anchored in TPM hardware or software - it exists only while the verified user on the verified device under valid conditions is present. If for example the user is not "on the device" the Live Key disappears.
>
> With LIT: We use mTLS with the Live Key, and all TLS transactions carries the identity assurance that the user, device and conditions are met.
>
> The Live Key can also be used as a FIDO2 key, it's device bound - and user-bound.
> Unlike pure FIDO2 key the Live Key includes user presence/verification, as FIDO key or as mTLS key.
> --
>
> I hope this helps. Let me know. We would be glad to do:
>> 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
>
> Cheers
>
> Thi Nguyen-Huu | CEO
>
> Tel: +1 905.502.7000 x 3288  |  Toll Free: 888.879.5879 
> thi.nh@winmagic.com |  www.winmagic.com
>
> WinMagic Corp. | 11-80 Galaxy Blvd.
> Toronto, ON  |  M9W 4Y8 |  Canada | www.winmagic.com
>
>
>
> -----Original Message-----
> From: Thi Nguyen-Huu
> Sent: Tuesday, March 3, 2026 7:03 PM
> To: 'Simone Onofri' <simone@w3.org>
> Cc: Daniel Rubery <drubery@chromium.org>; dveditz@mozilla.com; 
> public-webauthn@w3.org; public-webappsec@w3.org; Sergei Nikitin 
> <sergei.nikitin@winmagic.com>; John O’Leary <John.OLeary@winmagic.com>
> Subject: RE: Formal Proposal: A Deterministic (No-Token) Alternative 
> to DBSC
>
> Hi Simone,
>
> Thanks for your questions. I might not understand all correctly but will try to address them based on our architectural perspective:
>
> 1. The Reality of Malware and the TPM
> We acknowledge that if a malware agent has high-level permissions, it can observe most activity on that specific endpoint—even if the transport layer is perhaps more difficult to access than user-mode browser processes. In this regard, our solution faces the same reality as DBSC or any other endpoint-based security. No solution can fully stop a powerful, local malware from 'observing' information on the authentic device.
>
> 2. The Cryptographic Anchor
> However, the critical distinction is that the malware cannot exfiltrate the TPM private key to the attacker’s machine. Because DIT/LIT anchors the identity to the physical hardware at the transport layer, the session is 'non-exportable.' An attacker might watch the user, but they cannot become the user on a different machine.
> In summary, while we cannot stop a powerful malware from seeing what 
> the user sees on an infected machine, we can ensure that the attacker 
> cannot take that identity elsewhere
>
> 3. Complexity and Attack Surface
> While DBSC can also use the TPM to prevent key export, the real question is one of complexity. How complex is the DBSC 'Cookie-Binding' machinery compared to native mTLS? By using the transport layer directly, we avoid the overhead and potential vulnerabilities inherent in managing complex browser-level session credentials.
>
> 4. Regarding Same Origin Policy and Web Privacy Our approach reflects perhaps some of the core principles of FIDO2:
>
> Origin Isolation/privacy: We can use different keys for different servers.
>
> Pre-registration: Keys should be registered beforehand. While mTLS certificates can be used, we believe the FIDO concept of a direct endpoint-to-relying-party relationship is superior.
>
> Hardware Binding: As with FIDO2, keys could be software-based if needed, but the best practice is a device-bound (and user-bound) TPM key. A TPM can maintain many unshared keys, ensuring that activity on one origin cannot be used to track a user on another.
>
> I hope this helps. If I misunderstood something please let me know. Thanks.
>
> Cheers
>
> Thi Nguyen-Huu | CEO
>
> Tel: +1 905.502.7000 x 3288  |  Toll Free: 888.879.5879 
> thi.nh@winmagic.com |  www.winmagic.com
>
> WinMagic Corp. | 11-80 Galaxy Blvd.
> Toronto, ON  |  M9W 4Y8 |  Canada | www.winmagic.com
>
> -----Original Message-----
> From: Simone Onofri <simone@w3.org>
> Sent: Tuesday, March 3, 2026 6:14 PM
> To: Thi Nguyen-Huu <thi.nh@winmagic.com>
> Cc: Daniel Rubery <drubery@chromium.org>; dveditz@mozilla.com; 
> public-webauthn@w3.org; public-webappsec@w3.org; Sergei Nikitin 
> <sergei.nikitin@winmagic.com>; John O’Leary <John.OLeary@winmagic.com>
> Subject: Re: Formal Proposal: A Deterministic (No-Token) Alternative 
> to DBSC
>
> [You don't often get email from simone@w3.org. Learn why this is 
> important at 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.
>
>
> Hi Thi,
>
> Do you have a Threat Model that clearly explains how it works, the threats it mitigates, and how it changes the perspective on the current approach, considering also the Same Origin Policy, and the web privacy issues?
>
> In general, if there is an agent/malware on board the device (depending on the permissions it runs with), it can access process memory and interact with the TPM.
>
> Thank you,
>
> Simone
>
>
>> On 3 Mar 2026, at 22:12, Thi Nguyen-Huu <thi.nh@winmagic.com> wrote:
>>
>> 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/in

>> d
>> ex.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 |  www.winmagic.com  WinMagic Corp. 
>> |
>> 11-80 Galaxy Blvd.
>> Toronto, ON  |  M9W 4Y8 |  Canada | www.winmagic.com<image001.png>  
>> <image002.png>  <image003.png>  <image004.png><image005.png> 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 + TPMapproach 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 |  www.winmagic.com  WinMagic Corp. 
>> |
>> 11-80 Galaxy Blvd.
>> Toronto, ON  |  M9W 4Y8 |  Canada | www.winmagic.com<image001.png>  
>> <image002.png>  <image003.png>  <image004.png><image005.png> From:
>> Thi Nguyen-Huu
>> Sent: Monday, March 2, 2026 1:36 PM
>> To: 'Daniel Rubery' <drubery@chromium.org>
>> Cc: nadalin@microsoft.com; dveditz@mozilla.com; mwest@google.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,  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 |  www.winmagic.com  WinMagic Corp. 
>> |
>> 11-80 Galaxy Blvd.
>> Toronto, ON  |  M9W 4Y8 |  Canada | www.winmagic.com<image001.png>  
>> <image002.png>  <image003.png>  <image004.png><image005.png> From:
>> Daniel Rubery <drubery@chromium.org>
>> Sent: Monday, March 2, 2026 1:20 PM
>> To: Thi Nguyen-Huu <thi.nh@winmagic.com>
>> Cc: nadalin@microsoft.com; dveditz@mozilla.com; mwest@google.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  You don't often get email from drubery@chromium.org. Learn 
>> why this is important 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> 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 |  www.winmagic.com  WinMagic Corp. | 11-80 
>> Galaxy Blvd.
>> Toronto, ON  |  M9W 4Y8 |  Canada | www.winmagic.com<image001.png>  
>> <image002.png>  <image003.png>  <image004.png><image005.png>
>

Received on Wednesday, 4 March 2026 18:55:25 UTC