I am creating this thread to start a discussion on how IPFS can be used to improve data availability and reduce Issuer hosted data dependence. I am very interested in actively pursuing this topic for my MSc thesis and am looking to learn about the community’s thoughs on this.
The usage of IPFS is mentioned several times in this Forum as well as in the github page.
My understanding from reading those is that one desirable feature of this system is to not be dependent on certificate Issuer’s hosted data.
At this time Issuer hosted data is required to:
Verify that a certificate has not been revoked;
Retrieve certificates - Altough a certificate receiver may hold a copy of the certificate on its certificate wallet, he may chose to share the certificate by sending a URL linking to the Issuer’s copy (the Issuer should have a copy).
Topic 1) is somewhat complex and is already being discussed on another post.
Regarding topic 2) wouldn’t it be possible to have an issuer automatically make the certificate available via IPFS?
I think this could be implemented either in Cert-tools or Cert-issuer.
Please let me know your thoughts on this, maybe there are other considerations that I am failing to take into account.
Hi João,
At a high level, absolutely! There are some interesting nuances to think through. Here are my very rough, stream of consciousness thoughts that I’m curious for your feedback on:
In the open badge model, the assertion @id field contains the assertion IRI. This commonly contains HTTP URL where the assertion (certificate) can accessed. It isn’t possible to directly replace this with a (content addressable) IPFS link at this layer, because the full Blockchain Certificate contains the blockchain transaction details that aren’t available when creating the certificate in cert-tools.
This all makes sense; the value of a content addressable file system is the changes to the file change the hash. Some questions: does the certificate need to contain a link to its location including info about how to verify it?Either way, the interesting challenge is how best to use the IPFS stack.
Some options (not exclusive, and could be used in combination).
If we want the link to the certificate with verification info to be in the certificate, we could use IPNS for that value (Allows content to be updated with signature)
We could also break up the certificate into chunks, I.e. Assertion is one chunk in IPFS, referenced by the blockcert envelope.
A broader and more interesting topic: investigate how IPLD could be used. Since Linked data canonicalization is what blockcerts used to find the certificate hash during issuing and verification, this seems like the most natural fit. I’m very curious about this and haven’t had the chance to look into it.
Thanks for starting a thread on this, and I’m eager to hear what you think.
About IPLD, I was recently told that it does not use the same canonicalization algorithm as JSON-LD. I don’t have a reference yet (planning to follow up on this), but I wanted to give a heads up to this thread.
It seems the theme has a relevant importance in present days. The better thing to do is continuing to study on it and then do a conference if something important shows up.
