Regarding the standard itself metadata and display are entering the default standard. metadata comes in replacement of metadataJson and remains a stringified JSON that will allow consumers to register specific data which are too unique for issuances to be defined in the context.
display brings in a little bit of novelty, allowing issuers to now anchor (base64 encoded) images or pdfs, in addition to the more classic HTML.
It is also possible to now reference a DID for the issuer, paving the way to a programmatic reinforcement of the trust with the issuer. What we do there is retrieve from the DID document the public key of the issuer that was used to create the issuing address (either on Bitcoin or Ethereum), and derive that key at verification time to ensure we find the same issuing address.
This is just the beginning for V3, as in the future we want to explore ways to reinforce the trust in the issuer identity, but also improve the recipient experience when handling and sharing their certificates, as well as bring them into the trust triangle by allowing recipient’s DID into the verification process.
Stay tuned for more, and as always we welcome the community’s feedback, opinions and contributions!
How are you doing?
Is it possible to integrate the cert-issuer project to NextJS version 14? Or is it possible to send HTTP requests to cert-issuer APIs to issue my some certificates?
You’d need to run it as a side by side API.
But yes it’s doable. The dockerized version is supposed to help you do that more quickly but I think at this time it’s facing some issues that I haven’t had time prioritize, so it will need a bit of tweaking.
Thank you for your reply.
I have already figured it out to send APIs, I have updated some source code of node wrapper, it works fine now.
Anyway, thank you for your time!
But I still have an unclear thing according to the blockcerts verifier.
So after issuing certificates, transactions are correctly ocurring with some gas fee.
But when verifying it on https://blockerts.org, “The address used to issue this Blockcerts does not belong to the claimed issuer.” error is occurring.
I think this is the last error for my blockcerts project, lol.
Why “0x” is removed automatically?
That’s why the verifier can’t find the transaction id and as a result, the above error is occurring.
I will look forward to hearing from you asap.
I will attach my screenshots.
I think from what I’m seeing in the screenshot of the credential that you are using a blockcerts issuer (issuer property links to an example issuer profile), while you probably signed (and anchored) the transaction with your own ETH address and private keys.
The verifier checks that the issuer profile bound to a certificate is indeed one that lists the public keys (aka issuing addresses) as belonging to them.
To fix this issue you will need to create your own issuer profile, listing the issuing address, and I would suggest adding a verificationMethod property to your proof that references in the same issuer profile document a public key from which you can derive your issuing address. You can take a look at this up-to-date and working example: https://www.blockcerts.org/samples/3.0/issuer-blockcerts.json#key-1
