openbadges federation sketch

OpenBadges Federation Planning

Design Goals

1. Users should be able to self-host Backpacks.
2. Backpacks should be localhostable – meaning, an outside connection should not be required. A backpack should be able to exist behind a firewall.
3. Implementation should not require Issuer to change existing code (i.e, Minimal implementation should work today without Issuers changing anything).
4. No required central authority/single point of failure.
5. Backpacks should not have to know about other Backpacks.

Workflows

Terms

• Issuer: Site that generates and signs/hosts badge assertions
• Backpack: Site where a User stores, manages badges from across sites.
• User: A person earning badges from Issuer, wants to get those badges into a Backpack.
• User-Agent: A piece of software acting on behalf of a user (generally a web browser). The User-Agent has the network privileges of the computer a User is operating – so things behind a firewall are accessible, etc.
• Displayer: Site that shows (among other things) a collection of user badges.
• Shim: JavaScript library that provides functionality. Hosted in neutral territory (e.g., https://openbadges.org/shim.js or a browser plugin)

Backpack Registration Flow

This is an optional enhancement for the following workflows.

1. Backpack invokes Shim-provided OpenBadges.registerBackpack
2. Shim presents dialog to user, "Would you like to add XYZ Backpack to your list of backpacks?"
3. Shim saves backpack list/preferences (either to localStorage bound against "https://openbadges.org" in the case of the JS shim or to the plugin's internal storage)

Notes

• Since localStorage is specific to each User-Agent, this will not sync across devices/browsers.
• Need to look into remoteStorage from the Unhosted guys.

Determining a User's Backpack Location

This is used in the flows below

1. Shim checks the list of registeredBackpacks, which could be an empty set.
2. If the set is empty, ask user for location of backpack. Ideally, user would only need to provide the origin.
3. A reasonable default should be provided if the user has no backpack/doesn't care (i.e., the Mozilla hosted Backpack).
4. An escape hatch should be provided when there is a registered default backpack for the user to provide the location of an alternate backpack.

Standard Issue Flow

Ideal for sites with no backend. Applicable for Issuer

1. User earns badge from Site.
2. Site presents User with "Push to Your Backpack" button (copy not final), which activates Shim.
3. Shim determines location of User's backpack, first by checking for any previously registered backpacks.

Notes

• With some modification, this flow could be applicable to Displayers: User-Agent pulls from CORS-capable backpack, return array of badges).

Connect Flow

Ideal for sites with a backend (ability to make server-to-server HTTP requests). Applicable for Issuer and Displayer.

1. Site asks User for permission to connect to their Backpack. Site requests certain capabilities.
2. Shim determines location of User's Backpack is AND determines if capabilities match up.
3. Shim returns approval/denial to Site with JSON description of relevant Backpack endpoints.

Notes

• This does not work with a localhost backpacks since it is necessary for an issuer to make contact with the backpack without going through a User-Agent.

RSS/Atom Flow

Forthcoming, this idea half-baked at best.