== Mozilla Open Badge Infrastructure (OBI) ==
The documentation below is for general on-boarding. For an overview of badge issuing with the Mozilla OBI, read on. For more technical documentation, please see our [https://github.com/mozilla/openbadges/blob/development/docs/apis/issuer_api.md 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 skills, 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 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 to earn badges across the Web - this requires support for multiple individual 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. It is critical for this 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 carry their badges with them throughout their online life .
=== Tech Specs ===
[[Image:Tech-diagram-v3 updated.png|700px|Open Badges -- Tech-diagram-v3 updated.png]]'''<br>'''
* 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 [https://github.com/mozilla/openbadges/wiki/Issuer-API 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
communities. The issuer is responsible for defining badges, making them available to earners and handling applications for badges.
* Badge issuing can involve participants with various specific roles, such as application assessors, badge creators and administrators.
'''[https://github.com/mozilla/openbadges-specification/blob/master/Assertion/latest.md Assertion Specification]'''
Badge metadata is represented as an [https://wiki.mozilla.org/Badges/Onboarding-Issuer#
Assertion 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 a badge. This ensures that badges can be fully understood and verified no matter where they are shared.
'''[https://github.com/mozilla/openbadges/wiki/Badge-Baking Badge Baking]'''
A badge is an image combined with assertion data - badge baking embeds
an assertion into an image to produce a portable badge.
'''[https://github.com/mozilla/openbadges/wiki/Issuer-API Issuer API]'''
The Displayer API provides specifications for displaying badges beyond the Backpack.
github. com/ mozilla/ openbadges- verifier Verification]
The Verifier extracts badge data to verify earners.
=== 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 using BadgeKit.
** 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 ===
# Have an email address for the earner.
# Create and host an
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 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 structuring. Issuers can then present available badges to their earners using the BadgeKit API.'''''
=== Open Badges related Widgets created by the community ===
=== BadgeKit ===
[https://wiki.mozilla.org/Badges/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 [https://github.com/mozilla/openbadger/blob/v2.0/docs/api.md Open Badger] and [https://github.com/mozilla/aestimia Aestimia].
== Backpack ==
* The Backpack is open source and federated. Earners or issuers can take the [https://github.com/mozilla/openbadges 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 (hashed user email + badge data) for each earner.
Badge metadata is defined as an assertion, which contains multiple required and optional fields. The structure has evolved over time - see the [https://github.com/mozilla/openbadges-specification/blob/master/Assertion/latest.md assertion specification] for complete details.
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.
== Badge Images and Baking ==
Each badge is a JSON blob of metadata embedded in a PNG file. * This allows the badge to be more easily portable - an actual 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: https://github.com/mozilla/openbadges-specification/blob/master/Assertion/latest.md
** 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 unpacked for the Displayer API so that Displayers will just have the raw data to work with on their end.
* 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 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 ==
* 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 to implement time-sensitive badges , for example in continuous professional development scenarios.* The OBI provides the channel for this verification to happen through the Backpack but must communicate 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 by displayers . Displayers should not display a badge that cannot be verified.
=== Verification Method ===
* The OBI currently supports verification of badges through Hosted Assertions. When an issuer sends a badge using the OBI, metadata is pushed to a unique and persistent URL (the Assertion URL). The issuer maintains the badge Assertion and displayers can ping the assertion URL to verify the badge.* * A displayer puts the earner’s email address 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 and can be claimed. * * There is a drawback of overhead for the issuer to maintain unique and persistent URLs for each badge. * With the V1. 0 release we support Signed Assertions, allowing for signing of a badge assertion with a private key and hosting a public key at a public URL. * * This has the benefit of creating less overhead for the issuer who just need to host the public key. * Looking forward, we will try to support DNSSEC for public key discovery. * Unverified Badge handling ** If a badge is passed through by an issuer and the signature is invalid, it is rejected. ** If a badge is verified initially but it becomes unverified in the future, the earner is notified.
=== Functional Flow ===
# Badge (
within it, its 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 (‘email@example.com’ + 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 of badges is where a significant part of the value of this approach lies. 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 where badges are displayed through the Backpack.
* Each earner can create collections of badges and share with displayers that have connected to the [https://github.com/mozilla/openbadges/wiki/Displayer-API Displayer API].
* Earners can also make badges public; those badges
would be discoverable by displayers if they had the earner’s email address. * If a site has an earner's email address, they will be able to query that person's Backpack for all of that earner's public badges. They will get back JSON representation of the badges.
== Identity ==
* Identity is a critical component because we need to recognize earners as they
earn 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.