Blockcerts longevity and availability


#1

The Blockcerts approach allows recipients to own and reveal their own credentials. Further, it allows anyone to independently verify certificate contents, without relying on a trusted party. There are a few near-term problems affecting longevity and availability, for which there are plans to address.

A Blockchain Certificate contains its own proof. Because the blockchain is a permanent, distributed, immutable store, one can always prove the certificate contents are not tampered with, but establishing authenticity and non-revocation currently relies on issuer-hosted information.

This includes:

  • Issuer identification: hosting of public keys (missing breaks verification)
  • Recipient revocation (missing breaks verification)
  • Certificates themselves (inconvenience or data loss if recipient doesn’t have backup)
  • Recipients have their own copy, but it’s easier for recipients to provide a URL for others

Full details of issuer hosting requirements are here

The dependency on issuer hosting is problematic because it can interfere with the availability or longevity of a recipient’s credentials. Problems can range from temporary (such web site issues) to permanent (such as the issuer going out of business).

Longevity/Availability

The reliance of URIs is a choice of expedience that we will ultimately remove, which help address the problems of longevity and availability.

Quick note on Revocation The proposed V2 revocation technique of an issuer-hosted revocation list URI continues reliance on issuer-hosted data. But even before V2, revocation had a dependency on issuer-hosted data, as the issuer revocation key which was used to spend the output had to be checked with the issuer.

Options for Permanence

Archiving/redirect services

One (inadvisable) way to extend the lifetime of a certificate if the issuer went out of business is use of an archival registry, e.g content formerly available at URI x is now available at y. Because this involves maintenance, and trust in the maintainer, this is not ideal long term. But it could be used as a stopgap measure.

Permanent, Decentralized File Store

The fundamental problems discussed above would be solved by moving content currently hosted by the issuer to a file store that is permanent, available, and distributed, such as IPFS (InterPlanetary File System). More precisely, the naming service based on IPFS – IPNS – would be required to allow the issuer to update data while remaining available at a fixed address.

This could also be used as a permanent store for the certificate itself, so that the recipient can easily share the address of the certificate, even if the issuer goes away. The content-addressable hash itself proves that the certificate has not been tampered with.

Note that, if a permanent file store such as IPFS is used, there would be a strong assumption that it’s the issuer’s responsibility to keep the data current. So, if the issuer goes out of business, whatever the current revocation list in IPFS/IPNS reflects is interpreted as correct.


Issuer hosting requirements