Badges/Onboarding-Issuer: Difference between revisions

Jump to navigation Jump to search

Badges/Onboarding-Issuer (view source)

Revision as of 19:55, 20 March 2014

2,619 bytes removed ,  20 March 2014
General updating/ restructuring - in progress.
(General updating/ restructuring - in progress.)
Line 1: Line 1:
== A. Mozilla Open Badge Infrastructure (OBI) ==   
== Mozilla Open Badge Infrastructure (OBI) ==   
NOTE: The documentation below is for general on-boarding. If you want the more technical documentation, please see our [https://github.com/mozilla/openbadges/blob/development/docs/apis/issuer_api.md github pages].
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].


=== I. BACKGROUND ===
=== Background ===
   
   
==== Why Are We Doing This? ====   
==== Why Are We Doing This? ====   
Line 10: Line 10:
* Develop badges as a system for alternative accreditation, credentialing, and recognition;
* Develop badges as a system for alternative accreditation, credentialing, and recognition;
* Help badges expand beyond siloed environments to be broadly shareable;
* Help badges expand beyond siloed environments to be broadly shareable;
* Truly support learners learning everywhere;
* Truly support earners learning everywhere;
* Optimize the value of those badges by allowing badges to be remixable and shareable with different audiences;
* Optimize the value of those badges by allowing badges to be remixable and shareable with different audiences;
* Develop a supporting infrastructure to standardize the process and support each learner;
* Develop a supporting infrastructure to standardize the process and support each earner;
* Create an infrastructure that is open and as decentralized as possible to give learners control and support of the entire ecosystem.  
* Create an infrastructure that is open and as decentralized as possible to give earners control and support of the entire ecosystem;
* Provide software and development tools to help organizations implement badging systems.


==== Description ====  
==== Description ====  


Enabling learners to earn badges wherever they're learning across the web requires support for multiple individual badge issuers. Empowering learners to use their badges as legitimate credentials requires support for sharing of badges across many display sites. The Open Badges framework is designed to allow any learner to collect badges from multiple sites, tied to a single identity, and then share them out across various sites, including personal blogs to social networking channels. It is critical for this infrastructure to be open to give learners control over their own learning and credentials, allow anyone to issue badges, and for each learner to carry their badges with them across the Web and other contexts.  
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.


=== II. TECH SPECS ===   
=== Tech Specs ===   
* The OBI is built in node.js using express.   
* The OBI is built in node.js using express.   
* [https://wiki.mozilla.org/Badges/Onboarding-Issuer#C._Badge Badges] are represented by JSON data blobs embedded in PNG files in the [http://beta.openbadges.org/backpack/ Backpack]
* Badges are represented by JSON data blobs embedded in PNG files in the [http://beta.openbadges.org/backpack/ Backpack]
* [https://wiki.mozilla.org/Badges/Onboarding-Issuer#I._Identity Identity] management is handled by Mozilla’s Persona (fka BrowserID) [link: https://browserid.org/, http://identity.mozilla.com/]
* Identity management is handled by [http://identity.mozilla.com/ Mozilla Persona]


=== III. OPEN BADGES ECOSYSTEM ===
=== Open Badges Ecosystem ===
 
==== Diagram ====  
   
   
[[Image:Tech-diagram-v3 updated.png|700px|Open Badges -- Tech-diagram-v3 updated.png]]'''<br>'''
[[Image:Tech-diagram-v3 updated.png|700px|Open Badges -- Tech-diagram-v3 updated.png]]'''<br>'''


==== Overview ====
* An issuer makes a badge available to their community of earners on their website. When awarded the badge, an earner sends it to their Backpack.
* An issuing organization or individual makes a badge or series of badges available on their website and prompts their community to earn them. The earner sends the badge to their Backpack.
** The badge becomes portable through the [https://github.com/mozilla/openbadges/wiki/Issuer-API Issuer API] script, presenting the earner with a modal dialog that requests their consent to add the badge to their Backpack.
** The badge becomes portable through the [https://github.com/mozilla/openbadges/wiki/Issuer-API Issuer API] which provides script to present the earner with a modal dialog that requests their consent to add the issuer's badge(s) to their Backpack.
** If the issuer wants the earner to be able to store the badge outside the OBI, they can optionally push it to the [https://github.com/mozilla/openbadges/wiki/Badge-Baking Mozilla Baking Service] where the assertion URL representing JSON blobs is embedded into PNG files. Otherwise badge baking is handled through the Issuer API.
** Issuer can also push badges to the [https://github.com/mozilla/openbadges/wiki/Badge-Baking Mozilla Baking Service] where the assertion URL representing JSON blobs is embedded into PNG files
** n.b. This is only necessary if the issuer wants the earner to have the ability to store badges outside of the OBI. Otherwise badge baking is handled through the [https://github.com/mozilla/openbadges/wiki/Issuer-API Issuer API].  
* Displayers pull unpacked badges (JSON) out of the Backpack based on earner action and privacy settings.   
* Displayers pull unpacked badges (JSON) out of the Backpack based on earner action and privacy settings.   
* Public badges are discoverable based on earner’s email address.   
* Public badges are discoverable based on earner’s email address.   
* Earners can share their badges through their Backpack and grant permission for a particular site to display that collection of badges.   
* Earners can share their badges through their Backpack and grant permission for a particular site to display that collection of badges.   
* Displayers authenticate badges with the Issuer using the [https://wiki.mozilla.org/Badges/Onboarding-Issuer#G._Verification Verification] check.
* Displayers authenticate badges with the issuer using a verification check.
 
''Badge issuing is significantly simplified using BadgeKit, Mozilla's new set of badging tools. The BadgeKit Web app lets issuers create and publish badges through an intuitive interface. An issuer can then present those badges using the BadgeKit API, which also handles reviewing applications - [[Badges/badgekit|Read more about BadgeKit]].''
 
=== Definitions and Concepts ===
 
'''Badge'''
 
A digital representation of a skill, learning achievement or experience. Badges can represent competencies and involvements recognized in online or offline life. Each badge is associated with an image and some metadata. The metadata provides information about what the badge represents and the evidence used to support it.
 
'''Open Badge Infrastructure (OBI)'''
 
Open infrastructure technology supports independent badge issuers and displayers. Includes the metadata specification, APIs, verification framework, Backpack and software tools.
 
 
'''''ROLES'''''
 
'''Earner'''


''BadgeKit, Mozilla's new set of badging tools, can significantly simplify the issuing process - [[Badges/badgekit|Read more about BadgeKit]].''
Someone who earns a badge (either by applying or being directly issued with it). The earner can use their Backpack to manage and share their badges.
 
'''Issuer'''
 
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 issuing can involve participants with various specific roles, such as application assessors, badge creators and administrators.  
 
'''Displayer'''


=== IV. DEFINITIONS/KEY TERMS ===
;Badge
The core currency of exchange. A single signal that demonstrates a skill, achievement, interest, or affiliation.
;Open Badge Infrastructure (OBI)
Open infrastructure technology supports independent badge issuers, display sites, and reference implementation of the badges Backpack. Includes the metadata spec, APIs, verification framework, and badges Backpack. 
;[https://wiki.mozilla.org/Badges/Onboarding-Issuer#D._Mozilla-Backpack Mozilla Backpack]
The core authorized data store and management interface of Mozilla’s reference implementation of the Backpack. Each earner has their own Backpack where their badges data is stored.
;[https://wiki.mozilla.org/Badges/Onboarding-Issuer#E._Metadata_Spec Metadata Spec]
The definition of the information behind the badge. Each badge features a set of metadata that describes the badge, including badge name, badge issuer, date of issue, criteria URL, evidence URL, and standards URL.
;[https://github.com/mozilla/openbadges/wiki/Badge-Baking Badge Baking]
Embedding the assertion URL (which points to all metadata) into a PNG file to create a fully robust, portable badge.
;[https://github.com/mozilla/openbadges/wiki/Issuer-API Issuer API]
Interface specifications for sending badges to the Backpack.
;[https://github.com/mozilla/openbadges/wiki/Displayer-API Displayer API]
The interface specifications for expanding badges beyond the Backpack (including display sites and widgets).
;Verification API
Communication channels and framework to support badge verification.
;Endorsement API
Communication channels and framework to support badge endorsement, including focuses on valid signatures.
* n.b. Endorsement employs the same signing mechanism as Badge Verification
;Badge Earner
A learner who stores their badges and engages with the Open Badges Infrastructure. This learner has had interactions with issuers to earn badges and uses their Backpack to manage and share those badges.
;Issuer
Organization or individual who issues Open Badges to their communities.
;Displayer
A website, organization, or person who accesses publicly shared Open Badges and displays them for badge earners.  
A website, organization, or person who accesses publicly shared Open Badges and displays them for badge earners.  
;Endorser
An organization or individual who “endorses” a badge by signing it with their private encryption key. Trusted third party signers may emerge.
;[[Badges/badgekit|BadgeKit]]
A new set of tools to simplify badging for issuers - provides an interface for creating and managing badges/ assessing badge applications. The BadgeKit API lets issuers control interaction with their own community of badge earners.


== B. Issuer ==


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.
'''''TOOLS'''''
 
'''Mozilla Backpack'''
 
The core authorized data store and management interface of Mozilla’s reference implementation of the Backpack. Each earner has their own Backpack where their badge data is stored.
 
'''[https://github.com/mozilla/openbadges-specification/blob/master/Assertion/latest.md Assertion Specification]'''
 
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.
 
'''[https://github.com/mozilla/openbadges/wiki/Badge-Baking Badge Baking]'''
 
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/wiki/Issuer-API Issuer API]'''
 
The Issuer API provides a script for issuers to let earners send badges to the Backpack.  
 
'''[https://github.com/mozilla/openbadges/wiki/Displayer-API Displayer API]'''
 
The Displayer API provides specifications for displaying badges beyond the Backpack.
 
'''[https://github.com/mozilla/openbadges-verifier Verification]
 
The Verifier extracts badge data to verify earners.
 
'''[[Badges/badgekit|BadgeKit]]'''
 
A new set of tools to simplify badging for issuers - provides an interface for creating and managing badges/ assessing badge applications. The BadgeKit API lets issuers control interaction with their own community of badge earners while supporting much of the badge admin process through a Web app.
 
See also the [https://github.com/mozilla/openbadges-badgekit/wiki/BadgeKit-and-Open-Badges-Resources BadgeKit and Open Badges Resource list]


=== I. BACKGROUND ===
To explore the concepts and terms in badging and badge issuing, check out the [https://github.com/mozilla/openbadges-badgekit/wiki/Glossary Badging and BadgeKit Glossary]
* 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.


=== II. REQUIREMENTS ===
== Issuing Badges ==
* Issuers must have web server capable of serving requests to the general Internet.
 
* Issuers must have hosting ability.
An issuer is an organization or individual who designs and issues badges within the ecosystem. The OBI is open and supports any independent issuer who conforms to the necessary badge and issuing specifications. Additionally, issuers can now benefit from the [https://wiki.mozilla.org/Badges/badgekit BadgeKit] tools, providing they meet specific technical requirements.
* Issuers must have ability to make a POST request from their server backend and read a JSON response.
 
* Issuers must have email addresses for earners and must be able to email earners.   
=== Background ===
* Issuers must have badges (or be able to convert their badges) into the format (metadata spec) that the Assertion expects.   
* Issuers determine the badging approach that will work best for their communities.
* 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.  
* Touchpoints with the OBI occur through various interfaces, including sending badges to Backpacks and using BadgeKit.
* Issuers do not need to register with the OBI - they simply utilize the JavaScript APIs.
 
=== Requirements ===
* Issuers must have Web hosting facilities including:
** A server capable of serving requests to the general Internet.
** The ability to make a POST request from their server backend and read a JSON response.
** Email addresses for earners (and the ability to email them).   
** Badges structured in the format that the assertion expects - when using BadgeKit this structuring is automated.   
** 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.''
* For verification:
* For verification:
** If doing Hosted Assertions (currently available).
** For Hosted Assertions - issuers must maintain a server with the Badge Assertion information (at the unique badge URL) to verify each badge.   
*** Issuers must maintain a server with the Badge Assertion information (at the unique badge URL) to verify each badge.   
** For Signed Assertions:
** If doing Signed Assertions.
*** Issuers must generate public/private key pair and maintain the hosted public key.
*** 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.  
*** Issuers must sign the badges themselves, sign the whole package, and push badges to earner backpacks through the Issuer JavaScript API.  
* Issuers looking to use [[Badges/badgekit|BadgeKit]] have a specific range of options and requirements regarding hosting and technical provision - see the following blog post for more information: [http://openbadges.tumblr.com/post/78764181250/announcing-mozilla-badgekit Announcing Mozilla BadgeKit].
* Issuers looking to use [[Badges/badgekit|BadgeKit]] have a specific range of options and requirements regarding hosting and technical provision - see the following blog post for more information: [http://openbadges.tumblr.com/post/78764181250/announcing-mozilla-badgekit Announcing Mozilla BadgeKit].


=== III. BADGE CREATION FLOW ===
=== Badge Creation Flow ===


# Have an email address for the earner.
# Have an email address for the earner.
Line 104: Line 130:
# Integrate your site with the Backpack via the Issuer API
# Integrate your site with the Backpack via the Issuer API


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 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 assertions. Issuers can then present available badges to their earners using the BadgeKit API.''
'''''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.'''''


=== IV. OPEN BADGES Related Widgets created by the community ===
=== Open Badges related Widgets created by the community ===
* https://github.com/lmorchard/django-badger -- Issuing app for Django
* https://github.com/PRX/badges_engine -- Rails Engine for issuing.
* https://github.com/openmichigan/open_badges -- Drupal module for managing/issuing badges
n.b. Updated list can be found here: https://github.com/mozilla/openbadges/wiki/Open-Badges-related-widgets


=== V. Open Badger ===
A number of Open Badges widgets and utilities have been developed for integrating badges with various technologies including WordPress, Drupal, Django, Rails, PHP, Java, Moodle, Mahara, Joomla, Blackboard, Google Sites, Canvas, iOS, Android and AJAX.  
OpenBadger will be a lightweight OBI compliant badge issuing platform. It will soon make creating and issuing badges easy for non-technical users.
We've done some [https://github.com/mozilla/OpenBadger/wiki/Speculation speculation] but more to come on the [https://github.com/mozilla/openbadger Open Badger github].


== C. Badge ==
See [https://github.com/mozilla/openbadges/wiki/Open-Badges-related-widgets the list] on GitHub (which is regularly updated).


* Representation - Assertion URL representing chunks of JSON data embedded into a PNG file.
=== BadgeKit ===
* [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.


== D. Backpack ==
[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].


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.     
== Backpack ==
 
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 lets them 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.
* The Backpack is open source and federated. Earners or issuers can take the [https://github.com/mozilla/openbadges code] and fork it.
* Earners may decide to create and host their own Backpack so that they have complete control over their badges.
* Earners may decide to create and host their own Backpack so that they have complete control over their badges.
* 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.
* 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.


== E. Metadata Spec ==
== Assertion ==


=== I. OVERVIEW ===
Badge metadata is defined as an assertion, which contains multiple required and optional fields. The structure has evolved over time - see the [https://github.com/mozilla/openbadges-specification/blob/master/Assertion/latest.md assertion specification] for complete details.
* 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.


=== II. FIELDS ===
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.  
* Required
** recipient: Salted hash of the email address for the earner receiving the badge.
** salt: The salt used in the hash construction of the recipient’s email address.
** badge: The structure describing the badge. 
*** version: The version of the badge
*** name: Human-readable name of the badge being issued. Maximum of 128 characters.
*** image: URL for image representing the badge. Should be a square and in PNG format. Maximum size is 256kb.
*** description: Description of the badge being issued. Maximum of 128 characters.
*** 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).
**** name : Human-readable name of the issuing agent.
* Optional
** evidence: Earner-specific URL with information about this specific badge instance. Should contain information about how the individual earner earned the badge.
** expires: Date when the badge expires. If omitted, the badge never expires.
*** standard: Information about a governing institution or standard that a badge is related to.
*** 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.
** issuer: Information about the Issuer:
*** 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".
*** contact: (OPTIONAL) A human-monitored email address associated with the Issuer.


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.
== Badge Images and Baking ==


== F. PNG Files / Badge Baking Service ==
=== I. BACKGROUND ===
* Each badge is a JSON blob of metadata embedded in a PNG file.   
* 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.   
* 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.   
* Ultimately, this is important for decentralization of the system and will allow earners to have more control over where their badges live.   


=== II. BETA: BAKING SERVICE ===
=== Baking Service ===


* REQUIREMENTS: To bake a badge, you must be hosting a badge Assertion on your site.  
* To bake a badge, you must host a badge Assertion on your site.  
** See the Assertions page for details: https://github.com/mozilla/openbadges/wiki/Assertions
** See the Assertions page for details: https://github.com/mozilla/openbadges-specification/blob/master/Assertion/latest.md
* 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 system is designed to:
** The purpose of this is:
*** avoid SPAMing the earner with unwanted badges, and  
*** A) to avoid SPAMing the Earner with unwanted badges, and  
*** give earners ultimate control over where the badges go.  
*** 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 provides the "tools" for unpacking the PNG file through the OBI.   
* 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).
* 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.
* 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 ===
''If you are building a new system, we strongly recommend using the JavaScript Issuer API or BadgeKit for awarding badges. The tools and APIs take care of the badge baking.''
 
=== Badge Image Standards ===
 
* Image must be a PNG.   
* Image must be a PNG.   
* Images should be square and not exceed 256kb. They should have dimensions not smaller that 90 x 90.  
* 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.   
* 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.   
* 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.
* 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.
* When using BadgeKit, issuers can design badges inside the Web app using a graphical tool, or can upload images prepared elsewhere.


== G. Verification ==  
== Verification ==  


=== I. OVERVIEW === 
* To avoid gaming and duplication, the OBI is built to support badge verification.   
* To avoid gaming and duplication, the OBI is built to support badge verification.   
* 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?" 
* 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.   
* 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).   
* 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.
* Most verification will be done by displayers. Displayers should not display a badge that cannot be verified.


=== II. VERIFICATION METHOD ===  
=== Verification Method ===  
 
* 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.
* 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.   
** 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.   
Line 212: Line 205:
** If a badge is verified initially but it becomes unverified in the future, the earner is notified.  
** If a badge is verified initially but it becomes unverified in the future, the earner is notified.  
   
   
=== III. FUNCTIONAL FLOW ===   
=== Functional Flow ===   


# Badge (within it, its assertion) exists in the Backpack.   
# Badge (within it, its assertion) exists in the Backpack.   
Line 221: Line 214:
# If values match, badge is verified and displayer displays the badge. If not, displayer should reject the badge.
# If values match, badge is verified and displayer displays the badge. If not, displayer should reject the badge.


== H. Displayers ==
== Displayers ==
* 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.   
* 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 will control where badges are displayed through the Backpack.   
Line 228: Line 221:
* 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.
* 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.


== I. Identity ==
== Identity ==


=== I. OVERVIEW ===
* Identity is a critical component because we need to recognize earners as they earn badges from different issuers.
* 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.   
* 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.  
* We are utilizing verified email as a form of identity through the Mozilla product Persona.  
** Additional info: https://browserid.org/, https://wiki.mozilla.org/Identity   
** Additional info: https://wiki.mozilla.org/Identity   
* Many sites already use email addresses for logins, even those that don't generally collect them.
* 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.  
* We don't need to retain any profile or personal information about the earner; all we need is their email address.  


=== II. FUNCTIONAL FLOW FOR VERIFYING IDENTITY IN BACKPACK ===   
=== Verifying Identity in Backpack ===   


# User validates identity to Mozilla's Verified Email.   
# User validates identity to Mozilla's Verified Email.   
Suesmith
Confirmed users
20

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/954204"

Navigation menu