BadgeKit Future!

BadgeKit Layout

This is the second post in a two part series on BadgeKit, in the first part, I wrote about BadgeKit Now, looking at how you can set up a version of BadgeKit on your own servers now.

BadgeKit is coming! Like I wrote last time, it’s already here. You can pull a handful of Mozilla Open Badges projects together, host them on your servers and build a complete badge platform for your project. All that’s easy to say, but not easy to do. BadgeKit will streamline launching an open badge system so that just about anybody can issue open badges with an open platform that grows with them.

Sunny and Jess wrote an overview of where we want to get to by March, a MVP Beta release for the Digital Media & Learning conference. The release will give users two ways to work with BadgeKit,

  1. SaaS – define your badge system on the fully hosted site (or your self-hosted site), integrate the system with your existing web applications through our API’s.
  2. Self hosted – the full experience outlined above, but hosted on your own servers.

In both cases, the issuers build a website that interacts with our API’s to offer the badges to their communities.

The project divides easily into two big buckets – first building out the API’s we created in Open Badger, Aestimia and the Backpack, second building a solid administrative toolkit to define badges and assemble them into larger badge systems. Issuers use the toolkit (which will live at to design and launch their badge systems, then they’ll integrate the community facing portions of the system into their own site (which preserves their custom look and feel) with our API’s. Here’s a quick sketch of what it all will look like,

BadgeKit Layout

Lot’s of API’s

More Flexibility

Last week we talked about a few services in the BadgeKit Now post, OpenBadger, Aestimia, Badge Studio, a ‘badging site’ and the backpack. None of those pieces are going away, but they are all going to get a makeover – each is stripped down to the roots and rebuilt with an emphasis on their web API interfaces. We’re going to standardize on MySQL as a datastore, explore Node.js’ streaming API’s for database access and output and rebuild the account authentication model to allow the services to support more than a single ‘badge system’.

Data Model

The current data model uses a three-tier ownership chain to define a single badge – a badge belongs to a program, a program belongs to a issuer, a issuer is part of a badge system by being defined in the instance of Open Badger. There’s a one to one mapping of a ‘badge system’ like Chicago Summer of Learning to an instance of Open Badger. Adding an extra layer, so that a badge belongs to a program, a program belongs to an issuer, an issuer is part of a badge system, which sits beside other badge systems in the single instance of Open Badger will open us up to hosting several large systems per ‘cluster’ of Open Badger servers. We’re breaking the one to many relationship of a badge to a program and a program to an issuer and allow for badges to belong to multiple programs, or programs to multiple issuers, issuers to multiple systems, providing more of a graph-like collection of objects.

Authentication and Authorization

This collection of applications authenticates the identity of each piece in the chain by signing API calls with JSON Web Tokens. The key used in each app is configured as an environment variable, as long as each app knows the key, they can read and write to other applications with the same key. When we build badge systems that are co-hosted, but span multiple applications (Open Badger talking to the badge site, the badge site passing messages to Aestimia) we’ll have to change the way the distribution of keys between the applications. The client site API keys will allow them access to the hosted API’s.

What’s Next?

You can follow the development of all these pieces on Github and read more about the system as it develops on Planet Badges.