Contact Us Support Forum Get Email Updates

Thanks! Someone will be in touch with you shortly.

Rather just email us? Email us here.
Rather speak with someone in person?
Call any time with Tin Can questions:


An Open Can of Tin Badges

Posted by

Categories: Tin Can

Posted 31 March 2015


badge-breakout-bottomPeople have been talking about a crossover between Open Badges and Tin Can (xAPI) since 2012. Blogs have been written, ideas shared and there’s even a Twitter account that got set up at one point! Nobody has actually come to the point of defining the details of how it would all work though. Until now.

If you’re not familiar with Open Badges, this blog from 2012 still gives a good introduction. If you are, then read on!

Today, we published an xAPI Open Badges recipe to the Registry. This recipe is the work of the xAPI Open Badges working group including people from both the Open Badges and Tin Can communities. The recipe has also been published on and uses identifiers; this is a real collaboration of both specification groups.

On today’s webinar I’ll be talking in detail about a range of problems that Tin Can has the potential to solve in the Open Badges world, but for now, let’s focus on the problem solved by this first version of the recipe: transferring earned badges between systems.

Imagine an organization that awards Open Badges to their learners, recognizing and credentialing their achievements. The learner might also earn Open Badges outside the organization from learning websites or professional bodies; how can they bring those badges into the organization to sit alongside those they have earned internally? Or as an organization with a load of Badges in your LMS, what do you do when the time comes to migrate to a new system?

Without Tin Can, Open Badges provides two mechanisms for transferring badges:

  1. Download and upload of the badge image.

  2. Integration with the Mozilla Open BackPack.

The first option is a poor user experience and a time sink, particularly if there are a lot of learners importing a lot of badges from the same source. It works, but it’s not ideal.

The second option requires the learner to register and then store their data on Mozilla’s BackPack. Again, the additional registration is a hurdle for the user. There are also security and privacy issues with storing learner data on a 3rd party system that the organization doesn’t have a contract with. Furthermore, there’s no way to associate identities within the BackPack, so earning badges with a mixture of work and personal email addresses is problematic.

The recipe published today solves this, by enabling earned Open Badges to be stored in an LRS as a Tin Can statement. These can then be shared between LRSs like any other statement, meaning earned badges can be accessed by any system capable of retrieving statements. The baked badge image (an Open Badge image containing embedded metadata) is attached to the statement and all of the badge metadata is included within the statement, allowing for easy access without having to un-bake the badge.

This is good news for systems that already implement Tin Can and/or Open Badges, and especially good news for those planning to implement Open Badges from now on. You can now use an existing LRS (get a free account on SCORM Cloud) and our open source Tin Can libraries to store badges as statements and retrieve them for display wherever you want them.

badges-prototype-screenieNext Steps

We’re working on a PHP prototype that demonstrates the recipe in action. Badges are earned by clicking a button (it’s just a prototype – we kept it easy for you!) and stored as Tin Can statements.

The statements are then retrieved and the badges are displayed both as a list of earned badges and within an activity stream. There’s no need to connect to the Mozilla Backpack or a database; the full record of the badge is stored within the LRS.

Within the xAPI Open Badges working group, we’re now turning our attention to the definition of Badge Classes with Tin Can. This will enable one system to define a badge and transmit the definition to another system. This system can then compare criteria to learner records and award badges to learners as appropriate. A limited implementation of this will be included in the prototype.

Expect more on this topic in the coming months!

If you’d like to hear more about implementing Open Badges with Tin Can in your product or organization, please get in touch!

  • Todd

    Love the crossover and the forward thinking. It only makes sense these two things have some sort of interaction.

  • Nadav Kavalerchik


  • Pingback: Webinar Q&A: "Nine Practical Uses of the Tin Can API (xAPI)" - Tin Can API()

  • Serge Ravet

    Witty title and great idea!

    To the Backpack option you will be soon able to add the Open Passport 😉 Your comments will be precious.

  • Andrew Downes

    Thanks Serge! I know you’ve been pushing for a crossover between the two specifications for a while!

  • Pingback: An Open Can of Tin Badges - Tin Can API | xAPI,...()

Tin Can API Email Updates

* indicates required

Tin Can API Email Updates

Thanks for signing up for the Tin Can API newsletter!

Make sure to follow us on Twitter @ProjectTinCan,
and tweet this page to let others know about the Tin Can API.