# E2EE encryption for Solid

## W3C Solid Community Group: Special Topic Meeting

* Date: 2024-11-05T12:00:00Z
* Call: https://meet.jit.si/solid-cg
* Chat: https://matrix.to/#/#solid_specification:gitter.im
* Repository: https://github.com/solid/specification
* Status: Draft

## Present

* [elf Pavlik](https://elf-pavlik.hackers4peace.net) - Solid CG
* Niko from NextGraph.org
* Dawei Chen — [SII/SoCo/ANU](https://sii.anu.edu.au/)
* Anushka Vidanage — [SII/SoCo/ANU](https://sii.anu.edu.au/)
* Sergio J. Rodríguez Méndez — [SII/SoCo/ANU](https://sii.anu.edu.au/)
* Graham Williams — [SII/SoCo/ANU](https://sii.anu.edu.au/)
* Tony Chen — [SII/SoCo/ANU](https://sii.anu.edu.au/)
* TimBL - Solid CG
* [Michal](https://id.mrkvon.org) - [SolidCouch](https://solidcouch.org)
* Rahul
* Hadrian (late)

## Announcements

### Meeting Guidelines
* [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
* [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md).
* No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
* Join queue to talk.
* Topics can be proposed at the bottom of the agenda to be discussed as time allows. Make it known if a topic is urgent or cannot be postponed.

### Participation and Code of Conduct
* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/).
* [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/)
* Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome.
* If this is your first time, welcome! please introduce yourself.

### Scribe
*

---

## Topics

### Solid Community AU

#### Encryption

https://github.com/solid/specification/discussions/689

* Anushka: [Presenting slides](https://anu365-my.sharepoint.com/:b:/g/personal/u6482057_anu_edu_au/EQtz6fiznVxPmitWGdiCPoABIQRZGXcl5VQOTMIYVmiIFw?e=HTllPU)
* ...: Over past couple of years we developed architecture to easily develop 3rd party applications.
* ...: Mainly interested in privacy and security, and concept of trust-no-one principle.
* ...: We came up with the idea of encrypting data and decrypting it only on the client side.
* ...: [explaining keys]
* ...: We encrypt data file using a random encryption key, different from the master key. Key itself is encrypted using the master key. In they priv/pub keypair the private key is encrypted with master key. We store encrypted random enc key for each file. The master key is not stored in the pod, only known by the owner themselves.
* ...: How do we then share the data? Data has path and access list. We use Bob's public key to encrypt the random encryption key of the file and bring it to Bob's pod. Bob then can decrypt it using their private key.
* eP: where the random key get's encrypted with Bob's key?
* ...: Bob needs the random key to decrypt the file. Encryption key has to be share securely.
* ...: This happens client side, in the app.
* eP: Is it a dedicated app handing that.
* Anushka: we have packages for flutter and dart. Those packages have code for that.
* ...: Based on that we developed Secure POD Data Model, mainly by Sergio.
* Sergio: This concept map represents the ontology. We have clases, Person, POD, App etc. Then each class has several attributes, keys etc. On the right we have File. It captures how the user with an app that uses a pod will store a set of files and how those files can be shared.
* ...: This ontology is a proposal, it captures the design explained earlier. We want to use more formal definition and namespace. We had email exchange with Sarven who registered solid namespace with w3id.org
* eP: How apps have the key made availabel to the, how does it work across user's devices?
* Anushka: In Flutter we not only develop mobile applications, we have native windows and macos apps. Most of them are cross platform. If the user has multiple devices, as long as they log in to the pod it doesn't matter. Pod stors all the keys except the master/security key.
* eP: And the master/security key, is it shared across devices, how apps can access it.
* Anushka: In the pod we have a key-check in the pod, just to identify the key. It is user's responsibility to remember the master key.
* Niko: Congratulations, it is very interested work. It reminds me a bit of how we do it with PGP.
* Niko: You are talking about encryption of files, does it include triples or mostly binary files?
* Anushka: We just encrypt the entrie file, it can include anything binary, triples etc.
* Niko: Is it only manipulating the data, not acls etc ?
* eP: rambling about treating RDF as serialized files
* Niko: If you put RDF as data file, the server doesn't know it is RDF and it is not distinguishable is it RDF or not.
* Anushka: In this architecture we just treat the content as a file as a whole. We use GET and PUT.
* eP: What content type do you use if you do GET? Especially on GET response and PUT request.
* Niko: If it is text it only uses the facility of Solid Pod to store files not RDF.
* TimBL: SolidOS, works fine on the filesystem of a laptop. Some people rely on content negotiation. Another way is to have .ttl in the filename and run on top of this. This is another way of working.
* Anushka: We get it as text and do encyption and description on the app.
* eP: do you rely on file extension to know if it can be parsed with some RDF parser?
* Sergio: We would like to expend this initial architecture using also binary files. The metadata would be stored in turtle files and point to the binary files. It would be part of the payload. We are still planning to expend.
* eP: Are you referring to the Description Resource?
* Niko: Regarding modification of the data. Given that file/resource are the same concept at this moment. How do you modify it? Let's say one of the users wants to modify it / upload the new version.
* Anushka: To edit the file, it happens on the app side.
* Niko: Do you change the key or use the same key?
* Anushka: You can use the same key or generate an new key.
* Niko: I understand it is a symetric encryption key. It is a poor practice to use the same key.
* Anushka: Some applications use the same key but it is not recommended. We have yet to implement the change of the key in our package.
* Niko: Presenting NextGraph
* ...: We have E2EE, only clients have access to the decrypted data. The servers only see encrypted data and help with synchronizing it. The architecture is a bit different. We think it is important to add CRDT to the mix.
* ...: Since server doesn't controll edits, you can have conflict across different devices and different users modifying the data.
* eP: Should we do quick overview of CRDT?
* Niko: In order to avoid conflicts, you can imagine git trying to solve conflicts and user has to resolve conflicts. In CRDT we have a way to store data in a format that helps auto-resolving the conflicts.
* Sergio: In the terms of text, is the problem arrives with encoding?
* Niko: not utf type of encoding, there are libraries for the text which give each character and id etc. I use existing libraries - Yjs and Automerge for text and I developed CRDT for RDF.
* ...: Binary files are immutable and we don't use CRDT for them.
* ...: Formatted text also have their CRDTs, similar CAD software can use specialized CRDT. They are specialized based on the type of data.
* Niko: The main difference is that all the encryption mechanisms are done in the lower level. We use binary formats for that not RDF. At the level where RDF API is presented we don't see that metadata. It is also similar difference to Noel's work on CRDT, where Noel is using RDF to represent CRDT.
* ...: NextGraph is not based on PGP, it uses convergence encryptoin. Instead of encrypting the whole resource each operation gets encrypted. The client is doing it. Sidenote, ActivityPods whichis Solid compatibility layer behaves as client of NextGraph.
* ...: In convergent encryption we hash the content of the update and use it as a key for the encrypion. The encrypted result is hashed again and is used as id of the commit. If you have both then you can decrypt the operation. Then we put that data into DAG (directed acyclic graph), it is similar to git. It can be very linear when you work on a single divice, but with multi device and/or multi user you start having branches. The merge is happening automatically.
* ...: Showing a slide from https://file.nextgraph.org/download/f8da4518b9d7d14ff052f539e5f80d89
* Niko: The question about groups, in this example we have two users collaborating on the resource. We can extend it with groups, the group can have access to several resources. There is rotation of keys where you want to remove permissions.
* eP: Niko presented NG recently: https://www.youtube.com/live/OAEOoaV-1bA?si=6yn28qY8WMHHs0Xm&t=578
* Anushka: In terms of the keys, I understand that every commit has a different symetric key. Whe two people push different commits to the same file, each commit will have a different key. Are those keys shared?
* Niko: There is also a system of private and public keys. PubSub is used to distribute the encrypted updates and the encrypted keys. In your approach you encrypt it with the public key of the users, in NG it is encrypted with shared key of everyone who can update the resource. There is a mechanism using the priv/pub key to get the shared key. It is like a session key in SSH or TLS.
* Niko: NG DID has a public key of the document, which is the identifier which will never change. Who has the private key? With this private key we generate a first certificate in the chain and those certificates are used to specify who can edit and which keys are allowed.
* ...: Once the certificate is signed, the private key is thrown away. When new editors want to edit the document, we need the public key of Bob. Alice as an owner will be able to create a new certificate where she puts her public key and add's Bob's public key, plus reference to the previous certificate. This attects that both Alice and Bob can edit the documents. Every time they make a new commit they sign that commit with their personal private key.
* ...: In the commits in the DAG, there are also signatures of each commit made by the author.
* eP: What happens when Alice want's to revoke Bob's access?
* Niko: There are different levels, Alice is the admin and Bob is the editor. ActivityPod is also mapping it to WAC. This is transparent to the user's of Solid pod, it manages public keys of the user. Later we can delegate it in future versions. There also can be hybrid system, when there is a Solid compat and at the same time NextGraph directly.
* eP: How users manage their keys? How does it work across devices and apps?
* Niko: Each user has a private key, as well as devices have their keys. We use React, Svelte, maybe Vue soon. We would like eventually to have APIs for Flutter.
* ...: Each device including a browser tab has a key. User can authorize on which devices the user's key can be used. But the peer's key is used to do the actual signatures.
* ...: For permissions we have mechanism used for revoking permissions, which involves rotating keys. New certificate is created without Bob's public key, it also revokes their access to the PubSub. For that the symetric key has to be rotated, it happens in NextGraph not in Solid. It involves a threshold cryptosystem. Which works if not everyone is offline.
* Hadrian: How do you use DID `ng` and why do you have a DID for a document, which I don't see how it can scale.
* Niko: I think your intuition is good. It creates a lot of metadata if we create a public key for each document. We do it because we are in the local-first setting. Here we can have concurent edits. We need IDs for the commit and the document. You can create new documents also offline, where the ID is created. This happens wihout any coordination with any peers. Only when the peer goes online the created document is shared. The triples will already use it in statement. We use public key which is unique globally.
* Hadrian: What compromizes do you see at scale. Some documents get archived at some point etc.
* Niko: Static data / imutable data. It will not be important to store it in RDF resource. This we only use the symetric key for the encryption. This is much less metadata.
* Michal/mrkvon: I saw that you are using DIDs. I'm curious how do you find the linked document?
* Niko: Showing Alice knows Bob slide. As for the resolution, to dereference (get) the resource. DID is longer than just the public key, it includes more metadata, including how to join the PubSub topic and get the updates. It not only gives you the snapshot but it also gives you capability to subscribe and get the new updates. The DID includes IP of the broker (can be mutiple if there are more IPs and brokers). If the IP changes there is a mechanism to update that. In the statements, only the public is used and the metadata from DID is decomposed in other triples. The metadata can change but we don't want the ID to change.
* eP: Is that extra information saved in the same document/graph?
* Niko: It is saved in the same graph. There are an additional triples using NextGraph ontology.
* Niko: https://docs.nextgraph.org/en/framework/nuri/
* eP: What are the communication channels?
* Anushka: my presentation has email addresses, please feel free to send us a messge
* Niko: Please give me suggestion how to make NextGraph system better.

#### Authorization

#### Packages for dart/flutter