wavelet--Interoperable Trust Domains = WAVE's KEY Differential. You write:
"I understand how trusted domains work in a microsoft network, but assume that is not what is being refered to with Interoperable Trust Domains."
A couple points. 1. WAVE's Attestation Server combined with Utility Services makes possible Interoperable Platforms within a single trust Domain. But this is a CLOSED SYSTEM. To use your example, if you are registered with a Microsoft Domain you can ONLY download applications that are registered with the Microsoft Trust Domain. If there is a neat Trusted Application outside of MS Trust Domain that you yearn for, you are out of luck.
THERE IS NO FUTURE IN CLOSED SYSTEMS. (And there is NO FUTURE for WAVE's Attestation Servers in a CLOSED SYSTEM, because there is no compelling reason for Trust Domains to use them, when other competing Attestation Servers, become available.)
Of course, MS would LOVE to have its Trust Domain be the ONLY Trust Domain available for ALL Developers. That is to say, Have ALL developers Register with the MS Trust Domain. No doubt, Bill Gates is going to say to JAVA developers: Trust me! I can accommodate you, and your unique Security Protocols. When you want to upgrade, I have a wonderful new Microsoft OS with a big crypto library devoted to your every whim and demand.
Some fear that Microsoft is going to achieve this dominant position. THERE IS ABSOLUTELY NO WAY MICROSOFT CAN ACHEIVE THIS OS MONOPOLY AGAIN!!!!
2. An Interoperable Trust Domain is a SYSTEM which allows ALL Trust Domains their autonomy and independence. NO Single Trust Domain can DOMINATE! If you request an application from MS .NET, you request it, and the .NET application is downloaded to the Embassy Platform. The Emassy Platform has an Embassy OS with a crypto library, which will encrypt/decrypt the .NET application. You then might want an application from IBMs WebSphere. The Embassy Platform "reprograms" itself through the Embassy OS, to meet the security requirements of the IBM WebSphere application and you go through the same process.
OR: You might want to download an Application that would require a MS Applet to interact with an IBM Websphere Applet to produce a Service, in fact Embassy is designed to accept up to 32 Applets from DIFFERENT TRUST DOMAINS! and allow then to interact seamlessly together to provide the user with complex a complex service(this is of course the dream of Trusted Web Services. Where you would have Search Engines searching through an UDDI library for the very best applets to download on to the Embassy Platform).
Here is some additional info from a S. Sprague CC. Brought to you by our own UnCleverName:
"The “EMBASSY Trust System”, which sometimes we abbreviate as ETS, and is the next slide, is made up of many different components. From a Developer Kit that allows third party applications, to develop applications that run on the EMBASSY chip, to the Trust Assurance Network that distributes those applications, to the actual chip that provides the physical security of our system, to the trusted operating system of EMBASSY which manages the loading and unloading of those applications depending upon what is needed, to ultimately to the secure little applets themselves. In this way it’s possible for us to be compatible with almost every security system that’s out there today. We can run every cryptographic algorithm. We can run every different form of authentication. The only real issue is, can you program a little applet to do whatever it is that you want it to do, whether it is keeping a high score in a game, or doing DES based encryption, you can write an application to perform those different functions. It’s very similar to having a personal computer to do word processing vs a typewriter. Someone invents spell checking. It’s very easy to add spell checking to your Apple II computer. It’s really hard to add spell checking to your typewriter.
The other thing that is very important in a programmable security system is that there are “Independent Trust Domains.” And this is the next slide. Where each individual third party service has its own independent trust domain. So if VISA has an application, which has secrets, those secrets are not exposed at all to a similar application for American Express or an application from a corporate enterprise. So that the third party service providers can all feel comfortable in utilizing the technology and knowing that when they’re in control of the chip, it’s only there for their purposes and when someone else takes control it then shifts over to that other person’s application and the original one is protected. This independent trust domain is a fundamental competitive advantage for EMBASSY in our European banking applications, which I’ll get to in a minute.
It also means that we can do a very broad range of applications. In moving to the next slide, from consumer relationship systems to distributed transaction systems to different types of content. So we’re trying to provide again a general purpose platform and then an economic model that allows anyone who wants to use that platform to pay us for access to the platform and/or to share with us transactional fees from the applications that use that platform. So there is a very broad range of economic models. And we think the economics of a deployed EMBASSY device are very compelling. I’ll again touch upon that a little later in the presentation.
News 
Market Data 
Discover 
