Formalize schema elements and allow them to vary
The biggest weakness of the previous schema/standard versions was that too many of the critical aspects were implied (such as verification steps), which makes it harder to adapt the standard across different blockchains, and different domains. In general, formalizing AND generalizing allows us to future-proof the standard.
Most significantly, this affects the Blockcerts schema and standards for:
- Verification and Signing
- Revocation
Verification and Signing
Verification and signature should be explicit and allowed to vary, to support (at least) differing choices of:
- proof types, e.g. Proof of Publication, Chainpoint
- crypto key types
- blockchain
- domain-specific concerns
Blockcerts does not contain reference implementations for any of the variations described above. The goal is to help make the Blockcerts standard more portable across domains, blockchains, etc, in response to community requests.
Eventually, it may be possible to rely on IPFS/IPNS for storage of certain certificate elements, but that's premature for this phase. Instead, Blockcerts can made future-proof to allow.
Blockcerts is also being updated to ensure that at issuing, viewing, and verifying time, all properties have been mapped at property in the JSON-LD context. Verification should warn (at least) or fail if there are additional properties due to dropping of unmapped properties during JSON-LD canonicalization. Also, there will be following up with JSON-LD standards team to discuss for the benefit of the community.
Details: Github Issue #25
Revocation
Make revocation technique explicit
The help future-proof the standard, revocation should be explicit and allowed to vary. Possible implementations include a revocationList URI, smart contract, IPFS/IPNS. This facilities cross-blockchain implementations, allowing, for example, implementation of revocation as a smart contract in Ethereum.
This will not provide a reference implementation of alternate revocation techniques (smart contract, IPNS).
Change the default implementation
Before V2, revocation was implicitly (not specified in the schema) defined as spending certain outputs. As of V2, the revocation technique 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, described in the links below.
This has additional benefits:
- Fixed cost, independent of batch size
- Addresses UTXO bloat concerns
- Frees up recipient address to be any cryptographic public key
- More easily portable to other blockchains
Details: Github Issue #24
OBI V2 Alignment
When the blockcerts standard was originally developed, OBI v1.1 was the current Open Badges standard. A key blockcerts requirement was embedding much of the certificate content in the certificate (as opposed to URLs), so that the cryptographic hash of the content could be verified.
Blockcerts v1.1 and v1.2 standards were created with guidance from the Open Badges team, who simultaneously were developing the OBI v2 standard. OBI v2 was developed with use cases like blockcerts in mind, and includes standards that would benefit the blockcerts schema.
See details in Github Issue #28.