dig space, before you bite into that crow
Allow me to clarify and expand upon my previous post.
Stating that "the TPM vendor is responsible for the TDD and TDDL" was an oversimplification on my part, and somewhat misleading. For that I apologize. Let me explain in more detail...
The TPM vendor is responsible for providing the TDD (device driver). This is the software that actually "talks" directly to the hardware. They are also responsible for the interface between the TDD and the next higher layer, the TDDL (device driver library).
You can think of the the role of the TDDL as two-fold:
1. To present an industry-standard interface (TDDLi) to the next-higher software layer
2. To communicate with the device driver (TDD) using the interface provided by the TPM vendor
This means that a TPM vendor does not necessarily have to provide the TDDL, as long as they publish the interface (API) for their TDD so that other parties can "roll their own" TDDL against the TPM vendor's API.
This is actually the most likely scenario, since hardware vendors probably aren't interested in walking too far up the software stack.
What does this mean, particularly as related to your and Doma's discussion?
If you review NTRU's documentation for their CTSS product, you will notice that it comes with a TDDL layer. So the "interoperability value" in NTRU's product is that they have created a TDDL layer that can map TDDLi calls to the TDD API's from any current TPM vendor.
So to answer the question, yes - NTRU has done some work at this level, and yes - that work does have value in the marketplace.
Perhaps we should all have a bite of crow and call it a day.
Regards,
SL