-
Notifications
You must be signed in to change notification settings - Fork 72
Blockcerts Longevity and Availability
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).
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 (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.
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.