Some of you may already know and/or have been following along. Over the last few months, since Rebooting the Web of Trust 9, we have been coming up with drafts and proposals for Blockcerts V3 for the alignment of Verifiable Credentials & Decentralized Identifiers. The Verifiable Credential Data Model has just been officially recommended as a standard by the W3C, and the DID Working Group Charter has been officially recognized by the W3C as well. This is all very exciting and we are excited to begin utilizing these standards that will really propel this community forward.
For the most part, the concepts and flow are all the same for now, with an optional ability to use Decentralized Identifiers instead of Issuer URLs. The main changes are on the data model itself, to align with the Verifiable Credential schema.
Thereâs a few proposed items that may be of interest to the community, such as using a display URI to support more than just HTML, and some of the ways we could handle an âissuer profileâ inside of a DID.
I think the forum is a good place for now - either this thread or another if you feel it appropriate. Once the final paper is crafted, weâll send out an official email via the CCG mailing list which would be another good place for discussions, Iâd imagine.
Thanks for sharing this. have couple of questions.
What is the plan to support additional public blockchains? Understand that it does not affect the v3 schema. But cert-verifier need to be updated to support.
Cert-issuer & cert-verifier-js are pretty friendly for allowing additional blockchains besides just Bitcoin & Ethereum. There hasnât been strong enough desire for more, TBH. But we encourage and would welcome any contributions for more blockchains.
Good question. By aligning up with the Verifiable Credential and Decentralized Identifiers standards, it really opens up the gates to what is possible and all that could be implemented (Verifiable Presentations, DIDAuth, DIDComm, etc.).
Weâre hoping to be in a good place with the basics (at least with a beta) within 6 months. Including things like âIssuing VC-based BCâs with cert-issuerâ, âVerifying them with cert-verifier-jsâ, âResolving issuer DIDs using the Universal Resolver w/ cert-verifier-jsâ, etc⌠From there, it will be iterations and ecosystem support.
Hi Anthony, Thanks for the quick response. Agree and understand with the timeline for v3 implementation. On supporting other blockchains, our team has already modified cert-verifier to support Algorand blockchain. We deployed it on our site. Check this. https://verify.proofplum.com/uywcdr
Let me know how we can incorporate the changes in the main branch.
This looks very promising at the first sight, itâs very dense and Iâll have to have a deep look at it.
We are proposing a service endpoint for BlockcertsIssuer
On a first glance I was especially wondering about this. If I understand correctly, anyone could implement this service and use its own implementation. However it does not make sense to replace any âeasy to implementâ issuer.json uploaded on any Http server by a âmore complexâ service. So I guess that your proposal would be to host a service for the whole community.
If thatâs the plan, would the service be operated by Learningmachine or some kind of Blockcerts foundation / association ?
On the service itself : which kind of implementation do you have in mind ?
A centralized service with one classic centralized DB
A centralized service using a decentralized DB
Other
Related question : how would this service prevent anyone to register a false DID identity ? For instance for now I can create an issuer.json and pretend to be MIT and deliver myself certificates.
I guess a possible implementation could be an Ethereum smart contract that acts as a registry of issuers. Anyone could submit an issuer identity, but only approved EOAs could validate it. In the beginning, approvers could be a few select EOAs belonging to well-known people in the community. We could also imagine a co-optation system, where a new University could ask to become an approver and where at least 2 existing approvers could validate this request. The only real drawback of this implementation would that the image could not be stored on the blockchain, but it could be an URL to an image on the issuer website (decentralized file storage is far from being production-ready IMHO).
Thanks for taking a look and providing feedback @GuillaumeDuveau!
I should have provided a bit more clarification around that. In the VC world they call it âservice endpointsâ but it doesnât necessarily mean it has to be some sort of complex service. Youâre right that anyone could implement this service but in the end it simply just needs to spit out a list of revocations similar to the format which it is in today.
So the âserviceâ could be the same revocations.json url youâre using today, or it could be an endpoint that dynamically creates the json list. What happens behind the scenes is up to the implementer, we would just need it to produce a list of revocations that verifiers could consume.
More advanced revocation endpoints could be created in the future to take advantage of decentralization - weâre just not there yet I think. One futuristic idea would be to check for the âtypeâ of BlockcertsRevocationListService to see if itâs a URL or smart contract, for example, so that verifiers can take the appropriate action (either http request or ethereum smart contract query). Not sure if anyone else in the VC / DID ecosystem has thought of these things for revocation lists as service endpoints but it should be possible.
No, this would need to be hosted (whether simply a json file or an endpoint) by the issuer or whoever is managing the issuerâs profile - like how itâs done today.
Itâs mostly a terminology change happening here, to comply with out things are done in the VC / DID world. But it does open up the possibility of more advanced things in the future.
Indeed I missed the fact that it would not even have to be a real service but can stay also a static JSON. In that case it seems pretty neat.
Like I said, the only remaining problem would be that still nothing could prevent to fake an issuer. Itâs a major drawback in a system whose purpose is to increase the trust in certificates. Iâm talking about only the issuer profile here (the content resolved by certificate.badge.issuer.id), not the revocation list (for the revocation list, thereâs no identity problem once the issuer ID is established).
Since the VC and DID model do not care how the DID resolution is done (like you said, just a static JSON or a service building the JSON dynamically), a model like I suggested can very well be implemented while staying fully VC/DID compliant. Itâs a very easy thing to develop. The smart contract can be pretty straightforward (more or less a micro DAO managing a registry), a simple Node.js service connected to Ethereum through Infura and the App to interact with the SC has just a few transactions to implement).
what do we need to do in order to do so (or what we deem bare minimum)?
Whatâs missing on MerkleProof2019 verification? - this is in a greater scheme of things, to allow other VC verifiers to verify a blockcerts. This is likely not blocking on the path to releasing blockcerts V3.
There have been many talks (outside of the Blockcerts community) around OpenBadges and VCs. Does Blockcerts v3 have an ambition concerning OpenBadges compatibility.
I have tried to verify a V3 Verifiable credentials with the latest work in the cert-verifier-js and blockcerts-verifier repositories, but was unsuccessful as it is throwing an error that it is not a valid Blockcerts credential. What certificate did you use for a successful verification?
@GuillaumeDuveau at this moment the documents you are referring to are the latest ones. I guess some more work is required on that but it does not depend directly from me so I canât give you a more detailed answer at this point (because I donât know these details).
Regarding VC and Open Badge, I will try and get a clearer answer but my understanding is that Blockcerts V3 is moving away from Open Badge to embrace VC. I havenât had time to look into Open Badge definitions but I think current contexts are incompatible. Maybe there is a way to support both? It would have to be discussed.
@JamesLawton, the V3 examples in blockcerts-verifier and cert-verifier-js pass the verification. Could you point to a document so that I can take a look? FYI I am going to be on holidays for a bit more than 2 weeks starting tomorrow, so you may expect a delayed answer. Sorry about that.
Iâve been reading about V3 docs and seems fit with my Proof of Concept. Any updates on the timeline? Would like to see if I can play around even in a test version?
