244
edits
Changes
Created page with "== A. Mozilla Open Badge Infrastructure (OBI) == === I. BACKGROUND === ==== Why Are We Doing This? ==== * Learners are learning everywhere -- but most of that learning doe..."
== A. Mozilla Open Badge Infrastructure (OBI) ==
=== I. BACKGROUND ===
==== Why Are We Doing This? ====
* Learners are learning everywhere -- but most of that learning doesn't "count"
* Skills assessment and communication is limited in current system, e.g. GPA, GED, Bachelor or Master degrees, static resume
* There are few alternatives to the current accreditation/credentialing system
* Learning doesn’t happen simply between K - 12 and university; learning happens over the course of a lifetime and frequently in informal settings
==== Goals ====
* Develop badges as an alternative accreditation/credentialing system
* Develop badges as a micro-accreditation/micro-credentialing system
* Avoid silos; ie badges stuck in one learning system
* Truly support learners learning everywhere == Support badges issued from multiple issuers across the Web
* Optimize the value of those badges == Make 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 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 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. 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’s Persona (fka BrowserID) [link: https://browserid.org/, http://identity.mozilla.com/]
=== III. OPEN BADGES ECOSYSTEM ===
==== Diagram =====
UPDATED DIAGRAM IN DROPBOX: Open Badges project > Other > Technology overview > tech-diagram-v2
==== 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 JSON blobs are 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.
** 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.
** Metadata Spec - 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.
** Badge Baking - Embedding the JSON blob into a PNG file to make a fully robust, portable badge (with all of the metadata embedded)
** Issuer API - 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.
* Earners/Partners
** 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. Issuer ==
An organization, consortium, group 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.
=== I. BACKGROUND ===
* 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 edges - 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 earner
* Issuers do not need to register with the OBI - they simply push badges into earner Backpacks utilizing the Issuer Javascript API.
=== II. REQUIREMENTS ===
* Issuers must have web server capable of serving requests to the general internet
* Issuers must have hosting ability
* Issuers must have ability to make a POST request from their server backend and read a JSON response.
* Issuers must have email addresses for Earners and must be able to email Earners
* Issuers must have badges (or be able to convert their badges) into the format (metadata spec) that the Assertion expects.
* Earners must be registered with whatever Backpack the Issuer is trying to push badges to, or (for later versions) the Issuer must ask Earner which Backpack they want to push badges to and honor that request
* For verification:
** If doing Hosted Assertions (currently available)
*** Issuers must maintain a server with the Badge Assertion information (at the unique badge URL) to verify each badge
** If doing Signed Assertions (on development roadmap)
*** Issuers must generate public/private key pair and maintain the hosted public key
*** Issuers must sign the badges themselves; sign the whole package and push badge to Earner Backpacks through the Issuer Javascript API.
=== III. BADGE CREATION FLOW ===
0. Have an email address for the Earner
1. Create and host an Assertion on your site
2. Create and host the badge PNG; this is a single PNG for all badges, not a single physical PNG per issued badge.
3. Integrate your site with the Backpack via the Issuer API
4. Issuer asks Earner how they want the badge: sent to the OBI or delivered via email
5. Issuer honors Earner’s choice and sends to the OBI and/or to the Earner directly via email
n.b. The Issuer API is a script that can be dropped-in to any Badge Issuer's website to provide a way for Earners to add an Issuer's badges to their Backpack. There's no need to bake the badges yourself. The API takes care of it for you.
=== IV. OPEN BADGES Related Widgets created by the community ===
* https://github.com/lmorchard/django-badger -- Issuing app for Django
* https://github.com/PRX/badges_engine -- Rails Engine for issuing.
* https://github.com/openmichigan/open_badges -- Drupal module for managing/issuing badges
n.b. Updated list can be found here: https://github.com/mozilla/openbadges/wiki/Open-Badges-related-widgets
== C. Badge ==
The core currency of exchange. A single credential demonstrating a skill, achievement, quality or affiliation.
* Representation - Chunks of JSON data embedded into a PNG file
* Badge Assertion aka Badge Manifest - Earner identity information (<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
== D. 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. Earners 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
== E. Metadata Spec ==
=== I. OVERVIEW ===
* A badge is a JSON blob of metadata embedded into a PNG file.
* The metadata should carry all the information needed to understand a badge. This ensures that badges can be fully understood and verified no matter where they are shared or used.
* This is the data presented in the Assertion URL on the Issuer's server
=== II. FIELDS ===
* Required
** recipient: Salted hash of the email address for the earner receiving the badge.
** salt: The salt used in the hash construction of the recipient’s email address.
** badge: The structure describing the badge.
*** version: The version of the badge
*** name: Human-readable name of the badge being issued. Maximum of 128 characters.
*** image: URL for image representing the badge. Should be a square and in PNG format. Maximum size of 256kb.
*** description: Description of the badge being issued. Maximum of 128 characters.
*** criteria: URL describing the badge and criteria for earning the badge (Not the specific instance of the badge).
*** issuer: Information about the Issuer:
**** origin: Origin of the Issuer. This is the <protocol>://<host>:<port>. Must match the origin of the Hosted Assertion (and in the future, the origin of the public key).
**** name : Human-readable name of the issuing agent.
* Optional
** evidence: Earner-specific URL with information about this specific badge instance. Should contain information about how the specific Earer earned the badge.
** expires: Date when the badge expires. If omitted, the badge never expires.
*** The badge is not removed from the Earner’s Backpack after the expiration date – there will be some visual/technical indicator that the badge is expired and needs to be re-upped. Must be formatted "YYYY-MM-DD" or a unix timestamp
** issued_on: Date when badge was issued. If omitted, the issue date will be set to the date the badge was pushed to the Backpack. Must be formatted "YYYY-MM-DD" or a unix timestamp
** issuer: Information about the Issuer:
*** org: (OPTIONAL) Organization for which the badge is being issued. An example is if a scout badge is being issued, the "name" of the Issuer could be "Boy Scouts" and the "org" could be "Troop #218"
*** contact: (OPTIONAL) A human-monitored email address associated with the Issuer.
* n.b. We've discussed having an additional field that is customizable by the Earner - so that the Earner could add a personal evidence URL, or could add additional information or context to the badge. This would NOT be something that the Issuer would include in the Badge Assertion (so it is not listed above) and would most likely be managed by the Earner through the Backpack.
* n.b. Issuers can put a reasonable amount of extra material into the badge, but that material must be static -- once the badge is issued, any change to that information must not change. This is to prevent someone from issuing one badge, then sneakily changing it later to another badge unbeknownst to the Earner. There currently isn't a method for updating the information received in the badge, though it's not off the table.
== F. PNG Files / Badge Baking Service ==
=== I. BACKGROUND ===
* Each badge is 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 Earners have more control over where their badges live
=== II. BETA: BAKING SERVICE ===
* For beta, Mozilla will be providing a 'baking' service to package the JSON into a PNG file
REQUIREMENTS: To bake a badge, you must be hosting a Badge Assertion on your site.
See the Assertions page for details: https://github.com/mozilla/openbadges/wiki/Assertions
Issuers will still send the Badge Assertion to Mozilla, but instead of sending it directly to the Backpack, they will now send it to the Mozilla Baking Service. Then Mozilla will package it into a PNG and deliver back to the Issuer who can then send to the Earner
The purpose of this is:
A) to avoid SPAMing the Earner with unwanted badges (which we can control in beta) and
B) to give the Earners ultimate control over where the badges go.
n.b. If you are building a new system, we strongly recommend using the Javascript Issuer API for awarding badges. The API takes care of the badge baking for the Issuer.
Mozilla will provide the 'tools' for unpacking the PNG file through the OBI
PNG files will be unpacked in the Backpack where each Earner 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.
III. BADGE IMAGE STANDARDS
Image must be a PNG (for Beta).
Potentially: In later iterations, we can convert to a PNG
Images should be square and not exceed 256kb
Looking at standardizing dimensions to 90 x 90
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
G. Verification
I. OVERVIEW
To avoid gaming and duplication, the OBI is built to support badge verification.
This handles the questions of "Did this Issuer issue this badge to this Earner on this date? Is this badge still valid or has it expired?"
The OBI provides the channel for this verification to happen through the Backpack, but must communicate with the Issuer.
Issuer must be online to verify badges. (we are exploring a cache to cover verification for x amount of time)
Most verification will be done by the Displayers. Displayers should not display a badge that cannot be verified.
II. VERIFICATION METHOD
OBI currently supports verification of badges through Hosted Assertions. i.e. When Issuer pushes a badge to the OBI, metadata is pushed to a unique and persistent url aka assertion url. Issuer maintains the Badge Assertion and Displayers can ping the assertion URL to verify the badge.
Diplayer puts the Earner’s email through a salted hash function and sees if it matches with the hash value indicated for the recipient in the badge metadata. If values match, the badge belongs to the Earner that claims it, if not, it is being spoofed.
Cons: Overhead for Issuer to maintain unique and persistent url for each badge.
In the future we will support Signed Assertions, which will mean signing a badge assertion with your private key and hosting a public key at a well known, public URL.
Pros: Less overhead for Issuer, just need to host public key
Further down the road, we will probably try to support DNSSEC for public key discovery.
Unverified Badge handling
If badge is passed through by an Issuer and the signature (when we support this method of verification) is invalid, OBI rejects it.
If badge is verified initially but somewhere down the line it becomes unverified, OBI notifies user. [Needs to be worked out more.]
III. FUNCTIONAL FLOW
0. Badge (within it, its assertion) exists in the Backpack
1. User attempts to display badge via a display site widget
2. Display site takes the earner’s email and puts it through a salted hash function.
eg. hash (‘hipjoe@example.com’ + salt)
3. Display site compares the resulting value with the value indicated for the recipient in the badge metadata.
4. If values match, badge is verified and Displayer displays the badge. If not, Displayer should reject the badge.
H. Displayers
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
I. 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
0. User validates identity to Mozilla's Verified Email
1. User creates an account with Mozilla (same as sync account)
2. User asserts which email addresses he or she owns.
3. User does an SMTP challenge (system emails user a token link they must click) to prove ownership
J. Development History, Milestone, and Roadmap
Prototype - A prototype of the badge Infrastructure was built at the Mozilla Drumbeat Festival in Barcelona, November 2010. 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 was launched in late July 2011. The Alpha included 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 were pushed into the Alpha Infrastructure with support for displaying on the user’s P2PU profile.
Developer Preview (Beta1) - The first Beta version of the Infrastructure launched mid September 2011. The Beta was a fully functioning (critical feature complete) Infrastructure, including all Backpack technology. Initial Issuers were plugging in following the launch. We did a closed beta launch to work closely with an initial group of issuers to fine tune the technology and ensure that we have data and experience to evaluate the Infrastructure.
Public Beta - Public Beta included more features including the Displayer API and was launched in early April 2012.
1.0 Public Spec - In Q3 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
=== I. BACKGROUND ===
==== Why Are We Doing This? ====
* Learners are learning everywhere -- but most of that learning doesn't "count"
* Skills assessment and communication is limited in current system, e.g. GPA, GED, Bachelor or Master degrees, static resume
* There are few alternatives to the current accreditation/credentialing system
* Learning doesn’t happen simply between K - 12 and university; learning happens over the course of a lifetime and frequently in informal settings
==== Goals ====
* Develop badges as an alternative accreditation/credentialing system
* Develop badges as a micro-accreditation/micro-credentialing system
* Avoid silos; ie badges stuck in one learning system
* Truly support learners learning everywhere == Support badges issued from multiple issuers across the Web
* Optimize the value of those badges == Make 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 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 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. 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’s Persona (fka BrowserID) [link: https://browserid.org/, http://identity.mozilla.com/]
=== III. OPEN BADGES ECOSYSTEM ===
==== Diagram =====
UPDATED DIAGRAM IN DROPBOX: Open Badges project > Other > Technology overview > tech-diagram-v2
==== 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 JSON blobs are 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.
** 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.
** Metadata Spec - 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.
** Badge Baking - Embedding the JSON blob into a PNG file to make a fully robust, portable badge (with all of the metadata embedded)
** Issuer API - 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.
* Earners/Partners
** 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. Issuer ==
An organization, consortium, group 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.
=== I. BACKGROUND ===
* 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 edges - 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 earner
* Issuers do not need to register with the OBI - they simply push badges into earner Backpacks utilizing the Issuer Javascript API.
=== II. REQUIREMENTS ===
* Issuers must have web server capable of serving requests to the general internet
* Issuers must have hosting ability
* Issuers must have ability to make a POST request from their server backend and read a JSON response.
* Issuers must have email addresses for Earners and must be able to email Earners
* Issuers must have badges (or be able to convert their badges) into the format (metadata spec) that the Assertion expects.
* Earners must be registered with whatever Backpack the Issuer is trying to push badges to, or (for later versions) the Issuer must ask Earner which Backpack they want to push badges to and honor that request
* For verification:
** If doing Hosted Assertions (currently available)
*** Issuers must maintain a server with the Badge Assertion information (at the unique badge URL) to verify each badge
** If doing Signed Assertions (on development roadmap)
*** Issuers must generate public/private key pair and maintain the hosted public key
*** Issuers must sign the badges themselves; sign the whole package and push badge to Earner Backpacks through the Issuer Javascript API.
=== III. BADGE CREATION FLOW ===
0. Have an email address for the Earner
1. Create and host an Assertion on your site
2. Create and host the badge PNG; this is a single PNG for all badges, not a single physical PNG per issued badge.
3. Integrate your site with the Backpack via the Issuer API
4. Issuer asks Earner how they want the badge: sent to the OBI or delivered via email
5. Issuer honors Earner’s choice and sends to the OBI and/or to the Earner directly via email
n.b. The Issuer API is a script that can be dropped-in to any Badge Issuer's website to provide a way for Earners to add an Issuer's badges to their Backpack. There's no need to bake the badges yourself. The API takes care of it for you.
=== IV. OPEN BADGES Related Widgets created by the community ===
* https://github.com/lmorchard/django-badger -- Issuing app for Django
* https://github.com/PRX/badges_engine -- Rails Engine for issuing.
* https://github.com/openmichigan/open_badges -- Drupal module for managing/issuing badges
n.b. Updated list can be found here: https://github.com/mozilla/openbadges/wiki/Open-Badges-related-widgets
== C. Badge ==
The core currency of exchange. A single credential demonstrating a skill, achievement, quality or affiliation.
* Representation - Chunks of JSON data embedded into a PNG file
* Badge Assertion aka Badge Manifest - Earner identity information (<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
== D. 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. Earners 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
== E. Metadata Spec ==
=== I. OVERVIEW ===
* A badge is a JSON blob of metadata embedded into a PNG file.
* The metadata should carry all the information needed to understand a badge. This ensures that badges can be fully understood and verified no matter where they are shared or used.
* This is the data presented in the Assertion URL on the Issuer's server
=== II. FIELDS ===
* Required
** recipient: Salted hash of the email address for the earner receiving the badge.
** salt: The salt used in the hash construction of the recipient’s email address.
** badge: The structure describing the badge.
*** version: The version of the badge
*** name: Human-readable name of the badge being issued. Maximum of 128 characters.
*** image: URL for image representing the badge. Should be a square and in PNG format. Maximum size of 256kb.
*** description: Description of the badge being issued. Maximum of 128 characters.
*** criteria: URL describing the badge and criteria for earning the badge (Not the specific instance of the badge).
*** issuer: Information about the Issuer:
**** origin: Origin of the Issuer. This is the <protocol>://<host>:<port>. Must match the origin of the Hosted Assertion (and in the future, the origin of the public key).
**** name : Human-readable name of the issuing agent.
* Optional
** evidence: Earner-specific URL with information about this specific badge instance. Should contain information about how the specific Earer earned the badge.
** expires: Date when the badge expires. If omitted, the badge never expires.
*** The badge is not removed from the Earner’s Backpack after the expiration date – there will be some visual/technical indicator that the badge is expired and needs to be re-upped. Must be formatted "YYYY-MM-DD" or a unix timestamp
** issued_on: Date when badge was issued. If omitted, the issue date will be set to the date the badge was pushed to the Backpack. Must be formatted "YYYY-MM-DD" or a unix timestamp
** issuer: Information about the Issuer:
*** org: (OPTIONAL) Organization for which the badge is being issued. An example is if a scout badge is being issued, the "name" of the Issuer could be "Boy Scouts" and the "org" could be "Troop #218"
*** contact: (OPTIONAL) A human-monitored email address associated with the Issuer.
* n.b. We've discussed having an additional field that is customizable by the Earner - so that the Earner could add a personal evidence URL, or could add additional information or context to the badge. This would NOT be something that the Issuer would include in the Badge Assertion (so it is not listed above) and would most likely be managed by the Earner through the Backpack.
* n.b. Issuers can put a reasonable amount of extra material into the badge, but that material must be static -- once the badge is issued, any change to that information must not change. This is to prevent someone from issuing one badge, then sneakily changing it later to another badge unbeknownst to the Earner. There currently isn't a method for updating the information received in the badge, though it's not off the table.
== F. PNG Files / Badge Baking Service ==
=== I. BACKGROUND ===
* Each badge is 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 Earners have more control over where their badges live
=== II. BETA: BAKING SERVICE ===
* For beta, Mozilla will be providing a 'baking' service to package the JSON into a PNG file
REQUIREMENTS: To bake a badge, you must be hosting a Badge Assertion on your site.
See the Assertions page for details: https://github.com/mozilla/openbadges/wiki/Assertions
Issuers will still send the Badge Assertion to Mozilla, but instead of sending it directly to the Backpack, they will now send it to the Mozilla Baking Service. Then Mozilla will package it into a PNG and deliver back to the Issuer who can then send to the Earner
The purpose of this is:
A) to avoid SPAMing the Earner with unwanted badges (which we can control in beta) and
B) to give the Earners ultimate control over where the badges go.
n.b. If you are building a new system, we strongly recommend using the Javascript Issuer API for awarding badges. The API takes care of the badge baking for the Issuer.
Mozilla will provide the 'tools' for unpacking the PNG file through the OBI
PNG files will be unpacked in the Backpack where each Earner 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.
III. BADGE IMAGE STANDARDS
Image must be a PNG (for Beta).
Potentially: In later iterations, we can convert to a PNG
Images should be square and not exceed 256kb
Looking at standardizing dimensions to 90 x 90
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
G. Verification
I. OVERVIEW
To avoid gaming and duplication, the OBI is built to support badge verification.
This handles the questions of "Did this Issuer issue this badge to this Earner on this date? Is this badge still valid or has it expired?"
The OBI provides the channel for this verification to happen through the Backpack, but must communicate with the Issuer.
Issuer must be online to verify badges. (we are exploring a cache to cover verification for x amount of time)
Most verification will be done by the Displayers. Displayers should not display a badge that cannot be verified.
II. VERIFICATION METHOD
OBI currently supports verification of badges through Hosted Assertions. i.e. When Issuer pushes a badge to the OBI, metadata is pushed to a unique and persistent url aka assertion url. Issuer maintains the Badge Assertion and Displayers can ping the assertion URL to verify the badge.
Diplayer puts the Earner’s email through a salted hash function and sees if it matches with the hash value indicated for the recipient in the badge metadata. If values match, the badge belongs to the Earner that claims it, if not, it is being spoofed.
Cons: Overhead for Issuer to maintain unique and persistent url for each badge.
In the future we will support Signed Assertions, which will mean signing a badge assertion with your private key and hosting a public key at a well known, public URL.
Pros: Less overhead for Issuer, just need to host public key
Further down the road, we will probably try to support DNSSEC for public key discovery.
Unverified Badge handling
If badge is passed through by an Issuer and the signature (when we support this method of verification) is invalid, OBI rejects it.
If badge is verified initially but somewhere down the line it becomes unverified, OBI notifies user. [Needs to be worked out more.]
III. FUNCTIONAL FLOW
0. Badge (within it, its assertion) exists in the Backpack
1. User attempts to display badge via a display site widget
2. Display site takes the earner’s email and puts it through a salted hash function.
eg. hash (‘hipjoe@example.com’ + salt)
3. Display site compares the resulting value with the value indicated for the recipient in the badge metadata.
4. If values match, badge is verified and Displayer displays the badge. If not, Displayer should reject the badge.
H. Displayers
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
I. 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
0. User validates identity to Mozilla's Verified Email
1. User creates an account with Mozilla (same as sync account)
2. User asserts which email addresses he or she owns.
3. User does an SMTP challenge (system emails user a token link they must click) to prove ownership
J. Development History, Milestone, and Roadmap
Prototype - A prototype of the badge Infrastructure was built at the Mozilla Drumbeat Festival in Barcelona, November 2010. 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 was launched in late July 2011. The Alpha included 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 were pushed into the Alpha Infrastructure with support for displaying on the user’s P2PU profile.
Developer Preview (Beta1) - The first Beta version of the Infrastructure launched mid September 2011. The Beta was a fully functioning (critical feature complete) Infrastructure, including all Backpack technology. Initial Issuers were plugging in following the launch. We did a closed beta launch to work closely with an initial group of issuers to fine tune the technology and ensure that we have data and experience to evaluate the Infrastructure.
Public Beta - Public Beta included more features including the Displayer API and was launched in early April 2012.
1.0 Public Spec - In Q3 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
