initial discussion

[MatthewVita]

engage

[MatthewVita]

@whit537 says saxifrage/cityasacampus#153 (comment)

[chadwhitacre]

:-)

Interesting conversation-starter, https://github.com/saxifrage/universal-badge-api. Sounds familiar from conversations I've had with @timothyfcook. Badgr is new to me, though. Have we considered joining forces with them? They have a hosted service, which is de facto centralization (even if they do also promote standalone instances). I've just registered an account there (and created a ticket ;-). What other open-source badge servers already exist?

[MatthewVita]

This is a fresh "pen and napkin" (well, we actually used a whiteboard...) idea. We can't join forces with Badgr until we actually speak with the devs/associated organization.

Speaking freely and with much respect to their hard work, my 3 primary concerns with Badgr are:

1. Our idea would extend the badge standard they're using... which may not fly since they seem to be coupled to Mozilla's standard
2. The website says "Try for free today!" and "Badgr is a product of Concentric Sky", which is not typical of an open source project
3. doesn't seem to concern itself with any formal boards/evidence/additional metadata/etc

[MatthewVita]

"What other open-source badge servers already exist?" AFAIK, none.

amendment: with the condition that such a server has an API for consumers, that is.

[chadwhitacre]

I once owned badgr.co, which, while its definition of "badge" differs, reminds me of our present discussion in another way. I bought badgr.co to host a GitHub README badge server that I had written. I discovered that I was duplicating effort with the Shields project, and I ended up joining forces with them. That was my most significant experience of doing the hard work of partnering with others, rather than forging ahead with my own plans. Here is the badger that I drew for Badgr.co:

May he, in some measure, be for us a badger of collaboration!

[MatthewVita]

Very interesting, thanks for sharing.

I'm definitely happy to join forces, of course (collaboration, FTW). I certainly don't want to write an entire badge API and auth strategy if that's already been done!

Some ideas[0] we've laid out in our README.md have never been implemented in an OSS open education badge API so it would be great to join with Badgr to build on their platform.

@timothyfcook to accelerate this conversation, can you ping your friend at Badgr? You can probably @mention him here.

[0]

• centralized platform
• competency benchmarking
• volunteer boards to verify badges and credibility of instances

[chadwhitacre]

centralized platform

http://badgr.io/ is a centralized platform, no?

[MatthewVita]

@whit537 the platform itself is centralized. The badges themselves are decentralized. As long as a badge has an assertion url, they can be "imported". This is, I think, a problem [0]. Badgr is great as a backpack [1], connecting issuers, and a means to present badges via the earner API.

I stood up badgr and found that they have a nice API doc: https://cloud.githubusercontent.com/assets/1715206/8973968/ef905f06-3639-11e5-96b5-196a4262feb7.png

[0] as seen in our README, it would fantastic for a centralized badge platform to allow for badges to be requested and the following would be reviewed:

• badges contains well-defined and weighted curated competencies (for Competency Benchmark Indicator data) by respected organizations/experts
• badges need to exhibit evidence that confirms learner took course
• badges need endorsements from respected organizations/experts (critically important)
• badges need to be approved by a board of volunteers (not just added arbitrarily)
  organizations/instructors need to be one-time-approved by a board of volunteers (these volunteers should probably be educators, IMO)

...basically, we'd be the API to make this happen and any client could leverage it (CaaC, for example :) ). We would modify existing badge standards/build on them. I am of the opinion that badges need this kind of credible vetting process to mean something... especially in the context of higher ed.

[1] definition from Badge Alliance: "A tool used to collect, share and display earned badges. One example is the Mozilla Backpack - a federated backpack is also under development."

[MatthewVita]

I'm really interested in your and Tim's thoughts here. We're entering new territory here and I think that debating this "process"-oriented checklist strategy is healthy. After all, I'm just a software geek that has no real credentials in education :)

[chadwhitacre]

[T]he platform itself is centralized. The badges themselves are decentralized.

Mmmm. I read ya now.

Two quick points:

• I tend to have a low view of federation. I find open centralization more interesting.
• The badge problem is a marketplace problem, requiring both consumers of badges (credentials) as well as producers. Marketplaces require manual flooding at the outset. Ross Ulbricht manufactured his own shrooms to jump-start Silk Road. For Badgr.io (or whatevs), I could see a Phase 1 focused on higher education consuming badges issued by lower education, where both sides are already invested in the badge movement. Phase 2 is employers (open companies?) that are willing to start consuming badges produced by both higher and lower participants in Phase 1.

[MatthewVita]

I agree that open centralization is best.

As for your second point, I feel as though we could employ a process like the one that is being worked out for CaaC saxifrage/cityasacampus#150. Over simplification?

[timothyfcook]

Let's try and focus the discussion here on the primary goals, specifically what the technology will do. In this post I included an ugly sketch to start thinking of what we needed:

What I want is:

A centralized service that:

1. allows learners to login to a learning platform (like CaaC or anywhere else)
2. forces learning platform to ask for CRUD permissions for the learner's archive (so they can add badges, etc.)
3. allows learner to choose the level of permission they grant to the learning platform (provide good scoping)
4. badges, and eventually other learning data, maybe xAPI statements, are saved to the learner's archive, not to the data-store on the learning platform (although maybe we can let them save it as well? that could be one of the permissions).

The goal is to provide seamless connections and data storage across platforms so that if I'm logged into CaaC but get linked out to a resource at Khan Academy I don't have to login with a separate account and so that my learner data is persistent across platforms.

[MatthewVita]

Tim, I enjoyed reading your article. I feel that this repository can be the place that starts to implement (and build on) your idea.

What I want is:

A centralized, open source, and cloud-based Universal Open Education Badges API[0] that:

1. allows one to submit badges for approval by a volunteer board of educators (following a checklist)
2. allows any learning platform that uses open education badges to leverage it for any badge interactions. Badges can still be saved on that relative learning platform but the Single Source of Truth (SSoT) is always with this centralized API [1]
3. allows learner to choose the level of permission they grant to the learning platform (provide good scoping)

[0] we need a name :) ... I always thought "Illumine" would be a cool API name, FWIW
[1] allows for an easier migration as well... which is a big plus

@whit537 @Arf375 feel free to list what you feel are the primary goals. I suppose we'll just keep refining them until we all agree.

[timothyfcook]

Nice.

Your 1. is interesting, but might be outside the initial scope. In that concept, are you referring to the badgeClass (i.e. the "idea" of the Badge), rather than the badge as earned by the learner? i.e. the badgeAssertion

In the case of the earned badgeAssertion, the review is supposed to take place on the front-end before the badge is issued. You don't earn it unless you have done the work. However, I think there could be an interesting market for "certifying" badgeClasses. I think that the API service could eventually have that kind of clout in the market to provide that as an additional quality-control service, but maybe only after the API tech is in place and becomes adopted.

[timothyfcook]

@MatthewVita do you agree that the identity service is an important part of this?

[MatthewVita]

My point #1 was about the actual badgeClass creation process and also the subsequent consumers. For example, a "Programming 101" badgeClass should be approved by the Universal Badge API panel that list out what that badge represents (crude example ahead... this is where we will be expanding on current badge data standards):

When a platform wants to associate their opportunity instance with this particular badge, the Universal Badge API panel has to approve it by doing a check similar to how CaaC will vet opportunity instances.

Thoughts?

[MatthewVita]

btw, Addison and I were thinking about how a UI would look for this (when badges are being made). If we're on the right track, he and I will actually mock it up.

[MatthewVita]

@timothyfcook and yes, I would agree that identity service [0] is probably the most important piece.

[0] I'm assuming you mean the service that actually captures the entirety of a learners accomplishments in a centralized way?

[timothyfcook]

On badgeClass approval when an educator creates a badge, I think a serious review process for all badges would be too onerous and unnecessary. However, I do think there could be a lot of value in certain badges going through an extra layer of quality-assurance by getting approval/certification in some way, especially as it relates to their relevancy in a certain competency area.

I like the idea of peer-creators reviewing one another badge creations and reviewing them. Since peers have a knowledge base with which to make judgements and an incentive to keep the overall quality of badges up, this could work well.

[MatthewVita]

@timothyfcook I agree with you. For example, my "Programming 101" badge, although crude, could probably scale really well because I know programming. Shouldn't need a serious review process. In addition, the opportunity instances issuing that badge can request changes to it over time, as needed.

However, a huge point I was trying to make is that opportunity instances requesting to issue a particular badge should be reviewed by the Universal Badge API panel to make sure the opportunity instance satisfies the requirements to truly be able to issue that badge. Thoughts?

[timothyfcook]

Interesting.

In this context, there are two kinds of badgeClasses that organizers could create:

1. Badges that were created for a single use-case in a local program or digital tutorial
2. Badges that were created for national use by many programs or tutorials.

This first type of badges doesn't necessarily need approval, since the created/issuer of the badge is the same as the creator of the opportunity_instance.

The second type may require an endorsement from the Creator of the badge if another organizer wants to issue the badge. This idea of endorsement has been discussed at length in the Open Badges community, but has yet to become fully implemented. It is, however, definitely on the horizon.

I've written about possible implementations of endorsement here.

To encourage flexibility, I think that some nationally shared badges could require endorsement in order for another organizer to issue them, while other nationally shared badges may not. e.g. the American Red Cross could create a CPR Certification badge that would require their endorsement in order for other organizers to issue that badge as a result of their holding a CPR class in a local opportunity_instance.

In this example, it isn't a "Universal Badge API" panel that is reviewing badge issuers and allowing them to issue a badgeClass they did not create, but it is the Creator of that badgeClass that reviews and endorses any subsidiary issuers.

That said, I think there might still be a role for a higher level of review/endorsement at some point.

[MatthewVita]

Tim, thanks for the link to the Open Badges discussion. Was very helpful.

I feel that we can move forward with leaning on endorsements as the means of establishing credibility (even in the case of a "single use" program... I am of the opinion that if a person or organization is serious about offering an educational opportunity, they'll want to ensure it is credible by having endorsements... shouldn't be hard). This eliminates the need for the panel I mentioned before. Can we agree that our ideal API is now defined as:

A centralized, open source, and cloud-based Universal Open Education Badges API that:

• allows one to submit badges that require an endorsement and all associated badge metadata (which include competency metrics)
• allows any learning platform that uses open education badges to leverage it for any badge interactions. Badges can still be saved on that relative learning platform but the Single Source of Truth (SSoT) is always with this centralized API
• allows learner to choose the level of permission they grant to the learning platform (provide good scoping)

?

If so, this means that the current badge spec is missing the required endorsement piece and the competency metrics. Do you know anyone that we can talk to about those? I think we'd get a chance at validation and a lot useful information from those working groups.

[timothyfcook]

Looks great to me. In point 1, let's clarify that this is an Organizer / Issuer who wants to get a badgeClass endorsed, as opposed to a learn who wants their earned badgeAssertion endorsed (potentially also a future possibility).

For further reference, sharing the Open Badges spec page.

[MatthewVita]

Cool. Are we missing anything? Is the scope too big? Is the orderedCurriculum field (extending the badge spec) too constraining?

[MatthewVita]

Please view/amend as needed the new README.md https://github.com/saxifrage/universal-badge-api/blob/master/README.md