As a reminder, our platform allows for institutions to issue any kind of credential and produces self-verifiable PDFs that can be viewed as usual but now also trivially verified by using an open-source validator. A fingerprint of the credentials is anchored (stored) on Bitcoin’s blockchain and the validators need only consult the issuance metadata embedded in the PDF and Bitcoin’s blockchain to verify; nothing else.
The way Bitcoin’s blockchain works guarantees that what is stored in the blockchain is immutable; can never be modified or deleted. However, there are cases where we need to revoke credentials; from correcting simple typos on a name to revoking because an awardee provided false information, etc. Since immutability is a default attribute one needs a non-systemic approach to deal with revocation, which usually implies additional infrastructure to accomplish it.
In a previous article, we described the design principles that we endorsed when creating our credential fraud-proof platform. To summarize, they were issuer independence (decentralization), unforgeability, simplicity, and openness and were effectively and efficiently implemented using blockchain technology. Adding a revocation mechanism should also follow those principles.
Different Revocation Mechanisms
Let us examine some ways that revocation can be accomplished. Some of those are used on actual platforms and some are theoretical. We will conclude with the revocation mechanism that we designed that adheres best to the above-mentioned principles. This article is going to try to capture the rationale (and trade-offs) and not actually delve into technical details. For technical details, please refer to this publication.
This is straight-forward. The credential itself has a URL embedded that points to the issuer’s website. An internal database is consulted regarding the validity of the credential (if it was revoked or not). This introduces a central point of failure, i.e. dependency on the issuer, which is against our principles.
Re-issuing all credentials
This approach re-issues all credentials when a new batch is created invalidating the old one. The new batch will contain all the corrections with regard to the revoked credentials. There are several disadvantages with this approach, like rendering the transaction timestamp meaningless but more importantly, it simply does not scale as an issuer will end up issuing hundreds of thousands or even millions of credentials at the end!
Extra addresses per issuance
It is possible (and was actually implemented by another platform) to send a small amount of funds to additional addresses, each representing a different certificate. To revoke you need to just spend those funds; the validator will check if the specific address has funds, and if not it will consider the credential to be revoked. As above, there are several issues with this approach the two most important being:
Issuance is more expensive and does not scale; each extra address adds to the transaction fee and the maximum transaction size limits the maximum number of credentials per batch.
Complex infrastructure to keep track of which address corresponds to each credential.
Complexity and lack of scalability make it an unattractive approach.
Revocation with issuer-hosted Certificate Revocation List
Several systems use this approach where there is a fixed URL that contains the fingerprints of the credentials that have been revoked. When the issuer needs to revoke they just add an entry to that list. This is similar to the centralized solution previously mentioned.
Additional decentralization layer
Another approach is to make use of another blockchain like Ethereum and create a smart contract for the revocation of credentials. This approach could be promising with regard to the features you can support. However, it introduces unwarranted complexity both design-wise and implementation-wise.
Similarly, and for completeness, one other approach would be to design a specialized blockchain platform to deal with credentials; their issuance, dissemination, validation, revocation, etc. Private initiatives have been announced already but there are no real results yet. From our perspective, a private blockchain platform fails to satisfy most of our design principles.
This is the approach we designed and applied to our platform. When issuing a very small amount of additional information is passed into the transaction that anchors the credentials into the blockchain. The information encodes a meta-protocol which allows for operations specific for credentials and will refer to previous transactions as appropriate. The validator rules will be such that other transactions could be consulted before the final resolution for credential validity. Revocation is accomplished by creating an additional transaction, chained with the original issuing and revoking previous credentials on-chain.
This will allow to implement revocation as well as additional functionality. Some of the encoded operations are: issuing credentials, revoking a credential batch or specific credentials, and even revoke issuing addresses. This approach has all the required attributes, i.e. it is a simple and intuitive decentralized solution that is open and has no other dependency than a single blockchain.
The meta-protocol revocation mechanism (that we call the CRED meta-protocol) has been used in production from 2017 and it has proved to be a simple and elegant solution. It supports flexibility on how and what you can revoke and is easily extensible for other operations.
It is worth mentioning that revocation is really hard on immutable ledgers and most of the solutions are lacking one way or another. A simple, decentralized, on-chain approach was challenging but the results are satisfactory. Also note, that most of the standardization efforts leave the revocation mechanism abstract (to be decided later) exactly because this is a difficult problem to tackle. As the standards evolve we intend to contribute our revocation mechanism as one of the potential revocation mechanisms.