Changes

An organization, consortium, group or individual who issues designs and issues badges into the OBIecosystem. The OBI is open and supports any independent Issuer that issuer who conforms to the necessary badge and issuing specifications.

* Issuer Issuers completely determine the content and criteria behind their badge systems are independent of the Infrastructure - how you assess work, decide who earns badges, issue badges within your site, display badges within your site, etc. - that's all up to each Issuer * We are intentionally pushing the innovation to the edges - meaning the Issuers have complete control over how They know their badge system works * We want to support innovation, not constrain it communities best.* The touchpoint with the OBI is pushing each badge into occurs when earners send their badges to the designated Backpack for the earner .* Issuers do not need to register with the OBI - ; they simply push send badges into to earner 's Backpacks utilizing the Issuer Javascript API.

* Issuers must have web server capable of serving requests to the general internetInternet.* Issuers must have hosting ability.

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

* Earners must be registered with whatever Backpack the Issuer backpack implementation that the issuer is trying to push send their badges to. In the future, or (for later versions) the Issuer must issuer will need to ask Earner the earner which Backpack 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 (on development roadmap).*** 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 badge badges to Earner Backpacks earner backpacks through the Issuer Javascript API.

# Have an email address for the Earnerearner.# Create and host an Assertion on your site.

n.b. The Issuer API is a script that can be dropped-in to into any Badge Issuerbadge issuer's website to provide a way for Earners earners to add an Issuerissuer's badges to their Backpackor federated backpacks. There's no need to bake the badges yourself. The independently as the API takes care of it for youthis.

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

The core currency of exchange. A single credential demonstrating a skill, achievement, quality or affiliation. * Representation - Assertion url 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 Assertion URL. The OBI currently supports verification of badges through Hosted Assertions. i.e. When Issuer pushes the issuer sends a badge to the OBI, metadata is pushed to a unique and persistent url aka URL (the assertion urlURL). Issuer The issuer maintains Badge badge Assertion and Displayers displayers can ping the assertion URL to confirm verification.** n.b. Signed Assertion is on the [https://wiki.mozilla.org/Badges/roadmap development roadmap]. * 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 20122013.

The Mozilla Backpack is an authorized data storage plus a space and management interface for earners of Open Badges. Each earner will have can access their own Backpack that holds all of their badges and gives them an interface to manage, control and share their badges. * The Backpack as well as the entire system is open source and federated. Earners or Issuers 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 will hold holds all of the badge Assertions (hashed user email + badge data) for each earner.

* A badge is an assertion url 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 or used.* This is the data presented in the Assertion URL on the Issuerissuer's server.

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

*** criteria: URL describing the badge and criteria for earning the badge (Not not the specific instance of the badge).*** issuer: Information about the Issuerissuer: **** origin: Origin of the Issuerissuer. 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 specific Earer individual earner earned the badge.

*** standard: Information about a governing institution or standard that a badge is related to.*** The badge is not removed from the Earner’s 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".

* n.b. We've discussed having an additional field that is customizable by the Earner - so that the Earner could add a personal evidence URL, or could add additional information or context to the badge. This would NOT be something that the Issuer would include in the Badge Assertion (so it is not listed above) and would most likely be managed by the Earner through the Backpack.* n.b. 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. There currently isn't a method for updating the information received in the badge, though it's not off the tableearner.

* Each badge is a JSON blob of metadata embedded in a PNG file . * This allows the badge to be more easily portable - an actual 'thing' collection of information that can be emailed around, and portable while still carrying all the information its details with it . * Ultimately, this is important for decentralization of the system - so that Earners and will allow earners to have more control over where their badges live .

* For beta, Mozilla will be providing a [https://github.com/mozilla/openbadges/wiki/Badge-Baking 'baking' service] to package the JSON into a PNG file * REQUIREMENTS: To bake a badge, you must be hosting a Badge badge Assertion on your site. ** See the Assertions page for details: httpshttp://githubbit.com/mozilla/openbadgesly/wiki/AssertionsNewOpenBadgesAssertion* Issuers will still send the Badge 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 issuer who can then send to the Earner earner.

*** A) to avoid SPAMing the Earner with unwanted badges (which we can control in beta) , and

* Mozilla will provide provides the '"tools' " for unpacking the PNG file through the OBI . * PNG files will be unpacked in the Backpack where each Earner earner can view, manage , and organize their badges (and see all the metadata behind each badge) .

* 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 . They should have dimensions to not smaller that 90 x 90 . * Image is provided as a URL to the image on the Issuer issuer server in the metadata . * Mozilla will cache the image in at least 2 two sizes . * When a badge is displayed, it will be loaded from the Mozilla cache to avoid extra burden on the Issuer issuer servers, . This also in case helps if the Issuer issuer is not available or the link is broken .

* This handles helps handle the questions of "Did this Issuer issue this badge to this Earner 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 The issuer must be online to verify badges. (we We are exploring a cache to cover verification for x a set amount of time) . * Most verification will be done by the Displayersdisplayers. Displayers should not display a badge that cannot be verified.

* The OBI currently supports verification of badges through Hosted Assertions. i.e. When Issuer pushes an issuer sends a badge to using the OBI, metadata is pushed to a unique and persistent url aka assertion urlURL (the Assertion URL). Issuer The issuer maintains the Badge badge Assertion and Displayers displayers can ping the assertion URL to verify the badge.** Displayer A displayer puts the Earner’s 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 that claims it, if not, it is being spoofedearner and can be claimed. ** Cons: Overhead There is a drawback of overhead for Issuer the issuer to maintain unique and persistent url URLs for each badge.* In With the future V1.0 release we will support Signed Assertions, which will mean allowing for signing of a badge assertion with your a private key and hosting a public key at a well known, public URL. ** Pros: Less This has the benefit of creating less overhead for Issuer, the issuer who just need to host the public key.* Further down the roadLooking forward, we will probably try to support DNSSEC for public key discovery.

** If a badge is passed through by an Issuer issuer and the signature (when we support this method of verification) is invalid, OBI rejects itis rejected. ** If a badge is verified initially but somewhere down the line it becomes unverifiedin the future, OBI notifies user. [Needs to be worked out morethe 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 displayer displays the badge. If not, Displayer displayer should reject the badge.

* Display of badges is where a significant part of the value of this approach lies - badges . Badges are not siloed or 'stuck' within limited to one site but can be combined with badges from multiple Issuers issuers and then shared out for different audiences/and purposes . * Earner Each earner will control where badges are displayed through the Backpack . * Earner Each earner can create groups collections of badges and share through the Backpack to Displayers with displayers that have connected via to the [https://github.com/mozilla/openbadges/wiki/Displayer-API Displayer API] . * Earners can also make badges public - in that case, ; those badges would be discoverable by Displayers displayers if they had the Earner’s earner’s email address . * At its most basic: if If a site has an Earnerearner's email address, they will be able to query the that person's Backpack for all of Earnerthat earner's public badges. They will get back JSON representation of the badges.

* Identity is a critical part of the OBI component because we need to know/recognize an Earner all across the web earners as they collect earn badges from different Issuers/sites issuers.* Identity needs It's important to us that identity be open and decentralized . * We are utilizing verified email as a form of 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

* People understand the concept of an email address ** c.f. They have difficulty understanding OpenID * Many sites already use email addresses for login ** Even logins, even those that don't generally collect it (for resetting password) them.* We don't need to retain any profile or personal information about the Earner, earner; all we need is the 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.