Badges/Onboarding-Earner/Non-Technical
Contents
A. Mozilla Open Badge Infrastructure (OBI)
I. BACKGROUND
Why Are We Doing This?
Over the last 100 years there has been considerable amount of research in understanding how human beings develop understanding and "knowing" of subject domains. It has become increasingly recognized that people obtain most of their skills and knowledge (learning) from outside of traditional learning institutions. And the wisdom, skills and knowledge that a person accumulates throughout a lifetime comes from many sources and learning activities. The open badges project is building a technology to work within these realms to provide a method for recognizing the learning that occurs both within traditional learning institutions and informal settings.
Tacit Knowledge
One of the important bodies of research / thought within the subject of how human beings learn and gather knowledge can be attributed to Michael Polanyi. Dr. Polanyi introduced the idea of tacit knowledge, which essentially means much of what we know is not expressed or declared openly. In other words, it can't be found in books or learned in a traditional classroom. It is the knowledge that we gather as we live a life and engage with others and the events that form who we are and what we have learned. This is particularly important as our learning increasingly occurs outside the traditional institutions, and is therefore difficult to measure, manage and administer by the traditional institutions.
Explicit and Tacit
To further build upon the ideas Dr. Polanyi comes the important work of John Seely-Brown who compares explicit knowledge with tacit knowing and how these fall within the new approaches to learning known as Learning 2.0 or eLearning. The main idea being that a lot of learning is occurring outside of the institutions (and always has occurred outside the institutions) and new ways to recognize this learning needs to be developed. This is where open badges come in, developing ways to recognize the learning that occurs outside of institutions. Open badges aspires to create an infrastructure that will support new methods of assessment by providing an open approach to accreditation (the badge). The hope is this approach will work well for traditional and informal learning environments. Badges are not meant to replace the traditional practices of GPA, Diplomas, Degrees, etc... but to add to these existing and proven practices. It is by introducing open badges that Mozilla hopes alternative methods of assessment and accreditation will emerge. It is believed that one of the great strengths of open badges is that it will work equally well in K - 12, colleges, universities, professional development, life long learning, and informal environments.
Goals
The Mozilla Open badges Infrastructure (OBI) has a number of goals which are mostly focused on the informal and independent learner. These goals are focused on creating a badges infrastructure that will provide methods for accreditation that can both be used equally well within traditional environments and informal settings. The goals of the Open badges project is to;
- develop badges as an alternative accreditation/credentialing system
- develop badges as a micro-accreditation/micro-credentialing system
- avoid organizational and technical silos; ie badges stuck in one environment or learning system
- support learners within all settings and support badges issued from multiple issuers across the Internet
- optimize the value of those badges by making badges remixable and shareable with different audiences/sites
- develop a supporting infrastructure to standardize the process and support each learner collecting badges from multiple issuers and sharing sub-collections out across various displayers.
- create an infrastructure that is open and as decentralized as possible to give learners control and support of their entire learning 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 website 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.
II. TECHNOLOGY SPECIFICATION
- The Open Badges Infrastructure (OBI) is built in the JavaScript programming language using the software development frameworks known as node.js and express. These two frameworks used together provide a high performance server-side software development environment that is quick to develop new features and optimized for the web.
- The data that a badge file is built upon is stored in a single binary file created from two primary data elements; the JSON data-interchange embedded in a PNG graphics file. These two elements are combined and then stored in the badge earners backpack. JSON (JavaScript Object Notation) is a lightweight data-interchange format and a PNG (Portable Network Graphics) image file. The combining of these two files structures is known as baking.
- Identity management is handled by Mozilla’s Persona fka BrowserID [link: https://browserid.org/, http://identity.mozilla.com/]
III. OPEN BADGES ECOSYSTEM
Diagram
Overview
- Issuer issues a badge on their site, then prompts the Badge Earner to push the badge into their Backpack for portability.
- Issuer does this through the Issuer API which provides script to present the Badge Earner with a modal dialog that requests their consent to add the Issuer's badge(s) to their Backpack.
- Issuer can also push badges to the Mozilla Baking Service where the assertion url representing JSON blobs is embedded into PNG files
- n.b. Only necessary if Issuer wants the Earner to have the ability to store badges outside of the OBI. Otherwise Badge Baking handled through the Issuer API.
- Displayers pull unpacked badges (JSON) out of the Backpack based on privacy settings and Earner action.
- Public Badges are discoverable by Earner’s email address
- Earners 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 Verification check
IV. DEFINITIONS/KEY TERMS
- Badge
The core currency of exchange. A single credential demonstrating a skill, achievement, quality or affiliation.
- Open Badge Infrastructure (OBI)
Open infrastructure technology to support independent Badge Issuers, Display sites as well as the reference implementation of the Badge Backpack. Includes the Metadata Spec, APIs, Verification Framework and Badge Backpack.
The core authorized data store and management interface of Mozilla’s reference implementation of the Badge Backpack. Each Earner has their own Backpack where all their badge data is stored.
The definition of what makes up a badge. Each badge is a chunk of metadata that describes the badge, including badge name, image, description, criteria URL, Issuer, etc.
Embedding the assertion url (the pointer to all the metadata) into a PNG file to make a fully robust, portable badge
The interface specifications for pushing badges into the Backpack Displayer API The interface specifications for pulling badges out of the Backpack (Display sites/widgets)
- Verification API
Communication channels and framework to support badge verification (was this badge issued to this person on this date? Has it expired? etc.)
- Endorsement API
Communication channels and framework to support badge endorsement (was this badge signed? is the signature valid?)
- n.b. Endorsement employs the same signing mechanism as Badge Verification
- n.b. This is not part of Public Beta release but on the roadmap for development in 2012.
- Badge Earner
A person storing their badges within the Open Badge Infrastructure. This Earner 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. Learners are a type of Badge Earners.
- Issuer
Organization, consortium or individual who issues badges into the OBI.
- Displayer
Website run by an organization, consortium or individual, that pulls badges from the OBI and displays them for an Earner. Displayers could range from social networking sites like Facebook or career social networks, to job search/application sites to personal blogs or sites.
- Endorser
An organization, consortium or individual who “endorses” a badge by signing it with their private encryption key. Trusted third party signers may emerge.
B. Badge
The core currency of exchange. A single credential demonstrating a skill, achievement, quality or affiliation.
- Representation - Assertion url representing chunks of JSON data embedded into a PNG file
- Badge Assertion aka Badge Manifest - User identity information hashed (<algorithm>$<hash(email + salt)>) plus badge information (JSON metadata)
- Verified Badge - Badges that have an assertion URL. OBI currently supports verification of badges through hosted assertions. i.e. When issuer pushes badge to the OBI, metadata is pushed to a unique and persistent url aka assertion url. Issuer maintains Badge Assertion and displayers can ping the assertion URL to confirm verification.
- n.b. Signed assertion is on the development roadmap.
- Endorsed Badge - Badges that have been signed by a third party/endorser. The Backpack verifies the signature against the signer’s public key and if confirmed, accepts the badge as an endorsed badge. The endorsement information is represented with the badge as a layer of trust on the badge’s validity.
- n.b. On development roadmap for 2012
C. Backpack
Backpack is an authorized data storage plus a management interface for Earners; Each Earner will have their own Backpack that holds all of their badges and gives them an interface to manage, control and share their badges.
- The Backpack as well as the entire system is open source and federated. Users or Issuers can take the code and fork it.
- Earners may decide to create and host their own Backpack so that they have complete control over their badges.
- Mozilla is building a reference or default Backpack which will hold all of the badge assertions (hashed user email + badge data) for each Earner
D. Badge Earners
I. WHY PUSH BADGES INTO THE OBI
- Openness - break badges out of a single silo
- Earn and share badges from multiple Issuers
- Manage portfolio/living transcript that you control
- Display badges across multiple sites (without getting stuck in those sites)
- Discoverability: allowing employers or other stakeholders to find you based on your public badges and email
II. FUNCTIONAL FLOW: FIRST TIME EARNER
- n.b. This is based on Mozilla being the Backpack provider. As soon as there is another Backpack provider, the workflow changes: step 2 would be for earner to select the Backpack provider, one of the options being Mozilla’s Backpack.
- Earner has earned a badge from an Issuer organization/site
- Earner is prompted to push badge to Mozilla backpack.
- Earner chooses to push badge into Mozilla backpack.
- System displays popup informing Earner that in order to collect badge, they must create a badge Backpack
- System sends Earner to beta.openbadges.org
- Earner starts Backpack creation process by entering email address they want associated with the Backpack
- System displays modal popup informing user about Mozilla’s use of user’s email and the use of Mozilla’s Persona product.
- If Earner has not set up their Persona account, Earner must go through workflow; SMTP challenge (system emails user a token link they must click) to verify and tie their email to their Backpack.
- Once Persona account is established, Earner lands on authenticated state of badge Backpack.
- System presents Earner with badge earned.
- Earner may click to accept or reject badge.
- Earner accepts badge and is taken to their Backpack.
- Earner organizes badges into groups and chooses which ones to make public or not.
- Earner selects a group to push out to Displayers to be displayed
III. BACKPACK MANAGEMENT FEATURES
- Accept/reject badges
- Badges come in as private - Earner must accept the badge (changes the status)
- All badges are by default non-discoverable/private until the Earner makes them public and discoverable.
- Badges grouping
- Earner can use drag and drop feature to create groups of badges that are relevant to each user. eg. coding badges, event attendance badges, arts badges, etc.
- Manage the privacy around the badges
- Earner can choose to make a group of badges public or not
- Not doing a badge by badge privacy at this point - Mozilla needs to work through the privacy and legal considerations
- Upload badges
- Earner may upload badges directly into the backpack using the badge upload feature, however these badges must be OBI compliant badges
n.b. We are revisiting user experience around group creation. More to come here.
E. Display
- 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
- Earner will control where badges are displayed through the Backpack
- Earner can create groups of badges and share through the Backpack to Displayers that have connected via the Displayer API
- Earners can also make badges public - in that case, those badges would be discoverable by Displayers if they had the Earner’s email address
- At its most basic: if a site has an Earner's email address, they will be able to query the Backpack for all of Earner's public badges. They will get back JSON representation of the badges
F. Identity
I. OVERVIEW
- Identity is a critical part of the OBI because we need to know/recognize an Earner all across the web as they collect badges from different issuers/sites
- Identity needs to be open and decentralized
- We are utilizing verified email as identity through the use of the Mozilla product called Persona
- Mozilla.com is working on a solution called Persona, fka BrowserID, the first version of the Mozilla Verified Email Identity
- Additional info: https://browserid.org/, https://wiki.mozilla.org/Identity
- People understand the concept of an email address
- c.f. They have difficulty understanding OpenID
- Many sites already use email for login
- Even those that don't generally collect it (for resetting password)
- We don't need to retain any profile or personal information about the Earner, all we need is the email address.
II. FUNCTIONAL FLOW FOR VERIFYING IDENTITY IN BACKPACK
- User validates identity to Mozilla's Verified Email
- User creates an account with Mozilla (same as sync account)
- User asserts which email addresses he or she owns.
- User does an SMTP challenge (system emails user a token link they must click) to prove ownership
