Badges/Onboarding-Issuer: Difference between revisions

NOTE: 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].

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.

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

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.

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

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-verifier Verification]

The Verifier extracts badge data to verify earners.

* Touchpoints with the OBI occur through various interfaces, including sending badges to Backpacks and 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 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 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.'''''

[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 (hashed user email + badge data) for each earner.

== Assertion ==

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.  

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

* 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

* 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 is provided as a URL to the image on the issuer server in 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 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.   

* Most verification will be done by displayers. Displayers should not display a badge that cannot be verified.

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

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

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

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

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

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