These are great questions, and this decision was one of the biggest sticking points. This is a good example of discussion that until now has been buried in github issues, so I'm glad you asked here.
Ultimately: CRL is not the Blockcerts revocation technique. This was an intermediate step to move forward with V2 OBI compliance while allowing the Blockcerts standard to make fewer assumptions about implementations (such as choice of blockchain). In OBI, revocation is implemented as a CRL, and this is the option you see here.
The problem with reliance on spent outputs for revocation is:
- assumes UTXO model (a complication for alternative blockchain models)
- revocation address key rotation infeasible (described here)
- cost is proportionate to number of certificates, making this infeasible for very large batches (for more economical issuers)
- cost of revocation for recipient depends on transaction fees (which have raised dramatically recently) -- one option is to pad the recipient outputs to cover this, but this increases the cost even more.
In the past, we've considered multisig approaches and others that involve the recipient participating in the transaction, but so far they've been infeasible from a usability and (recipient) cost perspective.
Finding a better revocation solution is a primary focus post-v2 (i.e. now). We want a solution that combines:
- economic for large batches
- blockchain agnostic: in Ethereum, for example, a more natural solution would be smart contract-based, and would have more natural economic model for revocation. (I.e. the v1.2 Blockcerts model plans for the worst case, in which any one of the certificates in the batch may be revoked. Clearly at some point it makes sense to revoke the whole batch).
- recipient-centric: the recipient must be able to curate and control the credentials presented. It is not clear yet at which layer this must occur; for example, we are also actively investigating Verifiable Claims/Decentralized ID approaches
On a related note, another problem we are investigating is reducing reliance on issuer-hosted data, and improving longevity and availability. In all versions of Blockcerts, the hosted issuer identification is required for verification. We want to find a way to avoid all such points of failure, and are pursuing a range of solutions, including IPFS/IPNS.
This is very much under investigation now, and any suggestions and collaborations are encouraged.