Open Badges makes it possible for anyone to issue a badge. The badge data or the public keys are hosted on the issuer’s web server. The metadata of badges contains links to where they are hosted. But what happens if the issuer goes away? or the web server goes down? Whether you are new to badges or have been issuing badges for some time, it’s an important consideration. As Open Badges works now, the long-term verifiability & validity of the badges is the obligation of the issuer or issuing platform.
So what are the options? How can issuers ensure that their earners will keep their badges for as long as they need them? Here are some options to consider now:
- Hosting badge criteria, evidence, and badge metadata on a smaller, cheaper server – There are plenty of free and inexpensive web hosts out there. When first planning your issuing site, consider your short-term and long-term costs. It doesn’t take much room or space to host badges.
- Coordinating with other Issuers – One thing to consider is collaborating with other issuers on hosting; a server where you share the costs and maintenance of web server. Or you could make an arrangement (with agreement of earners) to transfer badge data to another issuer’s service (while keeping issuing dates intact) and doing permanent redirects or providing earners with the new urls for their badges.
- W3C Permanent Identifiers – This service is run by the W3C Permanent Identifier Group. It maintains an HTTPS-only, permanent redirection service hosted at w3id.org operating much like a switchboard that can reconfigure entries to point to a new location if the old location stops working. V 1.1 of the Open Badges spec hosts the context file here: https://openbadgespec.org/v1/context.json
- PURL(Persistent Uniform Resource Locator) – This toolkit is provided by the OCLC and Zepheira. It can be used to create permanent identifiers that point to resources. It’s been around for a long time and seems to work similarly as W3C Permanent identifiers without the SSL support.
- Amber — The Berkman Center for Internet & Society created this tool to keep content accessible. It automatically saves a snapshot of every page linked to on a website. Initial development has been focused on WordPress and Drupal but they have also started Apache and Nginx modules which may be more relevant for issuers.
With Achievery we went with the first option and slimmed down the platform from badge issuing to just badge hosting on an inexpensive server. Primarily we did this because it was the fastest and easiest at the time and also because we wanted badges to maintain their urls. That said, this also give us the flexibility to pursue other options in the future some of which I’ve been digging into as part of my work with OpenWorks Group and BadgeChain.
I’ve been researching how Open Badges can work on the blockchain and part of that initial research has been investigating the Distributed Web (this post at The Internet Archive does a good job of explaining it). I’ll write more about this soon but for now, here’s a list of projects to look into that I think will play a role in the future of Open Badges:
Other distributed system projects that I’ve come across but haven’t dug into yet:
It’s my opinion that the near future of Badges is a combination of Blockchain (serving as the ledger) and distributed systems. With these systems we can ensure that badges have a permanence and reliability that web hosting can’t provide. Team BadgeChain will continue our focus here. You can stay-up-to-date on our Medium Publication.