# Blockcerts longevity and availability

**URL:** <https://community.blockcerts.org/t/blockcerts-longevity-and-availability/19>\
**Category:** Community\
**Created:** [March 22, 2017, 6:28pm UTC](https://community.blockcerts.org/t/blockcerts-longevity-and-availability/19 "2017-03-22T18:28:54Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![kim](https://sea2.discourse-cdn.com/flex016/user_avatar/community.blockcerts.org/kim/32/307_2.png) [@kim](https://community.blockcerts.org/u/kim)\
**Post date:** [March 22, 2017, 6:28pm UTC](https://community.blockcerts.org/t/blockcerts-longevity-and-availability/19/1 "2017-03-22T18:28:54Z")

</div>

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](http://www.blockcerts.org/guide/issuer-hosting.html)

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.