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.
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.
What is the timeline for v3 implementation?
Thanks
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.
Thanks
Arun
Hi Anthony,
Thanks a lot for sharing this 
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 ?
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).
Best,
Guillaume
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.
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 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).
Looking forward from following this topic !
Guillaume
Updated the original post to reflect the final copy of the proposal: https://nbviewer.jupyter.org/github/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/BlockcertsV3.pdf
Hi,
Is there any update on the v3 proposal official status? (still draft, finalized, … ?)
Thanks
Bump
Any news on this, please?
Hey Guillaume,
This post was not brought to my attention so I am only seeing your question now.
As to where we stand with blockcerts v3:
What we are now looking into:
Thanks Julien!
A few more questions:
Are there versions of the BlockCerts v3 proposal that are more recent than https://nbviewer.jupyter.org/github/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/BlockcertsV3.pdf and https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/draft-documents/BlockcertsV3.md ?
There have been many talks (outside of the Blockcerts community) around OpenBadges and VCs. Does Blockcerts v3 have an ambition concerning OpenBadges compatibility.
Hi Julien,
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?
Thanks!
@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?
Thanks
Hi @jackblock,
you can play with issuing v3 certs with this branch: GitHub - blockchain-certificates/cert-issuer at v3. Verification with cert-verifier-js and blockcerts-verifier already supports v3.
Great news. Thank you
Hello,
I tried to create a V3 Certificate to test.
I realize when I generated the model from cert-tools, the file is missing some fields.
The cert-tools project, in GitHub, is outdated (10 months ago). I’d like if it’s possible to create a model and sign it for test purposes.
To be more specific, I’ll try to explain by giving an example.
The code available to use V3 is cert-tools/create_v3_alpha_certificate_template.py at master · blockchain-certificates/cert-tools · GitHub.
Looking inside the code, I can see that the field ‘issuanceDate’ is receiving a string constant(’|DATE|’). I can’t see a parameter to set up this information correctly.
I also can’t see the parameters to set up the title… narrative, etc.
Please, could someone help me to understand the V3 cert-tools?
I just post my proposal here !!
If you want to issue V3, you can use my PR!!