Mozilla Open Badges

Infrastructure Technical Documentation

STATUS

Currently in: BETA1, September 15th, 2011 (Source Code)
Next Up: BETA2, October 2011

Mozilla Open Badge Infrastructure (OBI)

BACKGROUND / FRAMING
Why Are We Doing This?

Learners are learning everywhere -- but most of that learning doesn't count
Exploring badges as an alternative accreditation/credentialing system
Must avoid more silos
To truly support learners learning everywhere == support badges issued from multiple issuers across the Web
To optimize the value of those badges, need to be remixable and shareable with many different audiences/sites
Need a supporting infrastructure to standardize the process and support each user collecting badges from multiple users and sharing subcollections out across various displayers.
This infrastructure needs to be open and as decentralized as possible to give learners control and support the entire ecosystem

Description
Enabling learners to earn badges wherever they're learning across the web requires support for multiple individual badge issuers. Empowering learners to use their badges as legitimate credentials requires support for sharing of badges across many display sites. The Open Badges framework is designed to allow any learner to collect badges from multiple sites, tied to a single identity, and then share them out across various sites -- from their personal blog or web site to social networking profiles. It is critical for this infrastructure to be open to give learners control over their own learning and credentials. allow anyone to issue badges, and for each learner to carry the badges with them across the web and other contexts.

TECH SPECS

The OBI is built in node.js using express.
Badges are represented by JSON data blobs embedded in PNG files in the Backpack
Identity management is handled by Mozilla BrowserID

DEFINITIONS

Badge - The core currency of exchange. A single credential demonstrating a skill, achievement, quality or affiliation. Badges are represented as chunks of JSON data in the OBI Backpack. Badges may be stored in the Backpack as either Verified Badges or Unverified Badges.
- Badge Manifest - User identity information (email address) plus badge information (JSON metadata)
- Verified Badge - Badges that have been signed by a third party. The Backpack verifies the signature against the signers public key and if confirmed, accepts the badge as a verified badge. The verification information is represented with the badge as a layer of trust on the badges validity.
- Unverified Badge - A badge that has not been signed by a third party but is issued as flat JSON data. Unverified does not mean invalid, but simply that there is no additional information with the badge to establish an additional layer of trust. Most badges issued into the OBI will be unverified badges.
Open Badge Infrastructure (OBI) - open infrastructure technology to support independent badge issuers and display sites. Includes the Badge Backpack(s), Metadata Spec, API and Authentication/Verification Framework.
- Hub - The core authorized data store. Each learner has his/her own hub where all badge data is stored. The Hub software will be open source so if a learner wants to install and manage their own hub, and thus completely control all of their credentials, they can. Mozilla will manage the hubs for users who do not install their own.
- Badge Backpack - The core authorized data store and management interface. Each learner has his/her own Backpack where all their badge data is stored. Mozilla will host the reference Backpacks, but the infrastructure will allow for users to develop and host their own Backpacks. NOTE: the Backpack is being combined with new iterations of the development. Each user will have their own Backpack that holds all of their badges and gives them an interface to manage, control and share their badges.
- Metadata Spec - The definition of what makes up a badge. Each badge is a chunk of metadata that describes the badge, including title, description, issuer, issue date, evidence URL, image, etc. Each issuer will need to conform their badges to the metadata spec for the badges to be accepted into the Backpack. Beyond the technical requirements, the metadata spec is essential for standardizing badges to ensure that badges can be transferred/ported without losing critical information to understand and verify the badge. Beyond the core spec, the metadata is extensible.
- Badge Baking - Embedding the JSON blob into a PNG file to make a fully robust, portable badge (with all of the metadata embedded)
  - Badge Baking Service - tool/software to embed the JSON blob in a PNG. Mozilla will build the reference baking service for beta
- API - The interface specifications for pushing badges into the Backpack (issuers/users), as well as pulling them out (display sites/widgets).
- Authentication Channel - Communication channels and framework to support badge authentication (was this badge issued to this person on this date? Has it expired? etc.)
- Verification/Endorsement Channel - Communication channels and framework to support badge endorsement (was this badge signed? is the signature valid?)
Users/Partners
- User - a person storing their badges within the Open Badge Infrastructure. This user has had interactions with issuers to earn badges, then logs in via their Backpack to manage those badges, and can share out to various display sites as well.
- Issuer - Organization, consortium or individual who issues badges into the OBI. The OBI is open and supports any independent issuer that conforms to the necessary badge and issuing specifications.
  - Issuer Tech - Software that supports issuing of badges into the OBI and/or to users directly. The issuer tech must generate the JSON data chunks for each badge, and communicate with the Backpack(s) to pass badge data and authenticate badges. Many issuers will build their own issuer tech, although open generic or technology-specific tools could be built to support a wide range of issuers.
- Displayer - Website, run by an organization, consortium or individual, that pulls badges from the OBI and displays them for a user. Displayers could range from social networking sites like Facebook or career social networks, to job search/application sites to personal blogs or sites. Each user manages which display sites can access their badges (and which subcollection of badges to display per display site) through the Backpack or directly on their own.
  - Widget - Software that supports the display of badges on a particular display site. Widgets will communicate with the Backpack to pull badges, as well as utilize the Authentication/Verification Framework to authenticate badges before displaying. For example, one could build a Facebook app that leverages both the OBI API to pull badge data, and the Facebook API to push badges into Facebook.
- Signer/Endorser - An organization, consortium or individual who validates a badge by signing it with their private encryption key. Trusted third party signers may emerge.
  - Signing Authority - A third party that checks signed badges against the signers public encryption key and confirms or rejects verification. Backpack communicates with the signing authority to verify the badge if signing data is included with the badge (otherwise the badge is Unverified).

WHAT MOZILLA IS BUILDING

Diagram
https://wiki.mozilla.org/images/a/aa/Open_Badges_--_tech-diagram-_2.2.jpg

Backpack + Metadata Spec + APIs + Authentication Channel + Endorsement/Verification Channel == Open Badge Infrastructure

Details

Backpack is authorized data storage plus a management interface for users
If applicable, the Backpack verifies badges by communicating with a signing authority via the verification channel
The Backpack is open source - users may decide to create and host their own Backpack so that they have complete control over their badges. Mozilla is building a reference/default Backpack.
Issuers push badges to the Mozilla baking service where the JSON blobs are embedded into PNG files
For beta: Badges are then pushed to the Backpack, as well as back to issuers to email directly to users.
Post beta: Issuers manage the user interface on their side to have users authorize badges sent directly to the OBI or just emailed to them
Displayers pull unpacked badges (JSON) out of the Backpack based on privacy settings and user action.
Public badges are discoverable by user email address
User can share badges through the Backpack, thus granting permission for a particular site to display that set of badges
Displayers authenticate badges with the issuer using the Authentication Channel

METADATA SPEC

A badge is a JSON blob of metadata embedded in a PNG file.
This is the data presented at the Authentication URL on the issuer's server
The metadata should carry all the information needed to understand a badge. This ensures that badges can be fully understood and authenticated no matter where they are shared or used.
NOTE: trying to keep the spec as simple as possible while still carrying enough information to completely understand the badge/credential
The metadata spec is currently locked down for the beta launch (see link below). Fields:* Badge Title
Badge Image URL (served from the issuer's site or cached?)
We are probably going to end up doing image caching on the Mozilla side
Short Badge Description (plain text, hashtags, 140 characters?)
Badge Criteria (URL, required - optional metadata at url?)
Issuer (Human readable name)
'Organization name or just individual name
Issuer Contact (email address)
Issue Date
Badge Expiration Date (optional; default none)
Badge Evidence URL (optional; highly recommend?)
Maybe: User-added field (could provide URL or more context/text) (optional)
Push this off into the Backpack?

Finalized Badge Manifest/Spec:
~~http://openbadges.lighthouseapp.com/projects/80353/badge-manifest~~
Updated 9/1: https://github.com/mozilla/openbadges Changes:

Did not change the fields, just changed the order
This allows us to separate the static badge type information from the specific badge instance information.
This will make endorsements/signing easier since third parties can sign/endorse a badge without having to do so for each instance of it. (Inheritance.) For example, if MIT signs the P2PU Javascript badge (title, description, criteria, image, issuer info, etc.), each P2PU-issued Javascript badge carries that endorsement info with it. This allows post-issuance endorsement and results in up-to-date badges.

Badge Manifest Verifier:
Used to test the sending of your JSON blobs to Mozilla
https://github.com/mozilla/openbadges

PNG FILES / BADGE BAKING

Each badge will be a JSON blob of metadata embedded in a PNG file
This allows the badge to be more easily portable - an actual 'thing' that can be emailed around, carrying all the information with it
Ultimately, this is important for decentralization of the system - so that users have more control over where their badges live
For beta, Mozilla will be providing a 'baking' service to package the JSON into a PNG file
Issuers will still send the badge manifest to the Mozilla, just instead of sending it directly to the Hub, they will now send it to the Mozilla 'baking service' and Mozilla will package it into a PNG and:
1. push it to the Backpack (for beta)
2. deliver back to the issuer who can then send to the user
NOTE: step 1 is for beta only. We eventually want to get to #2 only and have the issuer manage the interaction and the user control the badge. This is A) to avoid SPAMing the user with unwanted badges (which we can control in beta) and B) to give the user ultimate control over where the badges go.
Mozilla will provide the 'tools' for unpacking the PNG file through the OBI
PNG files will be unpacked in the Backpack where each user can view, manage and organize their badges (and see all the metadata behind each badge)
PNG files will be unpacked for the displayer API so that displayers will just have the raw data to work with on their end.

Technical Specifics / API Specifics: https://github.com/mozilla/openbadges

BADGE IMAGE STANDARDS

Image must be a PNG (for beta).
Potentially: In later iterations, we can convert to a PNG (Why permit flexibility after launch? Why not stick with a default requirement?)
Other than that, we are only specifying that images should be square and not exceed 250K maximum size
Image is provided as a URL to the image on the issuer server in the metadata
Mozilla will cache the image in at least 2 sizes
When a badge is displayed, it will be loaded from the Mozilla cache to avoid extra burden on the issuer servers, also in case the issuer is not available or link is broken
Note: this is under consideration. Since the JSON is now embedded in the PNG file, we might not need this cache

ISSUERS AND DISPLAYERS

"ISSUE REQUIREMENTS / WHY & HOW TO BECOME AN ISSUER" "Independent Issuers"

Issuer badge systems are independent of the infrastructure - how you assess work, decide who earns badges, issue badges within your site, display badges within your site, etc. - that's all up to each issuer
We are intentionally pushing the innovation to the fringes/edges at this point - meaning the issuers have complete control over how their badge system works
We want to support innovation, not constrain it
The touchpoint with the OBI is pushing each badge into the designated Backpack for the user

Why Become an OBI Issuer

Openness - break badges out of a single silo
Learners can earn and share badges from multiple issuers
Learner portfolio or living transcript that they control
Display them across multiple sites (without getting stuck in those sites)
Maybe: Discoverability (allowing them, employers or other stakeholders to find people based on badges)
Maybe: Reporting/tracking (pushing out data about learning paths and experiences (in aggregate) for evaluation, effectiveness, etc.)

Requirements for issuers

Issuers must be able to communicate with the Mozilla baking service
Issuers must have email addresses for users and must be able to email users
Issuers must have badges (or be able to convert their badges) into the format (metadata spec) that the baking service expects.
~~Users must be registered with whatever hub the issuer is trying to push badges to, or (for later versions) the Issuer must ask user which hub they want to push badges to and honor that request~~
Issuers must maintain a server with the badge manifest information (at the unique badge URL) to authenticate each badge
NOTE: unless the issuer signs the badge instance. If badge instances are signed with the issuers private key, then the OBI can verify the badge and it would not be necessary to maintain the authentication channel

NOTE: We have an example of issuer tech, built in python with the alpha version of the infrastructure in early July. This code is available for partners to explore/utilize for their own issuing: https://github.com/lmorchard/django-badger. We will also provide some assistance for beta partners if needed. This needs updating based on the new manifest changes - will be updated after 9/15

Function Flow For Issuers:

0. Issuer must have an email address for user.
1. Issuer provides a badge manifest (retrievable by GET request) to Mozilla baking service

manifest contains email of user + badge information

2. Verification of issuer and issuee is implicit
- badges are associated with issuers by fully qualified domain name (visual distinction in artifact)
- email address == identity

BETA:

3. Mozilla baking service forwards embedded PNG to the Backpack.
4. Mozilla sends PNG back to the issuer
5. Issuer forwards the badge to the user (most likely via email)

POST BETA:

3. Mozilla baking service sends PNG back to issuer
4. Issuer asks user how they want the badge: sent to the OBI or delivered via email
5. Issuer honors user's choice and sends to the OBI and/or to the user directly via email

DISPLAY REQUIREMENTS / HOW TO BECOME A DISPLAY SITE

Display of badges is where a significant part of the value lies - badges are not siloed or 'stuck' within one site but can be combined with badges from multiple issuers and then shared out for different audiences/purposes
Mozilla will provide the displayer APIs which will unpack the PNG files and present displayers with the raw badge data
The displayer API is not yet fully developed - we are still working through these specifics and will have this sometime soon after beta launch
User will control where badges are displayed through the Backpack
User can create groups of badges and share through the Backpack to issuers that have connected via the API
Users can also make badges public - in that case, those badges would be discoverable by displayers if they had the users email address
At its most basic: if a site has a user's email address, they will be able to query the Backpack for all a user's public badges. They will get back JSON representation of the badges
We are building the first widget for the beta - a Facebook widget
Also will provide the user with embed code in the Backpack so that they can embed badges into any personal websites
Other display partners we are currently working with:
InsideJobs - data analyis of badges and badges for job opportunities
Adecco - badges for job opportunities
Parchment - badges alongside formal education credentials
LinkedIn - badges included on the career profile (Possible)

Functional Flow For Displayers:
PUBLIC BADGE DISCOVERY:

User sets privacy controls on badges through the Backpack; sets some of the badges to Public
Displayer queries the Backpack via the user's email address
Mozilla unpacks badges and sends the JSON for all public badges for that user to the displayer

USER SHARE

Displayer registers with the OBI as a displayer - meaning they will show up as an option for sharing in each Backpack
Users create subgroups of available badges through the Backpack
Users share subgroup(s) with displayer through the Backpack
Mozilla unpacks that user's badges and sends the JSON for all public badges to the displayer

Results:

User maintains control of their badges, can choose where they go
One backpack per user - ~~personas (email addresses) get aggregated at the hub level~~
- ~~user doesn't have to have same email at every issuer~~
Simple to implement
Difficult to spoof
- Issuers must keep badge manifest on their server. manifest data identifies recipient
- Unintended recipients can't claim badge
- Backpack identifies issuer implicitly: parses FQDN to identify issuer
  - Bad issuers may "copy" another badge but it will be easy to spot
  - Artifact contains FQDN.

IDENTITY
Verified Email Identity

Identity is a critical part of the OBI because we need to know/recognize a user all across the web as s/he collects badges from different issuers/sites
Identity needs to be open and decentralized
Mozilla.com is working on a solution called Verified Email
https://wiki.mozilla.org/Identity
The idea behind verified email as identity
people understand email address (they don't understand OpenID)
many sites already use email for login
even those that don't generally collect it (for resetting password)

OBI Identity

We are using the first version of Mozilla Verified Email Identity, called BrowserID (https://browserid.org/) for the beta version of the OBI
Implement signup for Backpack as email-based usernames, do SMTP challenge (email user a token link they must click) to verify.
We will roll in future versions of Verified Email Identity as Mozilla Labs releases them

Functional Flows
For Backpack:

1. User validates identity to Mozilla's Verified Email
1. 0. Moz ID. Act as a secondary authority.
2. 1. User creates an account with mozilla (same as sync account)
3. 2. and asserts which email addresses he or she owns.
4. 3. do an SMTP challenge to prove ownership
2. We don't need to retain any profile or personal information about the user, all we need is email address.

USER BACKPACK CREATION/REGISTRATION
Backpack creation

Mozilla is building a reference or default Backpack which will hold all of the badge manifests (user email+badge data) for each user
Users can create/build their own Backpack, giving them complete control over their badges/credentials* For beta, we will automatically forward badges to the Backpack to seed the ecosystem and work through other options
Ultimate goal is to allow users to have control over their badges and make it easier to maintain their own Backpack

Backpack registration

Issuers do not need to register with the OBI - they simply push badges to the baking service

BADGE AUTHENTICATION
Authentication

To avoid gaming and duplication, the OBI is built to support badge authentication.
This handles the questions of "Did this issuer issue this badge to this user on this date? Is this badge still valid or has it expired?"
The OBI provides the channel for this authentication to happen through the Backpack, but must communicate with the Issuer.
Issuer must be online to authenticate badges. (we are exploring a cache to cover authentication for x amount of time)
Most authentication will be done by the Displayers. Displayers should not display a badge that cannot be authenticated.

Functional Flow

0. Badge manifest exists in the Backpack
1. User attempts to display badge via a display site widget
2. Display site uses the Authentication Channel to communicate with the issuer to confirm that this badge was in fact issued to this user on this date, as well as if the badge has expired, needs updating, etc.
3. If authenticated, displayer shows the badge. If not authenticated, displayer should reject the badge.

BADGE ENDORSEMENT (SIGNING / VERIFICATION)
Badge Endorsement

We recognize a need for some badges to be validated or verified by authorities or trusted entities
The current solution we are working on is badge signing/verification functionality which would allow issuers to have their badges signed and the Backpack to verify that signature
Uses asymmetric encryption between a signer and signing authority. The signer may be anyone that an issuer feels can add a layer of trust to their badge.
This means there would be Verified Badges and Unverified Badges in the Backpack (a majority may be unverified)
Verification information is carried in the header of the badge manifest
Badge manifest is nested the way it is so that endorsers can sign the badge type ahead of time, or after the fact, and then all instances can carry that information with them.
We are still working out how the verification information is displayed to an end user.

Functional Flow

0. Issuer sends badge to signer
1. If accepted by signer*, signer sends badge back to issuer signed with signer's private key.
- If not accepted by signer, signer sends back back to issuer unsigned
2. Issuer issues badge to user
3. Issuer/user pushes badge to Backpack
4. Backpack communicates with the signing authority to confirm the signature against the signers public key
5. If confirmed, Backpack accepts the badge. If unconfirmed, Backpack rejects badge.

DEVELOPMENT ROADMAP

Prototype - A prototype of the badge infrastructure was built at the Mozilla Drumbeat Festival in Barcelona. The prototype was updated and advanced in early January 2011, and a more complete and working prototype is now in use for the School of Webcraft badge pilot program.
Alpha - The alpha version of the infrastructure, built for P2PU as the initial issuer will be launched in late July 2011. The alpha will include user account creation, a simple Backpack interface, minimum verification and P2PU issuer tech. All badges earned from the P2PU School of Webcraft Assessment and Badge Pilot will be pushed into the alpha infrastructure with support for displaying across personal sites and the P2PU profile.
Beta1 - The first beta version of the infrastructure will be launched early September 2011. The beta will be a fully functioning (critical feature) infrastructure, including all Backpack technology. Initial issuers will plug in over the few months following the launch. We are doing a closed beta launch to work closely with an initial group of issuers to fine tune the technology and ensure that we will have data and experience to evaluate the infrastructure.
Beta2 - The next wave of beta will include more features including the Displayer API and will be launched in ~~October~~ November 2011.
1.0 Public Spec - In January 2012 we will release the 1.0 version of the Open Badge Infrastructure with all necessary supporting documentation and tools to make it self-service

TEAM

Brian Brennan - Tech Lead, Mozilla
Erin Knight - Badge Project Lead, Mozilla
Carla Casilli - Badge Project/Operations Manager, Mozilla
Matt Thompson - Communications/PR, Mozilla
Dan Mills - Mozilla Identity, Advisor
Additional hire: Supporting Tech, Mozilla
Additional hire: Issuer Tech Support, Mozilla
Additional hire: Issuer Badge System Support, Mozilla
Additional hire: Researcher/Analyst, Mozilla
Partners/Advisory Group