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.
- 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.
Options for Permanence
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.