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
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.