A Problem With Badges

This post originally appeared on the Software Carpentry website.

We issued the first learning badges for Software Carpentry a couple of weeks ago, and in doing so, uncovered a significant flaw in the design of existing badging systems. My intent was to give a bunch of people "Instructor" badges; by mistake, I set the pulldown to "Organizer", then clicked "Issue". As a result, two dozen people got the wrong kind of badge—and there doesn't appear to be any way for me to undo that. According to Dave Lester, who created the WPBadger plugin for WordPress that I'm using:

I don't believe there's a way for an issuer to remove issued badges from a backpack, however if you remove an award from WPBadger and it results in a broken link the assumption would be that it no longer exists.

Since there will be multiple backpacks, I'm not sure how an issuer could notify all of them to let them know if a badge has been revoked.

One idea: perhaps the assertion file that WPBadger generates could be updated when a badge is revoked, with a standardized message so the backpack knows that the award is no longer valid.

Now, issuing the wrong badges was my fault. But I'm not the only person who will ever make that mistake, and as badging is scaled up to involve thousands or millions of people, there will inevitably be cases where someone's work turned out to be plagiarized, or where a buggy piece of software was given proof of X but issued badge Y, and so on. In the real world, there needs to be a way to cross badges off.

This isn't actually a new problem. During the first dot-com bubble, I spent several years working on a single sign-on/access control product called SelectAccess (initially at a startup, then at Hewlett-Packard after we were acquired). That work was my first exposure to digital certificates, and to the certificate revocation problem. In brief, issuing a certificate is easy: you create a blob of digital data, then sign it with your own certificate, which has been signed with another certificate, and so on back to a trusted root certificate (which is very carefully guarded).

Revoking a certificate, on the other hand, is a major pain—in fact, it's so difficult that many systems don't handle it at all, and others do so poorly. Once a valid certificate has been created, its bits can be copied any number of times, to any number of places. There's no central record of where those copies are, so there's no way to go and delete or modify them all. The best the issuer can do is create a list of invalidated certificates, and hope that users are periodically updating their copies of that list and checking incoming certificates against it—a "solution" which scales very badly.

One non-solution to this problem is to embed an expiration date in each certificate. However, that creates a window of vulnerability between the time the issuer decides to revoke the certificate, and the time sites actually stop accepting it. Reducing the lifetime of each certificate shrinks this window, but imposes the burden of re-issuing and re-distributing certificates every day, hour, or whatever—which once again fails to scale.

It seems to me that our current badging systems have exactly the same design flaw. I don't have a solution, but I think that if we don't come up with one, badging will turn out to be something that works a lot better in theory than in practice.