Skip to content


Samuel Hawksby-Robinson edited this page Apr 6, 2018 · 11 revisions

Samuel Hawksby-Robinson -


Verification is a key element for establishing the proofs of user's claims. Invariably with user claims about certifications and memberships these claims can be verified by a single source referred to as the institution. In an analogue context institutions issue certifications and/or memberships, referred to as issues, to individuals in the form of paper certificates. These certificates stand as proof, somewhat, that the individual holds a certification and/or membership with the institution. However the incentive for degree fraud and faking membership means that direct verification with the issuing institution is required before an individual's claims are believed.

Verification of claims can be a time consuming and costly process for the institution and the entity seeking verification, referred to as a verifier. In this section we discuss a number of solutions for verifying issue claims of individuals using the Ethereum blockchain. These solutions aim to reduce the time and cost of verification, required by both institutions and verifiers, to negligible levels.

Table of Terms

term description
Institution(s) The organisation responsible for presenting an issue
Issue(s) A certification and/or membership issued by an institution
Verifier(s) An entity seeking to prove the claims of an individual about their issue(s)
Claimer(s) An individual claiming to hold an issue from an institution
Holder(s) An individual which has an issue assigned to them by an institution


Verification Components

TiiQu verification will typically consist of the following components:

  • The holder
  • The issue
  • The institution
  • Optional issue meta data

Blockchain certificates

The issue will be represented on the blockchain by a readable issue contract that can be thought of as a "blockchain certificate", a document that details an attainment that many holders can achieve. The distinction from a traditional certificate is that the blockchain certificate contains no identifying data about the holders, and only details the specifics of the attainment.

In some cases it may be necessary to associate meta data with the issue to give further details about the attainment. For example if the issue was a degree, the additional meta data may include the level of the degree (1st, 2:1, 2:2, etc), or the associated modules that the holder chose for their degree. If the issue was a membership the meta data may include an entrance score or the membership rank the holder has.

The public readable data can be used to populate a UI presentation of the blockchain certification, allowing non-technical individuals to quickly view the holders' attainments.

Establishing a relationship

The relationship between the components is established by matching, the holder's address, the address of a readable issue contract, issue meta data contract and contact data published from the institution's address in a blockchain data row. The methods for establishing a match between each of this components is detailed in the subsequent sections of this paper.

Verifying Future Issues

The process for verifying future issues is quite different for the verification of issues made in the past. The distinction is made simply because you can plan for future issues and create a system that anticipates the use of blockchain verification. For issues that were made decades ago no such planning is possible. Therefore verifying future issues assumes certain data is available that would not be available for issues made without prior expectation of using the blockchain.

In this section there will be references to non-blockchain holders and blockchain holders, the distinction is a non-blockchain holder does not have any knowledge the blockchain and/or does not use the Ethereum blockchain. A blockchain holder is an individual that has knowledge of the blockchain and uses the Ethereum blockchain and has an Ethereum address they are willing to associate with their issues.

Issuing for non-blockchain holders

The process flow for verifying future issues is as follows:

  • An institution becomes a TiiQu partner and/or makes available their blockchain verification API
  • At each issuance event (eg. a university presenting a degree to a class of students) the institution publishes to the blockchain a data hashes for each holder that represent:
    • The holder's details
    • The issue's unique details
    • The reference to the blockchain "certificate"
  • Additionally to the data stored above the following fields will be left available for completion by a successful issue claim:
    • Hash proof of knowledge of the holder's details
    • Hash proof of knowledge of the issue's unique details
    • The Ethereum address that was able to supply the above details.
  • At some future date the holder will become a TiiQu member and will seek verification of their issues
  • The holder will submit their personal information
  • The holder will submit information about their issues
  • The TiiQu platform will inspect the blockchain for an entry that matches the data hashes of the holder
  • When a match is found the user will instigate a claim transaction, by sending the hash proofs of their personal details and the unique details of their issue.
  • The smart contract controlling verification will perform a hash check on the incoming data, and on success will assign the sender's address to the issue along with the incoming data.
  • The holder's claim has now been verified.

You will notice that the university incurred no cost except for the initial submission of data to the blockchain, and required no ongoing administration costs. The holder did not need to contact the institution and very little time was used in verifying the data. Furthermore once the issue has been verified it does not need to be verified in the future, this means that for any future verifiers they only need to refer to the data proofs in the smart contract, or their UI representations.

This approach also allows for institutions to have complete control over their data without the need to share data that may be sensitive. In addition only the institution has access to their data, with no need for any outside agent such as TiiQu to have access to the data that the institution holds.

For an interactive proof of concept please see the TiiQu Verifier

Why only store the data hashes of unique details?

Why don't we store the personal/issue details of the holder and only store the data hashes derived from the details? This element of the verification of issues has been deliberately designed with data protection and the right to be forgotten in mind. Since any data published to the blockchain is forever public we need a method of providing proof that the claimer is the holder of a particular issue without revealing the any of the details.

The hashes are stored on the blockchain but the data that they represent are not. This allows for a claimer to have their claim verified without having to reveal their personal details in a way which would be exposed directly to the blockchain. In the same vein all association with the person is abstracted to such a degree that the at some future time the individual can choose to disconnect their personal association with their issues if they want. Thus giving them the option "to be forgotten".

Why store the hash proofs of knowledge?

The hash proofs are stored to allow third parties to see that proof was provided by the claimer and to allow the third party to perform the hash algorithm on the proof to determine that it matches what was originally published by the institution. This allows the third part to prove that the claimers/holders have the same data that the institution had at the point of the issuance event, data only available to the holder and the institution.

Issuing for blockchain holders

The process flow for issuing to blockchain holders is significantly more straightforward as the institution has direct knowledge of the holder and their Ethereum address. This means that the holder can supply the institution with their Ethereum address and the institution can publish this at the holder's issuance event along with the certification reference. There is no need to publish the data hashes or data hash proofs as matching is done directly by the institution. Because the holder's address and issue reference is published in the same transaction by the institution's key we know that the it was the institution that made the match.

Verifying Past Issues

Verifying past issues can take two forms, one involving a method almost identical to issuing for non-blockchain holders, and another method requiring a manual response from the institution.

Publish past issues

This method may not be available in a lot of cases, particularly where the institution may have destroyed records. This method presumes that the institution has kept all the data required to issue for non-blockchain holders. The process flow is as follows:

Manual Response

In the case where the institution is unable or unwilling to publish the required data to the blockchain the following process could be used to allow the institution to verify a holder's claim.

  • A relationship is established between TiiQu and an institution
  • Claimer joins the TiiQu platform and submits personal and issue details
  • The TiiQu platform publishes the data hashes to a contract dedicated to an institution that requires manual response.
  • The TiiQu platform creates an issue on the blockchain and a reference to it in the above contract
  • The TiiQu platform sends an email to the institution containing a link to a secure browser page, created by TiiQu, containing the claim of the claimer and their personal details.
  • The institution representative reviews the details and presses the confirm or reject button.
  • An oracle will watch for the confirmation and will update the blockchain record to reflect the manual response from the institution.


This method is the least desirable of the presented methods because it involves a manual response from the institution and introduces another avenue for human error to affect the verification process. Although all the data is stored on the blockchain, the response will rely on an interface less security and reliable than the private key signing of transactions directly broadcast to the Ethereum mainnet. The weak points of the above methods assume that the institution has no direct interface with the blockchain, and are as follows:

  • The email sent requesting a response although containing no identifying data could be intercepted, tampered with, blocked and/or never read.
  • The secure browser page will require the institution's representative to enter a username and password, which could be compromised by key logging or social engineering. Granted a private key has the potential to be compromised without adequate security measures, it is far harder to do so if the private key is stored and signed with a dedicated device such as a hardware wallet.
You can’t perform that action at this time.