Opentimestamps for issuing & verifying

Technical
1

An idea from yancyribbens (github), and I’m u0001f3a2 (github) working on the issue. (trying to bypass url limitations for new users)

I’ve looked through the documentation and the source code of cert-issuer on
https://github.com/blockchain-certificates/cert-issuer, and it seems like using opentimestamps to issue and verify the certificates could be possible. I’m not quite certain how things would go exactly, but here is some basic steps on how it would go:

  1. the issuer would sign the unsigned certificate.

  2. the issuer would use opentimestamps to commit the certificate to the blockchain

3.using the certificate, the verifier will be able to verify the certificate with opentimestamps.

Therefore, there would be the certificate itself, an unforgeable data from the certificate (probably the hash of it) that can be signed by the issuer. Since opentimestamps issues timestamps in a batch, the batch issuing process wouldn’t be necessary.

I think this would decrease the fees related with issuing certificates, and simplify a lot of transaction handling part of the issuer and verifier. I’m relatively new to the whole blockchain certificates in general, so feel free to give any feedback!

2

Using opentimestamps would simply be handing the fees and transaction handling to a 3rd party service. You can currently batch many certificates into a single blockchain transaction with cert-issuer. Plus, my understanding of opentimestamps is that it would also create a OTS file that is required to verify integrity? cert-issuer embeds transaction information (receipt) straight into the blockcert.

The url requirement for new users is to provide recipient ownership of their own certificate since it embeds the recipient bitcoin address into the certificate.

3

The main purpose of this is to reduce the transaction fee for a smaller batch of certificate issuances. Ideally, if the opentimestamps servers are reliable enough, there would be basically no transaction fees, given some restrictions (OTS files and so on.). Even though the issuing fee is somewhat small now, you never know for sure what could happen. I’m suggesting this as a side feature rather than as a main protocol to allow some issuers to issue certificates without spending bitcoin.

4

I do see the appeal to wanting to use opentimestamps to offload some of the maintenance and fees to another service, but something similar has been on my mind and wondering if it would solve your problem as well.

Do you think if there were a service like opentimestamps specifically for blockcerts that it might accomplish the same thing?

Say every interval (daily, hourly, etc.) all of the queued up blockcerts that the community submits would be issued together by a single service, let’s call it openblockcerts. After issuance is complete, openblockcerts could provide the finalized blockcerts that has the receipt information in it already (much like how you have to wait for opentimestamps to issue and provide the final OTS file used for verification).

2 things come to my mind immediately. For 1,

I wonder if something like this is already in place in blockcerts. A field that allows the issuer to add a signature. It’s been awhile since I’ve looked into every detail of what could be in a blockcerts, but I do think something like this may be required for openblockcerts here as well.

For 2, the issuer address in the certificate HAS to match the actual bitcoin address doing the issuing. This means that the openblockcerts address has to be known beforehand and the person using openblockcerts has to include this address into their certificate first, before sending it off to be queued by openblockcerts. Otherwise, when cert-verifier-js checks to see if the address matches, it’ll fail verification.

I believe if #2 is required, then #1 would be required as well to have some sort of additional verification. Anyone would be able to issue a certificate using openblockcerts, so the issuer identity of openblockcerts won’t hold much weight alone. The true test will then become whether or not you trust the entity that signed the certificate in the first place.

I haven’t given it the most amount of thought, but I personally would much rather not rely on opentimestamps and the restrictions of OTS files but instead have a service like opentimestamps specifically for blockcerts, since receipt information is stored in the json itself.

5

Thanks for your reply.

I wonder if something like this is already in place in blockcerts.
Yes, I believe the certificate itself holds a signature of the issuer for verification purposes.
I think your idea would be another way to pass on the issuing procedures to a third party to reduce cost. What I’m looking for is the most cost-efficient way of issuing a certificate, so this sounds good.

As you mentioned, this will be quite straightforward assuming your second thought holds. The third party service issuing blockcerts will just add additional requests for certificates to its batch and issue it normally through blockcerts. I wonder if this is viable. I haven’t thought of the specialized platform for blcokcerts, but I’ll look through what is available to make it work.