Hand Crafted Open Badges Display

Earning an Open Badge is easy, there’s plenty of places that offer them, with more issuers signing up every day. Once you’ve earned an open badge, you can push it to your backpack, but what if you want to include the badge on your blog, or your artisanal hand crafted web page?

You could download the baked open badge and host it on your site. You could tell people it’s a baked badge, but using that information isn’t super easy. Last year, Mike Larsson had a great idea to build a JS library that would discover open badges on a page, and make them dynamic so that a visitor to the page would know what they were, not just a simple graphic, but a full-blown recognition for a skill or achievement.

Since his original prototype, the process of baking a badge has changed, plus Atul Varma built a library to allow baking and unbaking in the browser. This summer, Joe Curlee and I took all these pieces, prototypes and ideas and pulled them together into a single JS library you can include in a page to make the open badges on that page more dynamic.

There’s a demo of the library in action on Curlee’s Github. It shows a baked badge on the page, when you click the unbake button, it takes the baked information from the image and makes the badge dynamic and clickable. We added the button to make it clear what was happening on the page, but in a normal scenario, you’d just let the library do it’s thing and transform the badges on the page automatically. You can grab the source for the library on Github, or download the compiled / minified library directly.

There’s lot’s more we can do with the library, I’ll be writing more about it soon.

The Open Badges Infrastructure

First things first, what do we mean when we say “Open Badges Infrastructure?” Infrastructure is a bit of a loaded term, you can interpret it as servers, you could interpret it as software, or both hardware, software, internet…all the things. We’ll make this easy and say that the Open Badges technical Infrastructure is all the things that make it possible to earn or issue an Open Badge.

“All the things” is an easy answer to the question, “what is the open badges infrastructure?” but it doesn’t help much when we’re trying to push the infrastructure forward, when we’re trying to grow the ecosystem. Given a technical infrastructure need, how does the Badge Alliance, and the Open Badges community, figure out the best way to address the need? If the OBI is “all the things,” who could support it without turning the OBI into a silo’d badge system?

When we asked what role the Badge Alliance would play in the OBI, we knew that the OBI needed a shepherd organization that could help the members of the OB community coordinate their efforts maintaining the long-term health of the OBI. So how do we decide what actions fit into that model? What parts of the OBI are fair game for the BA to directly touch, which parts can we influence, which parts should we stay away from entirely?

We built a three-tier model that represents all the pieces of the OBI,

OB Infrastructure 3 Tiers

The first layer of the tier is the Open Badges standard. If you’re issuing an Open Badge, you’re relying on the standard to make the badge interoperable, transportable and verifiable. It’s the layer that all the other layers of the OBI rely on.

The second layer is libraries and tools that interact with the standard. Badge issuing libraries, validation libraries, badge bakers, tools that you download and install on your machine, or use as a dependency to build a bigger tool, fit in this layer.

Lastly, the top layer is userland. The marketplace. All the hosted services that interact with badge earners, with badge issuers and with badge consumers. It relies on the layers below it, and covers them up. A student earning a badge never knows that layers one and two exist, they just know that they received a badge and are storing it in their backpack.

Given the three layer model of the OBI, the Badge Alliance realized that it’s absolutely vital that we take a very active role in the maintenance of the first layer – the OB Standard, a less active role in the library layer, and a purely advisory role in the top userland layer.

Like all frameworks, it’s possible to find edge cases that break the model, but for most cases, it’s a solid way to judge what actions the BA should take in the maintenance of the OBI. Sunny and I will write more over the next couple of weeks about exactly how the BA will play in the three tiers.

Open Badges and JSON-LD

The BA standard working group has had adding extensions to the OB assertion specification high on its roadmap this summer. We agreed that before we could add an extension to an assertion or Badge Class, we needed to add machine readable schema definitions for the 1.0 standard.

We experimented with JSON-Schema, then JSON-LD. JSON-LD isn’t a schema validator, it’s much more. It builds linked data semantics on the JSON specification. JSON-LD adds several key features to JSON, most of which you can play around with in the JSON-LD node module.

  1. Add semantic data to a JSON structure, link the serialized object to an object type definition.
  2. Extend the object by linking to multiple object type definitions.
  3. A standard way to flatten and compress the data.
  4. Express the object in RDF.
  5. Treat the objects like a weighted graph.

All of which are features that support the concept behind the Open Badges standard very well. At its core, the OB standard is a way for one party (the issuer) to assert facts about another party (the earner). The assertion (the badge) becomes portable and displayable at the discretion of the owner of the badge.

JSON-LD is also quickly becoming the standard method of including semantic markup on html pages for large indexers like Google. Schema.org now lists JSON-LD examples alongside RDFa and Microdata. Google recommends using JSON-LD for inclusion in their rich snippet listings.

We’ve been talking about JSON-LD on the OB standard working group calls for a while now. It’s starting to feel like consensus is forming around inclusion of JSON-LD markup in the standard. This Tuesday, September 2nd 2014, we’ll meet again to collectively build a list of arguments for and against the move. We’ll also discuss a conditional rollout plan (conditional in that it will only be executed if we get the thumbs up from the community) and identify any gaps we need to cover with commitments from the community.

It’s going to be a great meeting, if you’re at all interested in JSON-LD and Open Badges, please join us!

Simplifying Open Badges Federation

We’ve had “Backpack Federation” on the Open Badges roadmap for a long time. It’s always been the next thing we’re going to work on, but it continually gets pushed down the list by other high priority items. My goal in this post is to remove the “Federation” project from our roadmap entirely and focus on the features we mean when we say federation. Those features are absolutely within our reach, some of them are being worked on now, some of them are complete and in production.

What does “Federation” mean?

“Federation” just means distributed, with no central service that’s solely responsible for the maintenance or governance of the service. The internet is arguably the greatest example of a federated network. There’s minimal central authority; anyone can add a node to the network. Facebook is the opposite, a single entity controlling a large network of users and services. Facebook allowing users to post Tweets to their timeline counts as federation under some definitions of the word, but for our purposes, we’re talking about distributed systems without a central authority.

What do we mean by “Federation?”

We pack a lot of meaning into open badges federation, what we really mean is “distributed badge storage that gives users choice and opportunity to be discovered for their achievements.” Federation means more backpacks, more user choice and more user benefit. I’ve written more about federation in past blog posts, and even more about a world with more backpacks.

Some brief user stories help illustrate what we mean by federation,

  • I earn a badge at my local public library and can put it into the Mozilla Open Badges Backpack, or onto my school’s backpack, or my backpack on my phone.
  • I make a badge for Javascript programming public in my backpack. A week later, an employer finds my badge through a search for JS skills and I’m asked for an interview.
  • A researcher gathers anonymous data through the distributed network of backpacks about the amount of time it takes to learn skills equal to an undergraduate math degree via free online courses.
  • I want to learn how to research my genealogy, I find resources and badges online through a search in my backpack.
  • A teacher can see the badges her students have earned over the summer, and associate them with common core standards she needs to teach this year.
  • A teacher can find content and badges for his classroom that maps to common core standards.
  • A teacher can associate a badge they didn’t create with a common core standard; letting her colleagues know that it’s a great alternative to the canon curriculum.

Let’s stop saying Federation

Let’s break down the scenarios above and give a rough idea of what needs to be built to satisfy the need.

I earn a badge at my local public library and can put it into the Mozilla Open Badges Backpack, or into my school’s backpack, or my backpack on my phone.

Our first pass at this feature was a prototype of a issuer api shim that stored your backpack of choice in the browser. It’s still viable, but we’re also thinking a lot about badge baking. A badge that includes metadata about what the badge represents inside the badge graphic, a “baked badge”, is a super portable badge. The current backpack concept requires that the earner “push” their badges into a backpack. By contrast, for years we’ve had an idea for a backpack that ‘pulls’ badges from an issuer; let’s pursue that. With a “pull backpack”, a lot of the burden of the Issuer API is taken from the Issuer. If they give a baked badge on their site, a “pull backpack” can suck it right up. Pinterest for badges!

I make a badge for Javascript programming public in my backpack. A week later, an employer finds my badge through a search for JS skills and I’m asked for an interview.

We’re working on a prototype of a badge directory which focuses on indexing BadgeClasses (the definition of an earnable badge, instead of the BadgeAssertion, which defines an earned badge). If we extend the directory to allow for indexing of BadgeAssertions, backpacks could report earned badges to directory services. The directory services could share feeds of their indexed objects, acting as supernodes in a network of badge indexers.

A researcher gathers anonymous data through the distributed network of backpacks about the amount of time it takes to learn skills equal to an undergraduate math degree via free online courses.

Also solved by a network of badge directories.

I want to learn how to research my genealogy, I find resources and badges online through a search in my backpack.

The Mozilla Discover prototype demonstrates how we can use a directory service that includes explicit machine readable learning pathways to make it easy for learners to create their own learning opportunities. Just like the idea of indexing BadgeAssertions in addition to BadgeClasses, we should create a specification for a BadgePathway and index it in the network of Badge Directories. That specification work will happen in the Badge Alliance Open Badge Standard Working Group.

A teacher can see the badges her students have earned over the summer, and associate them with common core standards she needs to teach this year.

By creating “pull backpacks” (backpacks that gather badges instead of waiting for issuers to push them to them) we’re opening the door for specialized backpacks that cater to specific users – like school age children that need additional checks on their internet usage from guardians and school officials. Allowing a school to host a backpack makes it easier to tie out of classroom achievements with in classroom learning.

A teacher can find content and badges for his classroom that maps to common core standards.

The Badge Alliance Endorsement Working Group is considering methods to allow third parties to add information to a badge, without needing the badge issuer to change their BadgeClass definition or a badge earner to change the issued BadgeAssertion. Badge directories will play a key role here too, indexing these kinds of endorsements and making them available to badge consumers.

A teacher can associate a badge they didn’t create with a common core standard; letting her colleagues know that it’s a great alternative to the canon curriculum.

While it’s great to create an endorsement for a broad audience, we shouldn’t lose site of instances where metadata could be added a badge and shared inside a private group for a specific purpose. Directory services need to scale big, but there are use cases that need small specialized private directories as well.

So, what’s this all mean?

Kind of like the parable of the boiling frog or less gruesomely, my parable of getting a full meal out of a bunch of small plate appetizers, we’re going to meet the goals of federation without a specific project named “federation”. Federation is dead, baked badges, backpacks that pull badges, badge directories, pathways discovery and endorsement are the new distributed federation.

Lot’s of input for this post came from John and Carla. Thanks! Feel free to comment on this post below, or get involved with a Badge Alliance Working Group to keep the conversation going!

Remember our old pal the Open Badges Standard?

The specifications that make up the Open Badges Standard form the basis for the Open Badges Infrastructure; the collection of platforms and tools that make Open Badges possible. While the infrastructure has continued to grow, the standard has remained pretty stable over the last year. That’s not necessarily a bad thing, standards are standards because they’re stable. Despite its growth and reach, Open Badges is still a young project, there’s plenty of work to be done, so it’s time to start looking at the standard with a critical eye. Is it complete? What does it need?

Badge Alliance Standard Working Group is made up of organizations and individuals that ask those questions. We’ve worked together to evaluate the existing specifications and look for opportunities to improve and extend their reach.


The first issue we tackled was largely administrative. How do we function as a group? The Alliance built each working group with a chairperson, an Alliance liaison, and a cabinet the chair and liaison assemble. The Standard WG is a bit different, because we’re maintaining technical standards, we also decided we needed a more formal charter that explained how changes to the standard would be proposed, evaluated and accepted or rejected. We based the first draft on similar charters written by the W3C, and the Python Enhancement Proposal process the Python community created. The first draft of the BA-Standard WG charter is here.


The first task the group took on was to go back through the discussions on openbadges-discussion and pull out features that would make good candidates for discussion in the group.

It was pretty clear that the number one addition we all wanted to see added to the specification was a formal way to extend the assertion, both as a way to add information and as a way to experiment with future ideas.

We posted draft proposal to the openbadges-discussion, discussed, updated, discussed, iterated, and discussed some more.

We found that it was difficult to extend the schema if we couldn’t describe the schema in a machine readable way. We’ve put the extension specification on hold until we have a full json-schema representation of the 1.0 specification. After that, we’ll represent schema extensions in json-schema, most likely taking advantage of the json-schema ability to extend json-schema.

What’s next?

We expect the json-schema-fication of the 1.0 specification / schema by June 24th, and the extension specification by July 8th. After that, we need to sync up with the Endorsement Working Group and ask the difficult question, “After you issue a badge, is it mutable? Can we add information to it?”

How to get involved

If you’re an organization that relies on the Open Badges Standard, or if you’re just interested in schemas and specifications, we’d love your comments on all the above! Join the discussion on the BA-Standard WG Mailing List or join one of our bi-weekly calls.

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 badgekit.org) 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.

BadgeKit Now!

This is the first in a two part series on Badgekit, the new badge issuing platform from the Mozilla Open Badges team. This post talks about the current suite of issuing tools we’ve built, the next post will talk about where we’re headed.

Badgekit is in active development. We’ve written about it a bunch, Erin, Sunny and Jess have all written introductions to it from different angles. There is a release in the future called Badgekit, that will do all the things that the Badgekite site talks about, but there’s also Badgekit-right-now, a collection of tools that the Open Badges team has used to launch the Chicago Summer of Learning, Connected Educators Month Badges, Open Badges Badges, Mozilla Summit Badges and MozFest 2013 Badges.

This post will explain how you can cobble together your own version of what will become Badgekit now. A follow-up post will explain the improvements we have planned, which will make Badgekit different from the collection of tools we have today.


There’s a few things in common in the apps that I’m going to write about here, in no particular order -

  • Node.js – everything we build is in Javascript with Node.js on the server.
  • 12 factor – We’re bought into Heroku’s 12 factor application architecture. We follow it pretty closely. That means that most of these apps use environment variables for configuration and don’t write to the filesystem for anything.
  • Heroku – for most of our production applications, we run in custom AWS EC2 instances, but given the above 12 factor point, it’s entirely possible to run a complete Badgekit-now system in Heroku.
  • Datastores – there isn’t much consistency in datastores, we use MySQL in some places, MongoDB in others, Memecache here and there, Redis. There’s very little consistency (which will change as we move towards real-Badgekit).
  • Lot’s of API’s and Webhooks – the apps all have big healthy API’s and do lot’s of inter-app communication by Webhook callback.
  • One instance per ‘client’ – every client of Badgekit runs their own instance of all the tools. That made it easy for us to punt on serious user authorization. If you can log in, chances are you can do just about everything.
  • Design – we have awesome designed front ends (thanks Jess & co.!) but slightly clunky developer designed admin panels.

Open Badger

Open Badger is the biggest application in the current Badgekit implementation. It handles the core functionality of a badging system, defining badges, issuing them, tracking whether someone has accepted an issued badge, creating claim codes for in-real-life badging, it’s a big collection of tools that accumulated over time. Almost everything is available via the API. A single instance of Open Badger will manage a full badge system with multiple issuers. The model fit the Chicago Summer of Learning, which had issuers, who had programs, which had badges.

You can build a badge inside of Open Badger, define criteria to earn the badge using a bulleted list of yes / no questions the assessment tool uses to evaluate the application, and upload a badge image. You can’t design the visual image for the badge, which we realized was a limitation on CSOL. So we built Badge-Studio (try it out here) to visually design the badge. (Badge Studio is another tool that will be greatly improved for the release of Badgekit).

The best thing to come out of Open Badger is the API. It’s full featured, makes it easy to list badges, easy to issue, and served us well in several installations. It proved to us that a solid API is worth the effort (I mean, we were already pretty bought in, but it reinforced the idea). You can see an example API call here – a list of badges available for MozFest 2013.


First of all – it’s Latin for “assessment.” I named it, for better or for worse, in a fit of Latin nostalgia (does that exist?). Aestimia is the thinnest possible assessment platform. When a user applies for a badge, the client site sends a package to Aestimia that includes the learners submitted evidence and a criteria listing it grabs from Open Badger. Aestimia returns an application id, then calls a webhook url the client site defines with any updates to the application. When an evaluator evaluates the application, Aestimia tells the client site about the changed state. The client site then chooses what to do with that information, either issuing a badge and emailing the learner about their new badge, or emailing the learner that the badge wasn’t awarded.

Because Aestimia only cares about criteria and evidence, it doesn’t necessarily need to end in the awarding of a badge, it could be used for assessment for any sort of situation. It’s entirely possible to build a system on top of Aestimia and Open Badger where a user does several assessed activities before a badge is awarded. Open Badger doesn’t understand an activity outside of a badge, so you’d have to hack it a bit to store criteria, and you’d need to build in some logic (maybe with tags?) to define a ‘path’ but – you could do it. Hacking aside, all those things will be key features of Badgekit, we have lots of plans!


One interesting sidenote from CSOL – because the Open Badges infrastructure doesn’t yet support federated backpacks, and because the current Mozilla Backpack can’t host badges for under 13 year olds, we ‘faked’ backpack functionality by creating an Open Badger API authenticated endpoint that provided a list of badges issued to a particular email id. In installations where users under 13 aren’t an audience, we push the badges to the Mozilla Backpack as a way of ‘accepting’ the badge.

All badge issuers need a place to store badges, I’ll write more about our plans here in the next Badgekit post, but for now – federation will fundamentally change how we think about backpacks.

Client sites

The CSOL client site was heavy compared to Connected Educators Month and Open Badges Badges. Largely because it had to handle user accounts and parent / guardian approval workflow for learners under 13. Subsequent sites were stateless with limited server code, feeding off the Open Badger and Aestimia API’s. That architecture works well for us, we expect continuing with it as much as possible as Badgekit develops.

How it all flows together

Phew, that was a lot of words. Let’s make some (low tech ASCII) pictures explain how all these pieces fit together.

Here’s all the players,

                                                   |              |
                                                   |              |
                                                   |  E-mail      |
                                                   |  Service     |
                                                   |              |
         +--------------------------------------+  +--------------+
         |   A badging site                     |
         |                                      |
         +--------------------------------------+  +--------------+
                                                   |              |
                                                   |              |
                                                   | Backpack     |
         +---------------+      +---------------+  |              |
         |               |      |               |  |              |
         |               |      |               |  +--------------+
         |  Open Badger  |      | Aestimia      |
         |               |      |               |
         |               |      |               |
         +---------------+      +---------------+

Everyone’s there, the overarching site, Open Badger, Aestimia, the Backpack and a e-mail service of your choice.

First of all, a learner visits a badge listing site, the badging site requests a list from Open Badger and shows them to the user,

                                                   |              |
                                                   |              |
                                                   |  E-mail      |
                                                   |  Service     |
                                                   |              |
         +--------------------------------------+  +--------------+
         |   A badging site                     |
         |                                      |
         +--------------------------------------+  +--------------+
                 ^                                 |              |
                 |                                 |              |
                 +                                 | Backpack     |
         +---------------+      +---------------+  |              |
         |               |      |               |  |              |
         |               |      |               |  +--------------+
         |  Open Badger  |      | Aestimia      |
         |               |      |               |
         |               |      |               |
         +---------------+      +---------------+

The user picks a badge, and submits evidence that they’ve completed the badge. The evidence, plus the evaluation criteria for the badge (from Open Badger) are sent to Aestimia. After the evaluator evaluates the evidence, Aestimia calls back to the badging site to let them know they finished the evaluation. (see all the new arrows?)

                                                   |              |
                                                   |              |
                                                   |  E-mail      |
                                                   |  Service     |
                                                   |              |
         +--------------------------------------+  +--------------+
         |   A badging site                     |
         |                                      |
         +--------------------------------------+  +--------------+
                 ^                     +  ^        |              |
                 |                     |  |        |              |
                 +                     v  +        | Backpack     |
         +---------------+      +---------------+  |              |
         |               |      |               |  |              |
         |               |      |               |  +--------------+
         |  Open Badger  |      | Aestimia      |
         |               |      |               |
         |               |      |               |
         +---------------+      +---------------+

Let’s say the learner got the badge! Hurray for learning! The client site then calls to Open Badger to issue the badge, most likely by asking Open Badger for a claim code embedded url that the site can email to the user. Once the site has that link, it sends it to the user via the email service.

                                                   |              |
                                                   |              |
                                            +----> |  E-mail      |
                                            |      |  Service     |
                                            +      |              |
         +--------------------------------------+  +--------------+
         |   A badging site                     |
         |                                      |
         +--------------------------------------+  +--------------+
              +  ^                                 |              |
              |  |                                 |              |
              v  +                                 | Backpack     |
         +---------------+      +---------------+  |              |
         |               |      |               |  |              |
         |               |      |               |  +--------------+
         |  Open Badger  |      | Aestimia      |
         |               |      |               |
         |               |      |               |
         +---------------+      +---------------+

The learner gets the email, clicks on the link, which takes them back to the site to accept the badge and push it to their backpack.

                  |                 |              +--------------+
                  | An email        |              |              |
                  |                 |              |              |
                  +-----------------+              |  E-mail      |
                          +                        |  Service     |
                          v                        |              |
         +--------------------------------------+  +--------------+
         |   A badging site                     |
         |                                      |
         +--------------------------------------+  +--------------+
                                +                  |              |
                                +----------------->|              |
                                                   | Backpack     |
         +---------------+      +---------------+  |              |
         |               |      |               |  |              |
         |               |      |               |  +--------------+
         |  Open Badger  |      | Aestimia      |
         |               |      |               |
         |               |      |               |
         +---------------+      +---------------+

And that’s it! Easy, right? Not really. It’s actually pretty complicated. There are multiple variations to the above flow, and it’s not even clear that we want to make the learner jump through the claim code acceptance flow – most learners just want their badge! Plus, each of those boxes is a separate piece of hosted software. This isn’t a setup for the feint of heart.

Which is really the point of Badgekit – all those services make sense. They’re the right thing, so what can we do to make it easy to use them? Plus – we’re not the only tool provider, maybe there’s a better assessment tool out there, maybe an issuer uses another issuing platform, but wants to use Aestimia. Badgekit will make hosting all these things seamless, without having to know the difference between Open Badger, Aestimia and whatever else, and give an issuer choice in how the pieces of their program work together. To paraphrase some advertising campaign somewhere – issuers should worry about teaching and making cool badges, not about how their badge system moves bits of data around.

[editing help from Sunny and Brian, thanks!]

Open Badges Tech Panel – Backpack Federation

The Open Badges team had its first tech panel way back on September 26th. The tech team met with active Open Badges community members to talk through the heavy tech-bits of Backpack Federation (which I wrote a bit about in “Let’s Make More Backpacks.” The raw notes from the meeting are here and video is here. It’s been a while since the meeting, but I wanted to summarize what we talked about there, and add some thoughts on where we’re headed next with Backpack Federation.

Federation is the Pipes

Backpack Federation in its minimum viable form is about moving badges around between the users backpack of choice. That was our target for the tech-panel demo, and our target for the first release of the feature. The result looks a bit like this,

Federation System Flow diagram by Jess Klein and Brian Brennan

Federation System Flow diagram by Jess Klein and Brian Brennan

It’s a simple goal, we’re confident we can roll it out in a couple of weeks, given it’s prioritization against other projects. However – that’s the Open Badges core team’s goal – the community wants more, and weren’t shy about saying it.

Federation should be about mobility

One of the themes from the discussion was that backpack federation is about more than just moving the badges around, it’s about creating more value in the badge – adding evidence directly to the baked badge, making the badges portable without relying on an issuer’s site, making the badges less about pushing them places, and more about pulling them.

Where do we go from here?

To start with, we’re absolutely going to have more tech-panels. It was a useful conversation and influenced our thinking, which I think you can see in some of the projects that came out of the Mozfest hack-sessions – the full assertion baked in the badge, and the start of the directory service. The former starts to address the issue of true portability of open badges and the latter starts to move us toward a pull-model of badge discovery.

We’re still committed to basic “push your badge to the backpack you want to” functionality as the MVP for Federated Backpacks. It’s a key part of the Badgekit project we launched at Mozfest and opens up the world of customized backpacks in a way that we’re convinced will change learners use of open badges.

Thanks to all that attended the first Open Badges tech-panel! The next one is tentatively scheduled for early November (fill out this Doodle Poll if you’d like to influence the timing). We’ll be talking about the 1.0 changes to the assertion specification and all the possibilities it enables.

Open Badges Hackery at Mozfest

Erin and Jess announcing Badgekit at Mozfest 2013
Erin and Jess announcing Badgekit at Mozfest 2013

Erin and Jess announcing Badgekit at Mozfest 2013

Following up on a post on the Mozfest blog, I wanted to give a big shout of thanks to the folks that came out to support Open Badges in our hack-track. We had around 8 hours of time built into the schedule for building new things on top of the Open Badges infrastructure and the Badgekit stack. I’m thrilled with what we accomplished, some highlights…

Open Badges Crawler / Indexer

Andrew from DIY built a service on top of the backpack that indexes all the badge classes loaded and marked public. It uses our database to bootstrap a crawling process that finds and indexes badges. It’s a first big step towards building a service that makes it easier for learners to find badges they want to earn. We’ll get it deployed live soon, in the meantime the code is up on github/thisandagain/badgecrawler.

Bake Everything!

In the current baking spec, we only specify that the link to the hosted assertion file be ‘baked’ into the badge png. It’s a good thing, because it pushes validation back to the issuer, but it makes very lightweight issuing difficult. Any issued badge requires a server to host the assertion, or a public key to validate a signed assertion. For a huge swath of badges, we’re less concerned about validation, and more concerned about attaching metadata that describes an accomplishment. Mozilla’s own Potch submitted a pull request to the bakery service that bakes the entire assertion into the badge, a huge leap forward for anyone that’s ever wanted to just quickly bake and email someone a badge without worrying about hosting.

Badge Everywhere!

The fine DigitalMe folks posted a map where people could put physical push pins that represented a commitment to launching a badge program in the place under the pin. The ever-resourceful and recent OpenBadges full-timer, Erik Christensen, built it as a real web site – Badge the World!

Badgekit and Appmaker, PB&J

We announced Badgekit (more on that from Erin, Sunny and Jess) at the festival, launched Open Badges Badges and MozFest badges on the platform and then started playing around with it. A few people came to the hack sessions wanting to mobile-ize issuing. Jess led several sessions on tools for disaster relief that included badges (which she writes more about on her blog), Telefonica and Unicef joined Mozilla to work on a mobile donation platform that included badges and bunch of us wanted an app to issue badges in a game of werewolf (excuse me, WereFOX).

When we realized we were in a room full of people that wanted to make mobile badging apps, we decided it would make more sense to build a series of Appmaker components. All in all, David, Laila and I built three key components, an issuer (which interacts with OpenBadger via claim codes and the API), a badge lister (fed by the OpenBadger feed) and a Twilio SMS’er. Given those ingredients, it’s possible to build a whole bunch of interesting things. The Appmaker team is working hard on getting external component libraries includable from the main Appmaker site – as soon as that happens we’ll be able to unleash a hoard of custom mobile badging apps!

Appmaker is really pretty cool to work with, and matches the goals we have for Badgekit – make hard things easy, build a community around a product. We’ve known the Appmaker squad for a while, and we’re super thrilled how easy it was to smoosh Badgekit tools into Appmaker containers. Really excited to keep that going.

Doug caught a great picture of the Erin / Jess plenary demo of the Appmaker / Badgekit super-combo,

@willowbloo just posted (Nov 3) a video summary of the disaster relief badge project she and others worked on, more on Youtube.

Learning Pathways

Chloe and Mike built this amazing demo of where we could head with Learning Pathways. The process of linking badges together into a pathway that other learners can duplicate and follow.

More Yack

After a series of discussions during the hack sessions, Brian launched the Github discussion repo mozilla/openbadges-discussion. There’s already a great conversation going about extensions to the spec for indexing going on. We all like hack, but without a good yack now and then, we’re all just bumping into walls. ORGANIZE THE HACKS!

Who needs digital?

Finally! Cross-stitch badges, courtesy of Cordelia,

Huge thanks to everyone that helped during the hack sessions, supports Open Badges and were super fun to hang out with…BADGES IS A BIG DEAL FRIENDS, LET’S KEEP MAKING THEM.

If I missed something badge-ish you worked on at the festival, drop me a note in comments and I’ll get it added!

[Oct 31 edit - added Learning Pathways]

[Nov 4 edit - adding disaster relief badges video]

[Nov 5 edit - adding link to Jess' summary of the Community Aid Badging sessions.]

Let’s Make More Backpacks

School is starting, which makes me think about school supplies. We use some school supplies as metaphors in the Open Badges world, the Mozilla Backpack is the place you can store your Open Badges. The current backpack stores open badges, organizes them and displays them. It’s really more of a portfolio than a backpack, a collection of achievements instead of something you need while you’re learning day-to-day.

The core functionality of what makes an open badges backpack valid supports the broken metaphor. A backpack (in the open badges sense) is a place to store badges. It validates the badges. It displays them. Maybe it organizes them, but that’s not a requirement. It’s just a filesystem with stuff in it.

So, should we change the name? Should we ditch the backpack metaphor and start calling it a ‘badge storage system’ (gag) or something? No, we shouldn’t, we should let the metaphor guide the development of what an open badges backpack is.

Backpack as Personal Expression

Ask my six year old about his school backpack. He’ll tell you all about it. It’s big, but not too big. It has Marvel super heroes on it. It has a special flap that let’s you choose between two different sets of super heroes, so he can change it up day-to-day. It has a single pocket, nothing fancy to get in the way of the essential nature of what a six year old needs, a place to put his lunch and a small amount of homework.

Ask me about my backpack, it’s biggish, but has these straps that make it small. It’s full of pockets that are easy to get to, some of which have a soft lining for electronic devices. It has a stiff back so that protects my laptop. It’s flat black and emphasizes utility and comfort. My last bag was a courier style bag with snazzy materials. It had a big single pocket that was easy to get to, and the design would impress people who were impressed by that sort of thing. I like both of these bags, but they’re very different and I use them for different reasons.

See what I’m getting at here? Real backpacks serve different purposes. They’re indicative of who we are and express ourselves in different ways. My bag won’t work for my son, his bag won’t work for me. Sometimes I use my utilitarian bag, sometimes I use my fancy bag.

Real backpacks as open badges backpacks lesson one – one size doesn’t fit all, open badges backpacks should be as various as real backpacks. Sometimes you need more than one backpack for different situations.

Backpacks with Constraints

Some schools have requirements about what their kids can use as a backpack. The most common is that they are clear, so teachers and staff can see inside them at any time. It’s not the greatest thing for student privacy or personalization, but as a constraint – it exists.

Lesson 2 – institutions will put constraints on the open badges backpack that won’t apply to all users. We need to accommodate them.

You’re lost without your backpack

Did you ever forget your backpack at home? Or your laptop bag? Your stomach  flip-flops, it’s borderline terrifying. In a learning situation, you’re lost without your backpack.

That isn’t the case with the current Mozilla Open Badges Backpack. The backpack is an after thought in a learning experience. It’s the place you push the results of your learning, not the place you’re actively planning your learning. It’s the equivalent of forgetting your report card at home. Who cares?

Which leads to lesson 3 – let’s make our open badges backpacks more useful, part of your day, essential to the way you learn. The badge backpack isn’t a trophy case, it shouldn’t just be a portfolio, it absolutely isn’t a report card. The backpack is where you go to track your progress, reflect on what you’ve learned, discover new paths you can take to get where you want to go. It’s your learning GPS, something essential to your learning.

What’s Mozilla Doing About It?

Yeah, so – backpacks can be cooler. What’s Mozilla doing about it? Three things:

Many Backpacks

There’s only one real open badges backpack today. If you press the button “push this badge to your open badges backpack” on any issuer’s site, it really means “push this to your Mozilla Open Badges Backpack located at http://backpack.openbadges.org” That’s what the world of badging needed to get started. It needed a single backpack, to prove the concept and bootstrap issuing.

Now that we have a healthy issuer ecosystem, it’s time to bootstrap a healthy backpack ecosystem. We’re working on extensions to the Open Badges Infrastructure that will allow a user to choose their backpack and push their badges there. There isn’t any burden on the issuer, they’ll still integrate a single button served by Mozilla, but the button will be 17% more magical. Once a user can push their badges wherever they want, they’ll want choices.

This feature has been on our roadmap for a while under the unintentionally obfuscated title “Federation.” It makes sense to us, but it’s hard to explain to the community. We’re working on better language (and could use your opinion, get involved in the mailing list) regardless of the name, the result of the feature is clear, learners get to choose their backpacks.

Mozilla Backpack 2.0

After a fair amount of soul-searching, we’ve decided to refactor the existing Mozilla Open Badges Backpack. We’ll do the work alongside support of the current 1.0 backpack. We’re not planning any significant features in the 2.0 backpack, it’s mostly a feature for feature replacement of the existing backpack. We’ll rework the UX, make branding changes to get the backpack in line with the current branding of Open Badges, but will mostly mirror the existing 1.0 backpack.

Why do it? There’s a significant amount of boiler plate functionality that makes up an open badges compliant backpack (which in itself is a moving target, we haven’t actually declared the requirements of a backpack yet, we will, so keep your ears peeled). If we want to encourage a diversity of backpacks, we’d like to offer a solid starting point. A collection of code that allows for easy extension of the backpack concept. If you have an itch to scratch backpack-wise, you can do it in a few days, or hours, you won’t have to recreate yet another storage system for assertions, or validation against the spec. Fork our code and focus on what you should, providing an awesome experience for your users.


Finally, Jess, Andrew and Emily are leading the charge towards a new vision of an open badges backpack. They’re working on backpack 3.0, or backpack 3000, or Badgeopolis. A backpack prototype that’s as important to you as that backpack with the flippy cover so you can show whatever super hero you want to. It will be a concept car like experience that will help guide future backpack crafters and seed the world of post it-just-stores-badges backpack thinking.

Exciting, yeah?

We hope so. Open Badges is taking off. We’ve proven to issuers that they can use open badges to guide their learning communities. Let’s get the same level of innovation applied to tools for the learners. Let’s make open badges backpacks as diverse and personalized as real world backpacks. Why settle for badge storage? You’re way cooler than that.