Encrypted POD? Is solid designed with this in mind? If not, would it be possible to add?


@taggart wrote:

My organization has several applications that might be interesting candidates to move to solid. We currently store the application data on our own backends, but we could potentially become a POD provider and allow our users to use us or another provider instead. One of our requirements for doing so would be to have a way that data on the POD provider is encrypted in a way that the POD provider itself cannot read. Or maybe put in more generic terms, access control should be cryptographically ensured.

Some of the reasons for doing this include:

  • organized crime, nation-state, etc hacking of services to steal user data
  • data breach through misconfiguation, API bugs, etc
  • physical theft of equipment
  • see https://haveibeenpwned.com/
  • malicious POD providers monetizing user data, injecting ads/malware/etc

The best way to protect the users is for the POD provider to not have access to the data.
Is solid designed with this in mind? If not, would it be possible to add?


There has been some discussion on https://github.com/solid/solid/issues/170 with @panleya and @tatwater and would like to invite more here.


I’m curious (and have a rather limited knowledge of JavaScript crypto) - how could that be done in JavaScript? Is there a secure way to create and store an encryption certificate/secret in the browser, such that the browser can encrypt data before sending it to the POD (and vice versa)?

How would such a secret be moved to a different device such that I can access my POD from different devices?


OK, so I interpret this question as a desire to not need to trust your POD provider.

Now, don’t take my answer as authoritative, and not as an official Inrupt answer. It is more like a braindump, because I think this question is really important and deserves an answer, and it has been open for long enough without one. Anyway, before I try to answer, let me just note a few things:

  1. You don’t need to trust any random POD provider, you can be your own, like I am, by installing the Solid server on hardware under your control. I think this should satisfy many of those who do not want to trust a POD provider, but I realize, not necessarily the poster.
  2. Stopping short of full end-to-end cryptography, the connection is always TLS in Solid, so that part is encrypted. Moreover, it is trivial to encrypt the file system the data resides on. However, this kinda misses the point, since the data will still be in clear text at some point in the Solid backend, and can be intercepted by an intruder or the POD provider itself.
  3. App developers can always encrypt on the client side, and make sure the literals in the RDF are encrypted with the user’s key.

To really address the concerns of the poster, we would need to have the data encrypted on the server side all the way down to disk with a key that the user controls. If the user is the only one who would have access to the data, that’s easy enough, but that wouldn’t be very social. I’m not a crypto guy, but it appears that TLS doesn’t make this easy, TLS connection terminates before we get to the disk. Again, not a crypto guy, it may well be solutions to this, and it would be interesting to hear.

However, there are another two things that makes it hard:

  1. People want to be social, they want to share data.
  2. More advanced apps are likely to soon require a more advanced query system, we might want to use e.g. SPARQL.

Without being a crypto guy, I could imagine that we build a protocol on Solid that uses the Web Access Control for key management to enable sharing keys with the people that you share data with. It doesn’t seem to me that this would require very substantial changes to Solid as it is today. I would require additional protocols, but I suspect it could be done with additions to Solid rather than a more extensive change, and so, to some extent the design of Solid should be accommodating.

Evaluating queries over encrypted data is very much an active area of research in academia. It has been going on for a number of years, and I have noted that quite a lot of this research revolves around RDF data on the Web, and thus, much of the research that is going into this is immediately applicable to Solid.

In conclusion, I think that Solid can enable a future where you don’t need to trust your POD provider, but right now, the shortest path to that is to install it on your own hardware. Beyond that, it will require quite a lot of work, but I certainly see the value of thinking in that direction.


Our users are non-technical and aren’t the kind of people that could setup their own POD provider, they count on us to provide them communication services in the most privacy protecting ways possible. We might be able to educate them what a POD is, explain the concepts of providers and that they have a choice in who they choose as a provider. If we also knew that the POD provider couldn’t see the data, we could explain that rather than give stern warnings that “you better strongly trust your POD providers because they will have access to all your data in the clear”.

It sounds like it would always be possible to build the end-to-end encryption into our web apps on top of solid, but I was hoping there would be some way solid could provide this in a standard way (which would also help prevent app developers from getting it wrong, crypto is hard to do right).


Thank you for your insight, @taggart! Indeed, I think there is a pretty strong case for end-to-end crypto-enabled PODs, as I also think there is a pretty strong for case for verifiable claims, zero-knowledge proofs and that kind of stuff in Solid. Maybe we should see this as a whole. I think it would take some time to get there though.


Let’s say that I want to save my files to a server that is not fully trusted.

For me, integrity is the most important security aspect. If I share some content publicly, I would like some guarantee that the content is not tampered with. This would mean that my (web) application has to cryptographically sign the content, and the web framework need methods to verify the integrity.

Closely followed comes confidentiality. I have some content I would like to keep private. This means that my (web) application has to encrypt the content before sending it to the server.

For this to work, I would need a cryptographic key that I can use for signing and encryption. The key cannot be stored together on the same server as my content. So I would need a trusted party that can safely hold my key.

For instance, the identity, cryptographic keys and the content/files could be serviced by different organizations… Maybe I would pay my identity provider and key holder a bit more than I would for file storage…? :thinking: