Credentialing Platform Frequently Asked Questions
On this page, you will find answers to the most popular questions of our customers.
Can’t find what you need? Contact us
ISSUANCE OF DOCUMENTS
Metadata relating to the document is attached to a PDF file.
A fingerprint of the whole document (PDF incl. the metadata) is included in a blockchain transaction.
The transaction details are added back to the metadata on the PDF file.
The vPDF documents are disseminated to owners.
Yes. Thousands of documents can be issued in a single transaction.
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 document has expired.
Yes, but extra charges will be levied.
Indeed. The product allows you to brand your records however you see fit. Also, if you choose to disseminate your blockchain-anchored documents using our “public links” or “QR code” features, there’s the option to serve them under a subdomain of your organization.
Block.co offers tailor made packages to accommodate your organization’s individual needs.
Talk with one of our client service officers.
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.
Contact us today to discuss your requirements and provide you with a bespoke package.
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.
No. Our agreements clearly state that we’re not able to share your data with any third party that’s not bound by our data privacy agreement and that isn’t named on our data privacy agreement.
You’re always able to remove data you’ve provided to Block.co from our platform.
Yes, this may be easily done. You can export your issuance data as a spreadsheet, and your certificates as PDFs at any time, free of charge. You may also submit a request at any time to email@example.com if you’d like Block.co to remove data that you’ve provided to our platform.
Your vPDF will be working fine, and vPDF recipients will be able to use them even if you stop using Block.co or even in the case that Block.co does not exist as an entity. You can visit or deploy the open source validating tool at any point and continue using the self-verifiable and self-contained digital documents at your will.
VALIDATION OF DOCUMENTS
Go to an online validator found on issuer’s and other websites.
Upload the VPDF file.
Get an immediate response as to its validity including detailed information.
REVOCATION OF DOCUMENTS
An additional transaction is created on the Blockchain that
invalidates previous records without erasing audit trail. You may also set a date for an automatic expiry in the future.
During validation, a user validating a vPDF document will see the blockchain address that uniquely identifies the entity that anchored (or issued) PDFs. There also is a technical section that displays which blockchain and in exactly which transaction is the PDF’s hash stored. Finally, a timestamp of exactly when the document was anchored on the blockchain is displayed.
We provide a SaaS (or BaaS) platform that greatly simplifies the process of creating vPDFs. We also provide an API that allows programmatic access to the same functionality allowing complex integrations with other platforms.
We would like to be further educated about the product before committing to its adoption. Do you provide any kind of training?
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.
Do we need to have a digital wallet set up through which to make the bitcoin transactions or can you take care of it for us?
We can certainly take care of it for you.
No. Block.co makes it easy to anchor records on a blockchain and manages the transaction fees for you behind the scenes.
No. Our issuing system is a web-based application and can be used by anyone with basic administrative skills.
Recipients receive their vPDF documents via email, and are able to share them for a decentralized and independent validation with whoever they choose to.
You have full control over the recipients, the appearance and other email settings through our platform.
Indeed. We have developed a methodology whereby documents can be revoked in case there is a need for that.
Any already issued document has no ongoing dependence on Block.co. These records are anchored on the blockchain that recipients own them for a lifetime.
Yes. Block.co allows you to upload and display all sorts of custom data on your document designs. In this case, you can use your unique number as a custom attribute on the document.
Yes, Block.co is a European company based in Nicosia, Cyprus.
For forgery to be proved, valuable resources and time need to be allocated. Block.co’s solution helps you prevent forgery with blockchain technology, providing a fast and easy validation mechanism without the need for intermediaries.
Any institution, may it be a public one, a local authority, or any private corporation that issues documents for which they wish to have an enhanced level of security and immutability.
We insert the metadata transaction ID and the Merkle proof back to the certificate once the transaction is complete.
The University of Nicosia (UNIC) in Cyprus. In 2014, UNIC became the first university globally to offer a Masters’ degree in Digital Currencies, the first university to accept bitcoin for tuition fees, and the first globally to develop a solution to issue academic certificates on the Blockchain, out of which the company Block.co was spined off.
You can see examples of our validators as follows:
University of Nicosia: https://www.unic.ac.cy/verify/
University of Finance and Economics Mongolia: https://www.ufe.edu.mn/English/Default.aspx?page=9067
Ayia Napa Municipality: https://www.ayianapa.org.cy/validator.php
Please note that the list is not exhaustive as our technology is Open Source Code.
Copy and paste the transaction id on any public bitcoin/litecoin block explorer to see all the details.
It has proved over the years to be the most secure blockchain.
Proof-of-Work public blockchain security is measured by the processing power (aka hashrate, because it calculates cryptographic hashes) that the network spends on security. Bad actors need to get a majority of the hash rate to attack the network and even so they are limited to what they can do. Bitcoin is the most secure because it has the highest hash rate, so much so that even global companies and state actors cannot really be incentivized to amass that much processing power.
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://staging-blockco.temp312.kinsta.cloud/design-principles-future-directions/
We managed to create a solution that covers our requirements without needing complex smart contract functionality, which is prone to more attack vectors.
Yes. Our solution just requires storing some data on a public blockchain and thus it is blockchain agnostic.
Being able to make attacks requires significant processing power, or hashrate. Hashrate depends on the specific hashing algorithm used by the network. As long as the network has the highest hashrate for the specific algorithm it is very secure. Bitcoin is the network with the highest hashrate on the SHA-256 algorithm. Litecoin is the network with the highest hashrate on the Scrypt algorithm.
Yes, since our solution is blockchain agnostic. All is needed is to be able to store a small amount of data on that blockchain. However, using a private blockchain limits the solution significantly given that it will only be auditable and transparent for the members of the private blockchain. However, that can also have its uses.
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 through decentralization. Please see article on our design principles.
A hash function takes an arbitrary size of binary data and produces a fixed size random sequence of bytes, call a hash (or hash value or digital fingerprint or digest). This is a one-way process and there is no way to get back to the data from the hash value. Even the smallest modification to the original data would produce a completely different hash value which is impossible to relate with any other hash value.
In public key or asymmetric cryptography, a key-pair is two keys that are mathematically related. One is called public key and the other private (or secret) key. The mathematical relation ensures that what one key can do the other key can undo. Only the public key can be shared with others. In practice, this allows two participants to exchange encrypted messages or authenticate messages via digital signatures.
The owner of a private key can sign a message and send both the message and the signature to the recipient. The recipient can use the corresponding public key to ensure that the message was not tampered with.
For efficiency reasons we typically sign the cryptographic hash of a digital file. The hash uniquely represents the file and is faster to sign.
PKI uses public key cryptography to allow for secure message exchange between participants online. More importantly it allows for uniquely identifying users/entities online, i.e., what is the public key of John Smith. John Smith will be validated the same way he would be validated in real life (ID, passport) and a digital certificate that contains John’s public key will be created and disseminated as needed. PKI, effectively tries to solve identity and secure distribution of public keys. Certificate Authorities (CAs) are the entities responsible for creating the digital certificates and are federated for scalability.
Web of Trust tries to solve the same problem as PKI in a decentralized way, i.e., without the Certificate Authorities (CA). To achieve that, it allows users to vouch for other users, e.g. John says that Mary is who she says she is, and that her public key is X. If several people, maybe known in real life, claim that a public key corresponds to Mary then others will be more inclined to trust it. Since there are several such trust connections between the participants, it is called a web of trust.
Do PDF signatures use public key infrastructure or web of trust? (note that PDFs support both e-signatures and digital signatures… we care for the latter)
It uses PKI.
It uses neither (arguably, it uses a Decentralized form of PKI).
Verifiable PDFs (or vPDFs) is the open-source technology that Block.co leverages. VPDFs allow anyone to ensure that a PDF’s integrity is secured by anchoring a hash of that PDF on a public blockchain. Since public blockchains are decentralized and immutable the hash will be tamperproof. Thus, it can be trusted that it was never modified, which allows anyone with the PDF to validate the document by consulting directly with the blockchain (and not necessarily the entity that created the PDF). In addition, we make sure that the identity of the person that created and anchored the PDF document can be validated in a decentralized way by consulting several public online resources that the entity controls.
In what way is it and how does it differentiate with the traditional solutions like PKI? I.e. Why would someone use our vPDFs instead of the traditional PKI signature scheme that PDFs support natively?
PKI signature scheme with CAs issuing digital certificates has been in operation for many years. It works, albeit not without issues. There have been several occasions that CAs have been hacked (and in some cases it was even an inside job) so that certificates, and thus all security depending on them, were compromised. I.e. CAs are a central point of failure. vPDFs provide a practical way to ensure that several public online sources are consulted to ensure identification of an entity’s public key thus improving on the centralized nature of CAs. The actual data and signatures are also immutable and tamperproof further improving on trustworthiness.
In addition, the PDF signature mechanism makes use of a feature called Incremental Updates to add signatures which was proved to be prone to several attacks, effectively bypassing the signature. VPDFs use the simpler and more practical solution of hashing the entire document, therefore eliminating this type of attacks.
A bitcoin address is constructed by the public key of a key-pair. It can be thought of as an account in Bitcoin where you can receive funds and send funds from.
From the client’s Bitcoin address which can be seen during validation. All different identity mechanisms used to ensure the client’s identity are also displayed, to a user validating a vPDF document.
How does a validator verify the identity of a client? We currently use two methods. Which ones? Are they decentralized?
We currently make use of three methods although more can be easily added according to the clients’ requirements. First, a domain name verification is used where our client proves ownership of a domain name that they are using. Second, Block.co provides a verification service that can also be used. And finally, a GitHub verification method can be used where the client uses their GitHub account to prove ownership of their identity.
Although, each one of the identity verification methods above are centralized, when used in conjunction ensure that there is no centralized point of failure.
When we say issuing/anchoring to the blockchain what do we mean, i.e. what are we issuing/anchoring/storing to the blockchain?
We are issuing/anchoring/storing the cryptographic hash of the digital document. This is an over-simplification that we use for the purpose of this Q&A. In reality more data are stored based on a meta-protocol that has been constructed to allow for additional functionality like timestamping, batching, etc.
How does Block.co ensures that a PDF file is not tampered with? I.e. what does a vPDF contain that a PDF does not?
A vPDF contains a blockchain proof in the metadata (the non-visible, machine-readable part of the PDF). The proof can be used to validate the document.
Our vPDFs are self-contained as they include the blockchain proof within the document itself. They are self-verifiable because you do not need any software download to verify its authenticity, just drag’n’drop on an open-source validator that anyone can host.
We add the PDF metadata in a deterministic way which allows us to remove them without influencing the integrity of the remaining document.
We add additional transactions that can invalidate previous transactions according to the meta-protocol that we have designed and implemented.
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.
We provide access to our API so anyone interested can build an integration with their internal or external system of choice. You can find the API documentation here: https://api.block.co