Changes

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 [https://github.com/mozilla/openbadges/blob/development/docs/apis/issuer_api.md github pages].

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.

* Optimize the value of those badges these representations by allowing badges to be remixable and shareable with different audiences;

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.

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 metadata is represented as an [https://wiki.mozilla.org/Badges/Onboarding-Issuer#Assertion 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.

A badge is an image combined with assertion data - badge baking embeds an assertion data into an image to produce a portable badge.

'''[https://githubwiki.commozilla.org/mozillaBadges/openbadgesOnboarding-verifier 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.

* Touchpoints with the OBI occur through various interfaces, including sending badges to Backpacks and optionally using BadgeKit.

** 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.''

# Create and host an Assertion assertion on site.

''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.'''''

[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].

* 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 ==

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.

* 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.

* 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.mdassertion] on your site.

* 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.

* Image is provided as a URL to the image on the issuer server in , stored within the metadata.

* 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.

* Most verification will be done Verification is typically carried out by displayers. Displayers , who should not display a badge that cannot be verified.

* 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[https://github.com/mozilla/openbadges-specification/blob/master/Assertion/latest.md 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[https://github.com/mozilla/openbadges-verifier Verifier] for more on this. ''

# Badge (within it, its including assertion) exists in the Backpack.

## * eg. hash (‘hipjoe@example.com’ + salt)

* 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.

* 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 is a critical component because we need to recognize earners as they earn collect badges from different issuers.