Skip to content

Instantly share code, notes, and snippets.

@kimdhamilton

kimdhamilton/reddit_response.md

Last active May 29, 2020 02:25
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save kimdhamilton/6eddfd9cc9194c9b13b3eb968f691352 to your computer and use it in GitHub Desktop.
Save kimdhamilton/6eddfd9cc9194c9b13b3eb968f691352 to your computer and use it in GitHub Desktop.
Download ZIP
Response to "My Official MIT Degree Verified on the Bitcoin Blockchain"
Raw
reddit_response.md

Hi, one of the Blockcerts creators here. Congratulations on your MBA, and I'm thrilled you're enjoying your Bitcoin blockchain-anchored degree!

There were a few questions below I wanted to provide answers and updates to:

Blockcerts verification: it's correct that only a hash of the degree is anchored to the blockchain. Even further, a Merkle tree of all recipients in a batch is formed, and the Merkle root is anchored. More details here: https://github.com/blockchain-certificates/cert-verifier-js/blob/master/docs/verification-process.md

Proof of control/auth: someone mentioned spending a small amount to "prove" control. In an earlier version of the standard we did add revocation semantics to output addresses. What's interesting is that either issuer or recipient could revoke -- the interpretation of the latter being something along the lines of disavowal.

With Blockcerts, a recipient public key (actually bitcoin address) is embedded in the credential, so if the credential contents are known, a relying party could challenge the recipient to sign with that key (technically, it would be the Bitcoin sign_message)

What's next: The standards around (decentralized) verifiable credentials are continuing to evolve.

  • Standard: The (json) structure of Blockcerts is based on Open Badges, but in the meantime, we realized the value of the Verifiable Credentials standard as a lightweight credential "envelope", supporting a wider range of credential types. That's now a W3C recommended spec. Note that Open Badges will also be migrating to support VCs in a future version

  • Privacy: the migration to VCs supports scenarios where more sensitive data might be included, and works with signature schemes that support zkp techniques, etc. Even in solutions where only a hash is anchored to the blockchain, there still could be concerns about correlation, and rights to erasure. Fortunately we've found that in many cases we can refine what is anchored to a blockchain, and that is largely identifiers (more below)

  • Decentralized Identifiers: you can think of this as crypto keys with lifecycle management (rotation, revocation) built in, but also supporting extensible services, integrations to existing auth mechanisms, etc. This will be used for both issuer and recipient.

If anyone's interested in learning more, we do a lot of this work at the W3C Credentials Community Group. Also, MIT is working with other universities around the world to push this work forward, through the Digital Credentials Consortium.

Congrats again on your accomplishment!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment