Changes

==== Diagram =====

* REQUIREMENTS: To bake a badge, you must be hosting a Badge Assertion on your site. ** See the Assertions page for details: https://github.com/mozilla/openbadges/wiki/Assertions* 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 ** The purpose of this is:*** A) to avoid SPAMing the Earner with unwanted badges (which we can control in beta) and *** B) to give the Earners ultimate control over where the badges go. ** n.b. If you are building a new system, we strongly recommend using the Javascript Issuer API for awarding badges. The API takes care of the badge baking for the Issuer. * Mozilla will provide 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.

=== III. BADGE IMAGE STANDARDS===* Image must be a PNG (for Beta). ** Potentially: In later iterations, we can convert to a PNG * Images should be square and not exceed 256kb* Looking at standardizing dimensions to 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 2 sizes * When a badge is displayed, it will be loaded from the Mozilla cache to avoid extra burden on the Issuer servers, also in case the Issuer is not available or link is broken

== G. Verification==

=== I. OVERVIEW === * To avoid gaming and duplication, the OBI is built to support badge verification. * This handles 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. * Issuer must be online to verify badges. (we are exploring a cache to cover verification for x amount of time) * Most verification will be done by the Displayers. Displayers should not display a badge that cannot be verified.

=== II. VERIFICATION METHOD=== * OBI currently supports verification of badges through Hosted Assertions. i.e. When Issuer pushes a badge to the OBI, metadata is pushed to a unique and persistent url aka assertion url. Issuer maintains the Badge Assertion and Displayers can ping the assertion URL to verify the badge.Diplayer ** Displayer puts the Earner’s email 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 that claims it, if not, it is being spoofed. ** Cons: Overhead for Issuer to maintain unique and persistent url for each badge.* In the future we will support Signed Assertions, which will mean signing a badge assertion with your private key and hosting a public key at a well known, public URL. ** Pros: Less overhead for Issuer, just need to host public key* Further down the road, we will probably try to support DNSSEC for public key discovery. * Unverified Badge handling** If badge is passed through by an Issuer and the signature (when we support this method of verification) is invalid, OBI rejects it. ** If badge is verified initially but somewhere down the line it becomes unverified, OBI notifies user. [Needs to be worked out more.]

=== III. FUNCTIONAL FLOW ===

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

== H. Displayers==* Display of badges is where a significant part of the value lies - badges are not siloed or 'stuck' within one site but can be combined with badges from multiple Issuers and then shared out for different audiences/purposes * Earner will control where badges are displayed through the Backpack * Earner can create groups of badges and share through the Backpack to Displayers that have connected via the Displayer API * Earners can also make badges public - in that case, those badges would be discoverable by Displayers if they had the Earner’s email address * At its most basic: if a site has an Earner's email address, they will be able to query the Backpack for all of Earner's public badges. They will get back JSON representation of the badges

== I. Identity ==

=== I. OVERVIEW===* Identity is a critical part of the OBI because we need to know/recognize an Earner all across the web as they collect badges from different Issuers/sites * Identity needs to be open and decentralized * We are utilizing verified email as identity through the use of the Mozilla product called Persona ** Mozilla.com is working on a solution called Persona, fka BrowserID, the first version of the Mozilla Verified Email Identity** Additional info: https://browserid.org/, https://wiki.mozilla.org/Identity * People understand the concept of an email address ** c.f. They have difficulty understanding OpenID * Many sites already use email for login ** Even those that don't generally collect it (for resetting password) * We don't need to retain any profile or personal information about the Earner, all we need is the email address.

=== II. FUNCTIONAL FLOW FOR VERIFYING IDENTITY IN BACKPACK ===

== J. Development History, Milestone, and Roadmap== * Prototype - A prototype of the badge Infrastructure was built at the Mozilla Drumbeat Festival in Barcelona, November 2010. The prototype was updated and advanced in early January 2011, and a more complete and working prototype is now in use for the School of Webcraft badge pilot program. * Alpha - The Alpha version of the Infrastructure, built for P2PU as the initial Issuer was launched in late July 2011. The Alpha included user account creation, a simple Backpack interface, minimum verification and P2PU Issuer tech. All badges earned from the P2PU School of Webcraft Assessment and Badge Pilot were pushed into the Alpha Infrastructure with support for displaying on the user’s P2PU profile. * Developer Preview (Beta1) - The first Beta version of the Infrastructure launched mid September 2011. The Beta was a fully functioning (critical feature complete) Infrastructure, including all Backpack technology. Initial Issuers were plugging in following the launch. We did a closed beta launch to work closely with an initial group of issuers to fine tune the technology and ensure that we have data and experience to evaluate the Infrastructure. * Public Beta - Public Beta included more features including the Displayer API and was launched in early April 2012. * 1.0 Public Spec - In Q3 2012 we will release the 1.0 version of the Open Badge Infrastructure with all necessary supporting documentation and tools to make it self-service