This pattern of burying TLS inside of application payloads is popping up all over the place. People realize that securing the transport isn't the same as securing the application, which often hops over multiple transports.
Exactly right. Application layer trust, with the transport and security layers abstracted away. This is important, since app developers typically can't control the transports from end to end, or at scale.
Data removal from Kafka for GDPR compliance is trivial in this setting. You just purge your keys. There are also key rotation and revocation protocols that are part of Ockam and we're making them simple to use from our libraries.
The underlying cryptography in Ockam SecureChannels comes from the Noise Protocol Framework (created by one of the authors of Signal Messenger's protocols). The Noise Framework protocols have many published security proofs and is gaining adoption in multiple secure systems. We are proposing an alternative to SSL/TLS but this alternative is well proven/understood in terms of it security guarantees.
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.
E2e for Kafka usually shows up as a mechanism to encrypt each item differently, because that has a bigger use-case in it.
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.
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.