Thanks for sharing this @linonetwo! I will attempt to answer all your questions with this post:
-
The work shared is indeed relevant in that it also attempts to implement the Verifiable Credentials spec. The major difference, as you allude, is that it leverages the consistency and persistence guarantees of distributed ledger technology (DLT). In fact, for some time, I was thinking of introducing a ledger construction that would have involved mimicking such a ledger by storing a credential or a batch/block of credentials in a pod, and referencing previous blocks of credentials from each credentials. The justification for this was to enforce a global ordering of credentials in the system, largely for purposes of timestamping and ordered events (ie., it’s important to know whether the last revocation event was before or after the last renewal event for a credential). After spending some time digging down this rabbit hole, I realized that this was not a very constructive way to conceptualize credentials in the context of Solid. For one, a pod owner could always delete a credential, which instantly breaks verification. Two, I am fine using ontology-defined terms, such as xsd:dateTime to represent time and expiry.
-
The decentralized nature of SolidVC is great in that users wield a great degree of control over their credentials. However, one limitation of if it is that users wield a great degree of control over their credentials! By that I mean that while subjects no longer rely on issuers to store their credentials, there are some business cases in which detailed history of past events is critical. For example, a real estate agent is interested to know the credit history of a potential tenant. The freedom of jumping from one issuer to another to achieve new credit scores could make it difficult to truly assess an individual’s solvency (unless issuers indicate in the credential how long they have been doing business with the subject, thereby “derisking” them). With that said, there may be room for introducing some sort of persistence mechanisms for certain types of credentials.
-
Another point about persistence that I may as well bring up now is that there is even a greater case to be
made for making credential status documents persistent. These are essential credentials about credentials, which is how I represent the canonical revocation list. Each credential has this document which describes information, such as whether it is active, expired, or revoked, as well as relevant metadata associated with each of those states. At the moment, this document lives in the issuer’s pod, which means that a verifier may lose access to the history claims that have been made about the credential, should the issuer choose to tamper with this document in any way. There is a case to be made to leverage Web Ledger and/or other specs to maintain these special documents. -
Finally, to answer your question about whether I think that this tool could replace blockchain technology altogether, I would have to say no. I can see this framework playing a major role in Web 3.0 for the purpose of reliably ascertaining the provenance of claims a la Verifiable Claims, but I think the nuances of these technologies, as presented above, render these more as sibling technologies than competitor ones: they are related and coexistent, but not threatening.
Thanks for your questions! I hope that this helps to conceptualize some of the contributions of SolidVC.