-
Notifications
You must be signed in to change notification settings - Fork 72
Blockcerts Longevity and Availability
The blockcerts approach allows recipients to own and distribute their own credentials. It allows anyone to independently verify the certificate contents, without relying on a trusted party. There are a couple of near-term problems affecting longevity, which we have plans to address.
A Blockchain Certificate contains its own proof. Because the blockchain is a persistent, immutable store, one can always prove the certificate contents are not tampered with, but establishing authenticity and non-revocation 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).
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.
One 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.
The fundamental problems discussed above would be solved by moving content currently hosted by the issuer to a file store that is permanent and available.
IPFS (InterPlanetary File System) would provide a permanent and decentralized method of storing and sharing issuer-hosted data. (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 name.)
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.
Note that, if a permanent file store 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.
Note that a distributed file store also addresses the availability aspects.