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.