Jump to: navigation, search


1,951 bytes added, 17:59, 21 March 2014
More general updating/ restructuring.
== Mozilla Open Badge Infrastructure (OBI) ==
NOTE: The documentation below is for For a general on-boarding. For an overview of introduction to badge issuing with the Mozilla OBI, read on. For more technical documentation, please see our [ github pages].
=== Background ===
==== Why Are We Doing This? ====
Learning happens everywhere. Yet it's often difficult to be recognized for skills and achievements that are gained outside of school. Mozilla's Open Badges project is working to solve that problem by making it easy for anyone anywhere to issue, earn, and display badges. The results: broad recognition of 21st century skillsand experiences, unlocking of career and educational opportunities, and learners everywhere being able to level up in their lives and work.
==== Goals ====
* Help badges expand beyond siloed environments to be broadly shareable;
* Truly support earners learning everywhere;
* Optimize the value of those badges these representations by allowing badges to be remixable and shareable with different audiences;
* Develop a supporting infrastructure to standardize the process and support each earner;
* Create an infrastructure that is open and as decentralized as possible to give earners control and support of the entire ecosystem;
==== Description ====
The Open Badges framework is designed to enable people make badging flexible enough to earn badges across represent the Web - this full range of learning and experience in online and offline life. This requires support for multiple individual , potentially significantly varied, badge issuers. Empowering earners to use their badges as legitimate credentials also requires support for sharing of badges across many display sites. The framework potentially allows the earner to both collect and display badges in multiple contexts, tied to a single identity.  Earners can share badges across such varied online environments as personal blogs and social networking channels, tying a variety of achievements to a single identity. It is critical for this the infrastructure to be open, to give earners control over how they represent their own learning and experiences, to allow anyone to issue badges, and for each earner to be able to carry their badges with them throughout their online life. The participants in a badging system are characterized using a few broad groups:* Issuers - they create badges, make them available to earners and award them.* Earners - they apply for badges and decide where to display them.* Displayers - they display badges earned by particular earners (this also involves verifying badges). You will see these roles described throughout the material you read on Open Badges. This page is aimed at providing an overview of badging for ''issuers'', with an introduction to the technical aspects of issuing. Last but not least, although not involved directly in badging systems, let's not forget this group of people:* Consumers - they include anyone looking at a badge (or badges) earned** examples include potential employers, college admin and peers.
=== Tech Specs ===
[[Image:Tech-diagram-v3 updated.png|700px|Open Badges -- Tech-diagram-v3 updated.png]]'''<br>'''
Here's an overview of how badging works:
* An issuer makes a badge available to their community of earners on their website. When awarded the badge, an earner sends it to their Backpack.
** The badge becomes portable through the [ Issuer API] script, presenting the earner with a modal dialog that requests their consent to add the badge to their Backpack.
Organization or individual who issues Open Badges to their communitiescommunity. The issuer is responsible for defining badges, making them available to earners and handling applications for badgesthem.
* Badge issuing can involve participants with various specific roles, such as application assessors, badge creators and administrators.
'''[ Assertion Specification]'''
Badge metadata is represented as an [ Metadata assertion]. The assertion specification defines the information within a badge. An assertion includes multiple items of data, such as: badge name and description, issuer, date, criteria URL, evidence URL and badge image URL. The assertion should carry all the information needed to understand process a badge. This ensures that badges can be fully understood and verified no matter where they are shared.
'''[ Badge Baking]'''
A badge is an image combined with assertion data - badge baking embeds an assertion data into an image to produce a portable badge.
'''[ Issuer API]'''
The Displayer API provides specifications for displaying badges beyond the Backpack.
'''[ Issuer#Verification Verification]
The Verifier extracts Displayers are responsible for verifying badges, i.e. checking that a badge data is valid and was issued to verify earnersthe person claiming it.
=== Background ===
* Issuers determine the badging approach that will work best for their communities.
* Touchpoints with the OBI occur through various interfaces, including sending badges to Backpacks and optionally using BadgeKit.
* Issuers do not need to register with the OBI - they simply utilize the JavaScript APIs.
** Email addresses for earners (and the ability to email them).
** Badges structured in the format that the assertion expects - when using BadgeKit this structuring is automated.
** Earners must be registered with the backpack implementation that the issuer is trying to send their badges to. ''In the future, the issuer will need to ask the earner which backpack they want to push badges their to and honor that request.''
* For verification:
** For Hosted Assertions - issuers must maintain a server with the Badge Assertion information (at the unique badge URL) to verify each badge.
=== Badge Creation Flow ===
Issuers need to:
# Have an email address for the earner.
# Create and host an Assertion assertion on site.
# Create and host the badge PNG; this is a single PNG for all badges, not a single physical PNG per issued badge.
# Integrate your site with the Backpack via the Issuer API
''The Issuer API is a script that can be dropped into any badge issuer's website to provide a way for earners to add an issuer's badges to their Mozilla Backpack (or federated backpacks). There's no need to bake the badges independently as the API takes care of this.''
'''''The badge creation flow varies significantly for issuers using [[Badges/badgekit|BadgeKit]]. Issuer admins can design and define the data for a badge within the BadgeKit Web app, with BadgeKit handling badge data metadata structuring. Issuers can then present available badges to their earners using the BadgeKit API.'''''
=== Open Badges related Widgets created by the community ===
=== BadgeKit ===
[ BadgeKit] builds on a range of tools which have been under continual development for some time , through projects such as Chicago Summer of Learning. These tools include [ Open Badger] and [ Aestimia].
== Backpack ==
* The Backpack 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 has built a reference or default Backpack (the "Mozilla Backpack") which holds all of the badge Assertions assertions (hashed user email + badge data) for each earner.
== Assertion Metadata ==
Badge metadata is defined as an assertion, which contains multiple required and optional fields. The structure has evolved over time - see the [ assertion specification] for complete details.
Issuers can put a reasonable amount of extra material into the a badge, but that material must be static - once the badge is issued, any change to that the 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.
== Badge Images and Baking ==
* Each A baked badge is a JSON blob of metadata embedded in a PNG file. * This allows the badge to be more easily portable - an actual a collection of information that can be emailed around and portable while still , carrying its details with it. * Ultimately, this is important for decentralization of the system and will allow earners to have more control over where their badges live.
=== Baking Service ===
* To bake a badge, you must host a badge Assertion on your site. ** See the Assertions page for details: [] on your site.
** The system is designed to:
*** avoid SPAMing the earner with unwanted badges, and
* Mozilla provides 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 are unpacked for the Displayer API so that Displayers will displayers just have the raw data to work with on their end.
''If you are building a new system, we strongly recommend using the JavaScript Issuer API or BadgeKit for awarding badges. The tools and APIs take care of the badge baking.''
* Image must be a PNG.
* Images should be square and not exceed 256kb. They should have dimensions not smaller that 90 x 90.
* Image is provided as a URL to the image on the issuer server in , stored within the metadata.
* Mozilla will cache the image in at least two sizes.
* When a badge is displayed, it will be loaded from the Mozilla cache to avoid extra burden on the issuer servers. This also helps if the issuer is not available or the link is broken.
== Verification ==
Badge verification involves checking that a badge was issued to the person displaying it, using their email address. Verification affects both issuers and displayers.
* To avoid gaming and duplication, the OBI is built to support badge verification.
* This is essential to allow earners to prove the authenticity and validity of their badges. Badges can also have expiry dates, allowing issuer organizations to implement time-sensitive issue badges, for example in continuous professional development scenariosskills which are only valid for a set period of time.* The OBI provides the channel for this verification to happen through the Backpack but must communicate , by communicating with the issuer.
* The issuer must be online to verify badges. (We are exploring a cache to cover verification for a set amount of time).
* Most verification will be done Verification is typically carried out by displayers. Displayers , who should not display a badge that cannot be verified.
=== Verification Method ===
* The OBI currently supports verification of badges through Hosted Assertionshosted and signed assertions. When an issuer sends The assertion data for a badge using contains verification information. For hosted assertions, this includes a URL field representing the OBIassertion hosted on the issuer's server. For signed assertions, metadata it includes a link to the issuer's public key. Displayers can utilize this data to verify badge earners. The verification process is pushed to as follows: '''''For hosted assertions''''':# Displayer carries out a unique and persistent GET request on the verification URL (from the Assertion URL)assertion. The issuer maintains #* If the response is not 200 OK or if the badge Assertion and displayers can ping data at the assertion URL to verify is not structurally valid, the badgeis treated as invalid.# Displayer analyses content of data at assertion verification URL, which includes recipient email address.#** A displayer puts Verification can now be achieved by comparing the earner’s email address through a salted hash function and sees if it matches with value for the recipient (according to the verification data) to the salted hash value indicated for the recipient in email of the person claiming the badge metadata. If values match# The displayer can optionally check further information in the verification data, including an expiry date if there is one.  '''''For signed assertions''''':# Displayer unpacks JWS object specified in the badge belongs to the earner and can be claimedassertion verification fields. #** There is a drawback of overhead for If the issuer data fails to maintain unique and persistent URLs for each badgeparse as JSON data, verification fails.* With # Displayer extracts the V1verify.0 release we support Signed Assertionsurl property from the JSON, allowing for signing of carries out a badge assertion with a private key GET request on it and hosting a stores the public key at a public URL. #** This has If the benefit of creating less overhead for HTTP status is not 200 OK, verification fails.# Displayer uses the issuer who just need public key to host perform JWS verification on the JWS object - if this fails, the public keybadge is considered invalid.* Looking forward, we will try to support DNSSEC for public key discovery# Displayer retrieves the revocation list and checks that the badge ID is not included. * Unverified Badge handling** If a badge is passed through by an issuer For more about assertions and verification, see the signature is invalid, it is rejected[ Specification]. ** If a ''Note: for baked badges, verification also involves extracting the assertion URL from the badge is verified initially but it becomes unverified in image - see the future, the earner is notified[ Verifier] for more on this. ''
=== Functional Flow ===
# Badge (within it, its including assertion) exists in the Backpack.
# User attempts to display badge via a display site widget.
# Display site takes the earner’s email and puts it through a salted hash function.
## * eg. hash (‘’ + salt)
# Display site compares the resulting value with the value indicated for the recipient in the badge metadata.
# If values match, badge is verified and displayer displays the badge. If not, displayer should reject the badge.
== Displayers ==
* Display Displayers are key to the value of Open Badges for earners. The OBI is designed to support display of badges is where acquired in various different types of context, letting earners paint a significant part more detailed, complete picture of the value of this approach liestheir skills and experiences.  * Badges are not siloed or limited to one site but can be combined with badges from multiple issuers and then shared for different audiences and purposes. * Each earner will control controls where their badges are displayed through the Backpack.
* Each earner can create collections of badges and share with displayers that have connected to the [ Displayer API].
* Earners can also make badges public; those badges would be are discoverable by displayers if they had have the earner’s earner's email address. * If a site has an earner's email address, they will be able to can query that person's Backpack for all of that earner's public badges. They will get back The response is a JSON representation of the badges.
== Identity ==
* Identity is a critical component because we need to recognize earners as they earn collect badges from different issuers.
* It's important to us that identity be open and decentralized.
* We are utilizing verified email as a form of identity through the Mozilla product Persona.

Navigation menu