I’ve been working with a number of different projects that are interested in the idea of utilizing open badges as a hook for creating a motivational and pedagogical pathway through their open course content.  Being located in a province and institution with a strong privacy commitment means thinking hard about privacy before implementing  tools that potential share student information with third parties, such as the WPBadger WordPress plug-in that would allow us to issues badges to Mozilla’s Open Badge Backpack.

Just to help think through privacy from the user perspective, I believe that there’s basically three levels to information sharing that would be involved in open badges – one is at the university level, one is at the system level, and one is at the individual badge level.  I’m going to use a very clumsy and simplified metaphor here: in some ways issuing badges via something like the WPBadger plugin would be similar to the “tweet this” widget found on the bottom of many university sites.  Clicking on the twitter icon will send the user to twitter, where they have to log-in, then they see a pre-formatted tweet that they can edit, then they have to hit publish to push that message into their twitter stream.

So at the university level, you have a twitter widget that sends information – “this user” clicked tweet this on “this page” –  between the university webpage and twitter.  For an open badge system, the information communicated between the university site and the badge framework is “this user” earned “this badge”.  Mozilla treats “this user” as an email address.  Indeed, a badge issuing tool like the WordPress WPbadger plug-in, the user data transmitted from the issuing site to Mozilla is only an email address – and the badge, more info about that shortly.  So only contact information – no names, student numbers, grades, etc.

At the system level, a user will have to have log-into a third party account.  In twitter, once clicking that “tweet this” button on a university site, the user has to have a twitter account to actually tweet anything.  Similarly, with badges, the user has to have a location (called a “backpack” in Mozilla terminology) where they collect/store and display their badges that they have earned across multiple places (i.e. a user may have badges from Purdue, Illinois, UBC, etc).  The Mozilla backpacks are, again, based only on a verified email address (nothing more).  Similar to twitter, where the user still has to publish the tweet, users still have to publish the badges they have earned in order to make them publicly visible.

At the individual badge level is probably the area where the most sensitive information could possibly be shared.  In the twitter widget, a pre-formatted message can be created.  This pre-formatted message could be anything and thus, theoretically, could contain information, which when combined with a user account, could be seen as sensitive (e.g Will tweeted “I just enrolled in BIOL104”).  Similarly, the open badge is really just a collection of metadata and thus could also contain sensitive info such as a grade (The BIOL104 A+ badge).   Again though, users will have to manually publish any badges they earn before they are publicly viewable.

It’s possible to build a system that’s not predicated on a third party like Mozilla, but in many ways this will decrease the usefulness of an open badge and will not decrease the metadata issue as well.  Information conveyed in an open badge is meant to be, well, open but the key aspect when it comes to privacy is that such badges are also meant to be optional, opt-in, and user controlled at many different levels: optional to earn, optional to have an account, optional to display.