My name is Kayode Ezike and I am an MEng student working with the Decentralized Information Group (DIG) at MIT for over a year. During my time in the group, I developed a Verifiable Credentials framework on Solid for my thesis. Here it is:
I have plenty of ideas for how I would like to extend this service, but I am also always happy to receive feedback from the community. For any questions, comments, or concerns, feel free to reach me on this thread or my e-mail (kezike13@gmail.com). Also, be sure to consult the README.md, which includes steps for setup and launch of SolidVC and additional notes, which address some of the idiosyncrasies of the platform.
Can this replace blockchain or cryptocash in some way?
I have seem that ontology-DID project tried to do some similar thing. Glad to see that SoLiD App don’t need to rely on block chain for verifiable claim.
Thought we don’t need to actually use “ontology project” now, “ontology project”'s documentations verification_provider and claim are good source for understanding verifiable claim I think. @kezike Do you think the applications they described are relevant to your project solid-vc?
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.
Is there any update on this? I’m looking into a practical solution using Solid with VC/OpenBadges. If I don’t hear back, I’ll post separately on this topic. Thanks!
Thanks for your response! I’d written you an email some months ago, perhaps it was sent to spam.
I tried to set up your repo (on Ubuntu 18.04) but ran into a number of issues, mainly around what seemed to be unescaped variables in shell scripts (for example, ./publish_key.sh: 32: ./publish_key.sh: Syntax error: "(" unexpected.
EDIT: I just tried again, and even with these errors the framework seems to work. Might have been confusion on my end as I’m still getting oriented here.
The project I’m working with wants to explore decentralized VC so it fits in with our current development, I’m working on a user-friendly proof of concept. A mid-level library to support this type of workflow would be ideal.
Your repo refers to a paper for ESWC 2019, is that available now?
I’m glad the framework is working for you now. I have published a paper for my thesis, but ultimately did not publish to ESWC 2019, as the platform still had a great deal of outstanding developments to be made before it could be accepted as a working platform. Since then, solid-vc has long been brought to a stable state and I actually delivered a brief demonstration of it in a call with the Inrupt team in March. The associated thesis paper has already been submitted and accepted and it is also entitled “SolidVC - A Decentralized Framework for Verifiable Credentials on the Web”. It should be available in DSpace soon.
In the meantime, if you would like to setup another call, we could either do it 1-on-1 or if there is enough interest on this thread, I would be happy to setup a group call, as I have been receiving some other offline requests about the platform lately.
