Members of the MIT Media Lab have related in a Medium post what they have learned from designing a system for issuing academic certificates using bitcoin blockchain technology.
The team released version 1 of its code under its open source license to allow others to experiment with similar ideas. The lab wants to share its ideas behind the design.
The team members who authored the blog include Juliana Nazare, a graduate student in the Program in Media Arts and Sciences at the lab, Kim Hamilton Duffy, a principal engineer at Learning Machine, and J. Philipp Schmidt, director of learning innovation at the lab.
A Sharing Approach
The team learned a lot about the way technology can shape socioeconomic practices around the concept of credentials. By sharing its experiences, the team thinks it will help institutions and other developers make use of blockchain architectures.
The team noted that the most interesting challenges were not technical in nature, but they could not separate the challenges from the technology since small design decisions can impact behavior. Hence, the team took small steps, tested the system with users, and made changes based on what it learned. The team noted the blockchain is still a new technology and the long-term effects of design decisions have to be carefully considered.
The certification architecture’s design is fairly simple. An issuer signs a digital certificate and stores it hash in a blockchain transaction. The recipient receives a transaction output.
Version 1: Starting Point
Version 1 is considered a starting point for other researchers. Institutions seeking to introduce digital credential systems are encouraged to wait for version 2. The MIT team has begun a redesign and will release future versions under the same license.
There are three repositories in the digital certificate architecture.
Cert-schema refers to the digital certificate data standard. Such a certificate is a JSON file with the required fields for the cert-issuer code to put on the blockchain. The team attempted to keep the schema close to the open badges specification as much as possible. They expect the next specification version to be even more closely aligned.
Cert-issuer takes a JSON certificate and creates a hash, which is a short string used to uniquely identify a larger file of the certificate. The issuer issues a certificate by broadcasting a bitcoin transaction from the issuer’s address to a recipient’s address with the hash embedded in the OP_RETURN field.
Cert-viewer displays and verifies digital certificates after issuance. The viewer code gives the ability to users to request certificates and create a new bitcoin identity.
Current Shortcomings
The team’s interest in designing new solutions is motivated by limitations in current approaches. Certification systems, when not working well, are not only inefficient due to an expensive and cumbersome process of requesting a university transcript. They can also be disastrous, like when a refugee cannot provide a certificate of completed study and therefore cannot continue their education. Digital systems can address such situations.
In the year the team has worked on the project, blockchain-based certification systems have gained a lot of attention.
A key takeaway for the team has been that the blockchain is more complex than most people realize. Developing applications on top of it is getting easier, but there are few who deeply comprehend its inner workings. It is not a simple solution that can fix everything wrong with credentials. This is what the team is excited to explore.
Why Not Ethereum?
When the project began, Ethereum was barely an idea, which explains why the team did not use it. In addition, bitcoin has been the most reliable and tested blockchain to date. And the robust self-interest of miners, along with investments in bitcoin, make it likely it will continue for a long time.
The team’s solution is not tied to a particular blockchain. The credentials can be published to other blockchains.
For most of what MIT is doing, the bitcoin blockchain continues to be efficient. The team is discussing the potential for Ethereum-based side chains to cut transaction cost and grow functionality.
The system uses public/private key pairs to authenticate both issuer and recipient. Certificate recipients, like workshop participants or graduates, could ideally create their own key pairs and share the public key to request a certificate.
However, the scope of technical sophistication needed to accomplish this makes a widespread roll-out prohibitive.
At present, being able to share a simple link to a certificate is convenient. In the future, the team will want better ways for non-technical users to develop and manage their own keys.
Wallet Solution Ideal
The ideal solution would be a wallet for academic credentials that functions like bitcoin wallets. An alternative would be a paper-based system of sharing and pre-creating keys, then destroying them. This option requires a lot of trust in the issuing entity.
The team wanted to maintain the chance to revoke a certificate, in part because people are concerned about it, and because they worried they would miss a fundamental flaw in the design and have to invalidate initial attempts.
Revoking version 1 is not a deletion since no information can be deleted from the blockchain. However, it is a flag that the issuer or the recipient can set to signal they don’t recognize the certificate as valid. The team creates two outputs containing 1 cent, with one output assigned to the issuer and the other to the recipient.
To revoke a certificate, one of the parties spends the output they control. In such a sense, it works like a convention that all users must agree on.
The viewer code follows the convention and checks to see if the revocation flag is set. Other viewers might choose to ignore it. This is a design choice the team is considering. For version 2, the team is exploring other revocation approaches that might cut the ability for viewers to validate or show revoked certificates.
One direction is “versioning,” following a chain of spends to the certificate’s most current version, which seems tedious. A revocation list, however, is a common pattern with other certificate issuers like X.509 certificates and open badges.
Certificates can only be useful when tied to a person. Hence, protecting private data is critical.
Certificates Must Be Useful
Learners have to be able to show evidence they received a certain certificate. They should also be able to disclose the information to an employer without needing to share it with every other employer.
Some MIT colleagues are working on solutions to provide more sophisticated ways to manage private data. Such initiatives are in early development.
The current solution attempts to balance obfuscation – making it difficult for unauthorized users to find the information they should not have access to – with usability so learners or institutions lacking advanced technical sophistication will not be prevented from using the credentials. This is accomplished by hashing the certificate – which has a learner’s personal data – and placing the hash on the blockchain.
Should someone seek to verify the certificate, the learner has to disclose where the hash is located on the blockchain as well as the certificate itself.
How Much Control Should Learners Have?
Should learners choose the aspects of their history to share with others? They can construct different narratives for different purposes with traditional certificates. Someone interested in writing and food can highlight certain experiences when seeking a particular job while highlighting another set of qualifications for another job.
Some employers might seek stronger transparency requirements. In most cases, however, there is no reason to require the learner to share all accomplishments in the same way. Minus better safeguards to protect sharing of such information, the risks of requiring disclosure outweigh the benefits.
Some individuals choose to broadcast their academic history while others do so only as needed. The MIT team wants to provide them similar flexibility in using digital credentials. It is possible for an employer to search the blockchain for other certificates the learner has, but the certificates’ content will be encrypted.
Design Has Shortcomings
The design has shortcomings. Should an issuer issue one type of certificate, it is possible to find all transactions the issuer made on the blockchain and determine who else might have received them. This is why the team is working on a technical change in version 2 – to make traceability more difficult.
The team sees a lot of potential in tracking the use of credentials to document value to the individual, but it does not yet have a clear design proposal. If there were a public record of degrees employers pay attention to, it would help students decide what programs to enroll in.
There are two solutions to extend the architecture, “transactional disclosure” and “disclosure by proxy.”
Transactional disclosure deploys the certificate disclosing process as a transaction that is publicly recorded and generates data others can use. Disclosure by proxy relies on users verifying certificates via a third party that records the disclosures. The team is thinking about these options for version 2.
Version 2 On The Way
The team is focusing on deployment and documentation in version 2 to make it easier for other institutions to begin. The key technical change is the way the certificate data is stored.
In version 1, every certificate corresponds to a bitcoin blockchain transaction. In version 2, the team will store certificate data in a Merkle tree, which is a cryptographic construct allowing more efficient storage while preserving users’ ability to point to their certificates without having access to other certificates. The bitcoin blockchain will still record the Merkle root to maintain the benefits of using a blockchain.
Merkle trees are more likely to be maintained by issuing entities than by recipients, but a wallet-based approach to managing credentials will still provide recipients full control over credentials.
The project home will be at http://certificates.media.mit.edu. There will be links to the source code, example implementations and documentation.
Those experimenting in the space should consider joining the Github repository for the issuer functionality, cert-issuer. This is where the team plans to move most of the version 2 technical discussion. For bugs, project specific features requests and other issues, the team recommends opening a Github issue against the project or sending a pull request.
Featured image of MIT Lab from Flickr/ Knight Foundation.
No comments:
Post a Comment