-
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 problems affecting longevity of this statement, 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 identity; 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
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.
First it’s helpful to understand context around the revocation changes in V2, as it covers future-proofing the Blockcerts standard in other dimensions, e.g. across Blockchains.
Before V2, revocation was implicitly (not specified in the schema) defined as spending certain outputs. Note that 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.
As of V2, the revocation technique will be explicitly stated in the certificate itself. The default implementation (of spending the outputs) will be replaced with the OBI standard of an issuer-hosted URI with revoked certificates.
There were many practical reasons for the change of the default implementation, but making the revocation technique explicit is done to future-proof the standard. This will allow the standard to expand to add new revocation techniques. This facilities cross-blockchain implementations, allowing, for example, implementation of revocation as a smart contract in Ethereum.
But note that, even with a smart contract implementating revocation, we still have no permanence guarantees.
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.