Ockam looks super cool. I've been thinking about trust in our networks and I think that there's a lot left on the table to be leveraged from these sorts of frameworks.<p>The old school method is "if it's in the network it's trusted". Obviously (in retrospect) this is terrible.<p>The new thing is Zero Trust, where you have point to point authentication. Ockam gives you this at an application layer, which is critical if your application serves APIs across trust boundaries (ie: "this API can be called by user group A, this one from B).<p>Further, Ockam also enables a sort of tunneled trust where you can have applications A, B, and C, and B can be untrusted, and A can communicate with C across B. This unlocks a bunch of things like encrypted delegation (C can know that B has been delegated permissions from A).<p>Really cool stuff. Excited to see it evolve.
Does the threat model include malicious system software on the endpoints? Or slightly differently, have you looked at any mechanisms to provide encryption when in use.
Looking at the setup code here, this looks a lot like SSL reinvented over Kafka (instead of over TCP), which is not a bad thing, just the mechanism feels a lot like you've automated a tcpdump into the protocol by making the handshake packets persisted in the stream + committed to disks.<p>This somewhat makes sense if you're going to buy Kafka from a cloud provider without the ability to trust them, but the trust here is not very useful beyond securing transport trust.<p>E2e for Kafka usually shows up as a mechanism to encrypt each item differently, because that has a bigger use-case in it.<p>Kafka being an immutable log, there is no way to go back and delete data for a customer who asks for a data deletion or legally mandated GDPR data removals.<p>Being able to shred the keys is very useful if you have a destination or source attribute based keys - instead of purging data out of the kafka log you can throw away the key.