Hello everyone. I’m happy to find this solution for IPFS. We want to have private content and be able to transfer ownership of the private content to a new user. Thus, we need authentication for the content. This also means that the previous owner should not be able to access the content anymore, while the new owner is able to do so. Is this possible with Ceramic? If so, can you lead me to some links that shows how this can be done? Thanks!
2 Likes
Hi @Mark, thanks for posting to the forum.
There’s a lot to unpack in your question.
First of all, by “access” do you mean read/write access or just write access?
Data on the network is public by default and you can’t really prevent 3rd parties from reading information unless it is encrypted (e.g. using Lit Protocol). However, once someone is able to decrypt the information through whatever mechanism you put in place, they’ll always be able to decrypt it, unless keys are rotated, etc. in which case they’ll be able to decrypt data till the point in time that the keys were rotated, but not data encrypted using the new keys. None of this is trivial - key rotation in blockchain-type systems is a very complex problem. If data is that important to block access to, then it should probably not be on a public blockchain anyway.
Restricting write access is probably easier to achieve. Ceramic streams allow you to change the controller (i.e. the DID that owns the stream), which can be used to transfer ownership from one user to another. I know this was/is supported when a user rotates their own key, but am unsure whether this is supported for transferring ownership from one user to another.
Once your goals are clearer, and we can determine what is and isn’t possible, I can refer you to the right documentation.
3 Likes
Thanks a lot for your reply. So, what we intend to do is to distribute private NFTs. Each NFT is only accessible by the owner (read access). The content itself should be immutable.
Indeed, the owner should be able to decrypt the content, so that the owner is the only one that is able to see the content. We know the risks of copying, but it is a risk we accept. Using the metadata of the NFT, one can prove who is the real owner, which also has value in itself.
The blockchain we are using is made for accessing private metadata, so it is possible to host private metadata there. However, we cannot store images / videos in the blockchain, as the size of the content is too large.
Your answers make sense to me (given my current limited knowledge on IPFS). In case key rotation is very complex, we are not planning to implement it. We are merely looking for some already existing solution (if there is any). If there is not, we of course have to look into ways of implementing the solution ourselves.
Restricting write access is not fully clear to me yet, perhaps it can be used for our case as well.
Does this explain more about our goals or would you like more information? We can of course give more informaton if needed.
I suggest looking into Lit Protocol, they have an encryption-based access control system based on onchain state (note this isn’t an endorsement of their security properties, they are closed-source so I cannot say how secure they are or aren’t, but I know this is the kind of use case they are designed for). As @mohsin said, all data on Ceramic is public by default, unless you encrypt it yourself beforehand.
Also to clarify something from Mohsin’s previous post, he mentioned “Ceramic streams allow you to change the controller” and I want to clarify that this is in fact not supported for Ceramic streams. Some older streamtypes do technically allow this, but this is mostly to support the internal implementation of the 3ID DID method and not intended to be used to transfer write access to streams between users. Newer Ceramic streamtypes, such as those used by ComposeDB, will not allow any form on controller change.
4 Likes
Thanks for the clarification, @spencer!
Thanks a lot for the help guys! I really appreciate your help 
I will take a look at the Lit Protocol.
1 Like
Hi,
could not NFT DID Accounts (**NFT DID Accounts** - Ceramic Developers) be a solution for this issue?
did:nft would not help with the encryption or read-access control. But for write-access control, yes, did:nft would allow transferring who is allowed to write data into a stream. Please note that did:nft is not supported currently and has security issues related to the Late Publishing Attack: Consensus - Ceramic Developers
1 Like
hi @spencer ,
regarding the changing ownership of contents, can DID-session help us?
if we change the controller did to another DID-session in an update stage, does it do that functionality ?
You cannot change the controller DID of a Stream once it is created. You can, however, have the controller DID create a capability (CACAO) delegating the ability to write to that stream to another DID. This is what did-session does internally: the controller of the stream is a did:pkh corresponding to the user’s blockchain wallet, but writes are authored used a did:key generated from a temporary session key that has received a capability granting it the ability to write data on behalf of the controller did:pkh. You could also create new CACAOs yourself to delegate write access from one DID to another. Note though that this doesn’t remove the access from the original DID - the controller DID that is set when the stream is created will be that stream’s controller forever and will always retain full access to write to that stream
1 Like