If the user has access to a reference to some data — and the correct decryption key — they have the ability to read the data. This is correct-by-construction: there mere fact of having this tuple confers read access. In the case of unencrypted data, you may think of the decryption key as being the identity function.
- 1.Reference (e.g. CID, URL)
- 2.Decryption key (e.g. AES256-GCM, ChaCha20-Poly1305)
In the private section, each directory contains pointers and keys for all of its children. As such, granting access to a directory also grants access to all of its children. This is granted “merely” by the parent relation. This works recursively. So in the image below, someone with access to the key that gives access to the root of the orange area can access the red area, but not vice-versa.
Granting another user, machine, app, or browser tab read access to some resource (e.g. WNFS) is as simple as handing them a copy of the key and a pointer to the relevant data.
This is self-contained information, and transport agnostic — any secure channel works. In Fission’s system, this is generally handled directly in WNFS via the
shared_by_otherssegments. We also transfer data via a bootstrapped secure channel on top of a WebRTC-based pubsub, and even directly in query parameters.
Revocation is possible by either changing the address of the data (e.g. by adding a nonce), by changing the encryption key, or ideally both. This is largely a moot distinction, since encrypting data with a new key changes the protocol-level data (the encrypted blocks), and thus the address.
If another user has a copy of the data being revoked, either by having it on their local disk or with a hard link to the same CID, they will have continued access to this data. This is the same as having downloaded a copy of the data previously — we can’t reach into someone else’s computer and delete files.
Note that removal of access via rotation is a very wide action. Subdeleation of read access of that data when not in a child relationship needs to be re-granted. Once a new key is used for the data, authorized users need to be granted the new key.
The Web Native File System handles this via the
shared_by_otherssegments. If there’s a ”cache miss” in your
shared_by_others, you may check the target file system’s
shared_by_mesegment, and look up the new key.
This extends to other resources as well. WNFS happens to be an effective data-layer substrate for key exchange broadly.