I’ve been delving into the specifications of Solid. As I understand it, if a Data Controller wishes to manage their own data, they can set up a server. In this scenario, all edits and deletions are logged on the Data Controller’s server.
My concern is about the verifiability of this data. It seems to me that this setup might not maintain the authenticity of the data, as the Data Controller could potentially manipulate it. I’m wondering if this issue has been addressed before, or if there’s a reason why such manipulation doesn’t need to be prevented.
To my knowledge, this is a currently ongoing research topic in decentralized systems. This would require an unbiased store to record valuable information one way or another. Having a blockchain component in here would be a decent choice, as transactions by 2+ agents could be queried from the chain as long as the chain is tamper-proof.
Thank you for your response.
I also believe that storing all Solid states on the blockchain could be a solution. This approach would ensure not only authenticity but also consistency. By storing not only the state of Solid but also other Personal Data Stores (PDSs), the chain could provide verifiability and interoperability.
I am trying to figure out how to design it while maintaining privacy.
You could use digital signatures if you want to prevent manipulation. For instance, if you want a verifiable university transcript:
University signs transcript and sends signature + document to user
User/App stores it in the users pod
Other user downloads both, asks the university for the public signature key and verifies the document with it
This way the user has control over the storage (where to put it, who has access, if they want to delete), while the university is the only one who can create/modify such documents. And everyone with access can verify these documents.
And this depends on the type of data you store. Most apps and data you use locally on your computer won’t require authenticity for example (music players, document editors, etc), a Solid equivalent of such apps also won’t require authenticity. But for other apps it will be necessary.
And afaik there’s no standard way yet to do this (ie where to store the signature, which vocabulary to use, etc).
Storing all states would be insanely expensive for many implementations, especially the more popular ones such as Ethereum. Storing a static or rarely changing credential, e.g. a degree or license, could be doable, but rapidly increasing data would be economically unfeasible. And having an entire datastore from a computation perspective is heavy.
Yes, I agree. I recognize that it’s not straightforward to upload all state information. One possibility could be to calculate the hash value of a document in the POD, construct a Merkle Tree structure, and manage the root value on the blockchain. However, we would need to consider how to handle edits and deletions, or status updates. Perhaps we might need two trees: one for logs and another for data logs.
Maybe as a thought, JSON-LD BBS+ verifiable claims or VCs, could be supplied by an Issuer, as input to a pod. Stored in RDF and then reassembled as JSON-LD BBS+ per the needs of a Verifier. That’s the way I see consequential data being handled through Solid. Individual elements being traceable back to Issuers through signatures. Maybe that’s an incorrect view, but I would like to know of a better way, if you have one. Thanks.
Thank you very much. I agree with what you are saying.
My writing was not good enough. I am concerned about how to achieve consistency in whether the PODs where stand-alone files and data (VC, social data, etc.) are stored are up to date.
I feel that what I have written below is the key to the solution. https://forum.solidproject.org/t/hedera-hashgraph/6566/4?u=yudai007004