Blockcerts V3 Proposal - Verifiable Credentials & Decentralized Identifiers

Hello community!

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.

The final paper is getting worked on right now (EDIT: now live here), but we wanted to go ahead and submit the GitHub README for the final draft so that this community to take a look at:

As always we appreciate and encourage all feedback, suggestions, comments!

Anthony Ronning


Awesome! Good job :clap: :clap:

BTW how can we join the specification working group and make proposals, suggestions?

Is this forum a good place? Or maybe somewhere in GitHub?


Good question @davidlj_btca!

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.

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

  2. What is the timeline for v3 implementation?


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.

Let me know how we can incorporate the changes in the main branch.


1 Like

Hi Anthony,

Thanks a lot for sharing this :slight_smile:

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 ?

  1. A centralized service with one classic centralized DB
  2. A centralized service using a decentralized DB
  3. 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.

1 Like

Hey Anthony, thanks for the clarification !

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

Looking forward from following this topic !


Updated the original post to reflect the final copy of the proposal: