Requirements

Objectives

1. to identify the current non-OBI compliant badge issuers who have an Open API to ease the consolidation of their badges into the open badges backpack
2. to provide earners the ability to consolidate their badges from non-OBI compliant badge issuers into the Open Badges Backpack
3. to provide badge issuers (teachers, facilitators, communities, events, etc.) the ability to consolidate a particular badge (or collection of badges) from their non-OBI compliant badge systems into their learners OBI backpacks. (essentially, the ability to select an existing badge and create OBI badges for all the earners)
4. to provide existing non-OBI compliant badge issuers the ability to migrate there badge data into the OBI. Therefore, all their students earned badges become Mozilla Open Badges (essentially, the bulk loading of badges).

User Roles

1. Earner (Satnam) - Satnam is an independent self-directed learner. She has been earning badges from a number of different formal and informal locations over the last couple of years. Her collection of badges are stored in a number of "siloed" badging systems. In total, she has earned over 25 non-OBI compliant badges.
2. Facilitator (Henrik) - Henrik is an open educator who has been offering open education courses for over three years. The courses he offers are hosted at number of online learning portals with a variety of credentialing systems. Through time he has issued over 2000 credentials to his students.
3. Issuer (BIT) - The Bowen Institute of Technology has been offering online courses for a number of years and they award badges to their students upon completion of a course. They have issued over 15,000 non-OBI compliant badges. Being a technology focused institution they build and host most of their technology solutions. They are a tech savvy organization, they are resource constrained, and focus their resources on building curriculum.
4. Enterprise Issuer (Maritimers) - the Maritimers are an international association of maritime professionals. They have been issuing badges for decades. The badges are used to denote maritime rank (like a military rank) and other skills, accomplishments and honours. Since they started offering badges in 1928, they have issued over 470,000 badges.

There a couple of other user roles, but they mostly fall into these four...

User Stories

1. I want to consolidate all my badges

• User Role - Earner
• I have a number of badges stored in different badge issuing systems, I'd like to consolidate them into Mozilla's open badges backpack.

2. I want to re-issue all my course badges as OBI compliant badges

• User Role - Facilitator
• I am an independed open educator and have issued many badges through a number of different sources. I want to start issuing all my badges through the Mozilla OBI. I want a way to bring all my existing issued badges into my students Mozilla open badges backpack. I am will to coordinate the re-issue effort myself, but I would like a way to automatically load my student badges (by badge type) into the OBI.

3. We want to allow our students to move thier badges into the OBI

• User Role - Issuer
• As an issuer we have issued over 15,000 badges. We want to keep our existing non-OBI compliant badging system, but we want to expose our badge data so our students can migrate thier badges into the Mozilla open badges backpack.

4. We want to load over 100 thousand issued badges into the OBI

• User Role - Enterprise Issuer
• We have been issuing badges for over 50 years and would like to migrate all our non-OBI compliant badges into the Mozilla OBI. We'd like to simply provide you an text file with all our badge data or you to load into the OBI.

5. More stories to come

Partner API research

a number of existing and potential partners were evaluated for thier existing API's for emmiting badge / credential data. This evaluation is documented within this google doc;

• https://docs.google.com/spreadsheet/ccc?key=0Ak8Mcp1f93B1dGZCazN0d3RybWI5SXdnLVc4WFVQOXc

Approach: All the fields within the partner interfaces were evaluated against the attributes of the issuer json;

• https://github.com/mozilla/openbadges/wiki/Assertions

Architecture / Design

partner integration should take a plug-in type approach where a common infrastructure is built where every new partner only needs to build a "small" plug-in to integarte with the OBI. There will be two sides to each plug-in;

1. the partner emmiter API
2. the OBI consumer

patterns

http://en.wikipedia.org/wiki/Module_pattern

data storage

users should be able to choose if their badge consolidation history [and related profile data (login, password, email)] is retained for subsequent consolidations or if no data is retained and is temporary only for the consolidation event.

bulk loading

some partners will so much data it will need to be bulk loaded. Keeping data integrity with subsequent loads will be very important.

Implementation

outreach

• OBI team create an extensible architecture that allows for easy integration with non-OBI compliant badging and credentialing systems
• our "plug-in" approach for new partners requires less resources to add new partners
• we offer guidance and technial resources to build both the OBI and partner sides of the plug-in. This includes assistance in building the partner side API for the emmitting of earner badge data.
• also offer resources and consulting services for the bulk loading of data (see enterprise issuer user role)

Phase 1

User stories 1 & 3

Phase 2

User story 4

Phase 3

tbd