FREQUENTLY ASKED QUESTIONS
Indeed, we do. We in fact consider this as a must for us to also get a better understanding of your company’s specific needs, requirements, and structure, so that we can deliver a product that best fits your profile.
Any institution, may it be a government, a local authority, any corporation or academic institution that issues certificates that wish to have an enhanced level of security and immutability.
The way we have designed our product where multiple certificates are hashed together, enables us to issue an unlimited number of documents per batch.
For every PDF certificate to be issued, we add metadata which is machine readable. This usually contains information on the issuer, the bitcoin address and any additional details to be shown upon validation. The credentials are then hashed together using a merkle tree data structure to produce a merkle root that can potentially represent tens of thousands or more credentials. Upon sending the transaction to a trusted bitcoin node we get a transaction ID (TxID). After few confirmations from the nodes we can be sure that the transaction is safe in the blockchain. To prove that the certificate was issued in the blockchain we need to add some additional information into the metadata of each certificate. This blockchain proof includes the merkle proof, the merkle root, the TxID, the issuing institution and the public address used. In summary, we insert the metadata transaction ID and the Merkle proof back to certificate once the transaction is complete.
Expiration dates can be set during the issuance phase as part of the embedded metadata. Therefore, when the validity period lapses, the verification process will indicate that the certificate has expired.
Indeed. We have developed a methodology whereby certificates can be revoked in case there is a need for that.
No, all the details are being taken care for you. No apps, wallets, tokens or smart contracts involved and no knowledge of blockchain is needed to issue or verify a certificate.
Any already issued certificate has no ongoing dependence on Block.co. These records are anchored on the blockchain that recipients own for a lifetime.
No. Block.co makes it easy to anchor records on a blockchain and takes care of all the details for you.
Yes, but extra charges will be levied and maintenance will have to be done internally.
Indeed. The product allows you to brand your records however you see fit.
It has proved over the years to be the most secure blockchain.
We feel there is not much to gain by using Ethereum blockchain. For more insights regarding our design principles, please read the relevant article on our blog: http://blockco.kinsta.cloud/design-principles-future-directions/
All configuration work will be carried out by us, but we will, however, require a contact person in your IT department to work with during the setup/configuration process and also for any account maintenance work.
No. Our issuing system is a web-based application and can be used by anyone with basic administrative skills.
The issue of Blockchain and GDPR compliance is one that will be discussed for some time still and until legislators decide to do something about it. GDPR legislation was passed in a pre-blockchain era and was fashioned with an implicit assumption that a database is a centralized mechanism for collecting, storing and processing of data. Which of course is no longer the case especially with public blockchains. In discussions we had with MEPs, they confirmed that GDPR legislation is meant primarily to protect against very large corporations exploiting their users’/clients’ personal data to make a profit.
On the positive side, both GDPR and Blockchain at heart share the objective of data sovereignty, so blockchain could become a tool to achieve this objective. Blockchain could in theory make it easier for platforms and applications to become GDPR compliant by having this compliance inserted in the code, thus supporting data protection by design, one of the law’s primary objectives.
The identity of the issuer is important and needs to be verified. We deal with this by including several identity verification mechanisms. Right now, we support two such mechanisms. One is domain verification where the identity is proved by proving ownership of a specific Domain Name Server (DNS). Additionally, we provide a Block.co verification service where we take care of manually verifying the issuers. More verification methods will follow, like Keybase, Github or social media accounts.
With PDF signatures, one uses the traditional centralized Public Key Infrastructure (PKI). The issuers need to register with a Certificate Authority (CA) that will verify their signature and sign in turn that it is valid. This process is centralized and has several single points of failure that we want to avoid using, by decentralization. Please see article on our design principles.
You can see examples of our validators as follows:
- UNIC: https://verify.unic.ac.cy/verify
- University of Finance and Economics Mongolia: https://www.ufe.edu.mn/English/Default.aspx?page=9067
- British University in Dubai: http://18.104.22.168:5000/verify
- Ayia Napa Municipality: http://www.ayianapa.org.cy/validator.php
Please note that the list is not exhaustive as our technology is Open Source Code.