This repository has been archived by the owner on Aug 22, 2019. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 264
openbadges federation sketch
Chris McAvoy edited this page Nov 6, 2013
·
3 revisions
- Users should be able to self-host Backpacks.
- Backpacks should be
localhost
able – meaning, an outside connection should not be required. A backpack should be able to exist behind a firewall. - Implementation should not require Issuer to change existing code (i.e, Minimal implementation should work today without Issuers changing anything).
- No required central authority/single point of failure.
- Backpacks should not have to know about other Backpacks.
- 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)
This is an optional enhancement for the following workflows.
- Backpack invokes Shim-provided
OpenBadges.registerBackpack
- Shim presents dialog to user, "Would you like to add XYZ Backpack to your list of backpacks?"
- 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)
- Since
localStorage
is specific to each User-Agent, this will not sync across devices/browsers. - Need to look into
remoteStorage
from the Unhosted guys.
This is used in the flows below
- Shim checks the list of
registeredBackpacks
, which could be an empty set. - If the set is empty, ask user for location of backpack. Ideally, user would only need to provide the origin.
- A reasonable default should be provided if the user has no backpack/doesn't care (i.e., the Mozilla hosted Backpack).
- An escape hatch should be provided when there is a registered default backpack for the user to provide the location of an alternate backpack.
Ideal for sites with no backend. Applicable for Issuer
- User earns badge from Site.
- Site presents User with "Push to Your Backpack" button (copy not final), which activates Shim.
- Shim determines location of User's backpack, first by checking for any previously registered backpacks.
- With some modification, this flow could be applicable to Displayers: User-Agent pulls from CORS-capable backpack, return array of badges).
Ideal for sites with a backend (ability to make server-to-server HTTP requests). Applicable for Issuer and Displayer.
- Site asks User for permission to connect to their Backpack. Site requests certain capabilities.
- Shim determines location of User's Backpack is AND determines if capabilities match up.
- Shim returns approval/denial to Site with JSON description of relevant Backpack endpoints.
- 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.
Forthcoming, this idea half-baked at best.