Badges/Onboarding-Issuer: Difference between revisions

An organization or individual who issues designs and issues badges into the ecosystem. The OBI is open and supports any independent issuer who conforms to the necessary badge and issuing specifications.  

* Issuers completely determine the content and criteria behind their badge systems. They know their communities best.

* The touchpoint with the OBI occurs when earners send their badges to the designated Backpack.

* Issuers do not need to register with the OBI; they simply send badges to earner's Backpacks utilizing the Issuer Javascript API.

* Issuers must have web server capable of serving requests to the general Internet.

* Issuers must have hosting ability.

* Issuers must have email addresses for earners and must be able to email earners.  

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

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

*** 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 badges to earner backpacks through the Issuer Javascript API.  

# Have an email address for the earner.

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

OpenBadger will be a lightweight OBI compliant badge issuing platform. It will soon make creating and issuing badges easy for non-technical users.

* Representation - Assertion URL representing chunks of JSON data embedded into a PNG file.

* [https://github.com/mozilla/openbadges/wiki/Assertions 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. The OBI currently supports verification of badges through Hosted Assertions. When the issuer sends a badge, metadata is pushed to a unique and persistent URL (the assertion URL). The issuer maintains badge Assertion and displayers can ping the assertion URL to confirm verification.  

* Endorsed Badge - Badges that have been signed by a third party or 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 [https://wiki.mozilla.org/Badges/roadmap development roadmap] for 2013.

The Mozilla Backpack is an authorized data storage space and management interface for earners of Open Badges. Each earner can access their own Backpack that holds all of their badges and gives them an interface to manage and share their badges.     

* The Backpack is open source and federated. Earners or issuers can take the [https://github.com/mozilla/openbadges code] and fork it.

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

* A badge is an assertion URL representing chunks of JSON data 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.

* This is the data presented in the Assertion URL on the issuer's server.

*** image: URL for image representing the badge. Should be a square and in PNG format. Maximum size is 256kb.

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

** evidence: Earner-specific URL with information about this specific badge instance. Should contain information about how the individual earner earned the badge.

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

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

 

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.  

 

* REQUIREMENTS: To bake a badge, you must be hosting a badge Assertion on your site.  

** See the Assertions page for details: http://bit.ly/NewOpenBadgesAssertion

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

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

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

* This helps handle 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.   

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

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

# User attempts to display badge via a display site widget.  

# If values match, badge is verified and displayer displays the badge. If not, displayer should reject the badge.

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

* Many sites already use email addresses for logins, even those that don't generally collect them.

* We don't need to retain any profile or personal information about the earner; all we need is their email address.  

# User validates identity to Mozilla's Verified Email.  

# User creates an account with Mozilla (same as sync account).  

# User does an SMTP challenge (system emails user a token link they must click) to prove ownership.