Discussion: swag + badges?

[usernamenumber]

The purpose of this Issue is to provide a space for people to comment on the viability (or lack thereof) and desirability (or lack thereof) of using badging systems like Mozilla's openbadges as part of Swag.

A Swagmap is a collection of acknowledgements of user achievement.

A badge is a an acknowledgement of user achievement that:

• Follows an established spec
• Is portable between various badge stores (e.g. Mozilla Backpack, Achievery, others)
• Supports digital signing (though I'm unclear how many implementations actually do this)

...basically, it seems that representing swag achievements with badges could both give us a solid framework to build on, and add value to the swag a user collects.

However, there are some major hurdles that would need to be overcome for us to be able to do this, including but not limited to (note that these are based on conversations with people and some cursory looking through the spec; everything below could be completely wrong! I'm just putting it down so we have somewhere to start the conversation):

1. Elimination of online dependencies: It seems like the spec could be implemented in such a way that the assertion of achievement does not have to be sent to a remote badge store, but could instead be generated locally in a way that could be uploaded to a store later, but its unclear to what extent it has.
2. Self-containedness: Again, it seems like the spec can allow for some kind of digital signing, but it doesn't seem to be very commonly implemented. Everyone I've talked to agrees that having a badge as a standalone .png file that can be verified by anyone with the issuer's public key, and maybe even has extra metadata steganographically encoded into it would be really cool, but no one has been sure whether it's been done, or even if it could be done.
3. Security: Having the issuer be a classroom server not connected to the internet means storing the signing key somewhere students could theoretically get at it. One way around this might be to symmetrically encrypt the key with a passphrase that should (emphasis on "should") only be known to instructors, but even this is sub-optimal.

[usernamenumber]

Some references:

• A nice looking tutorial on unsigned badges, but refers you to the spec for signed badges. :(
• Thread on the openbadges group about signed badges; doesn't currently have anything useful, but hopefully someone will post something in the future.
• Django-based badging system
• Python and Node JWS implementations

[usernamenumber]

Possible approaches to signature/badge storage:

• Work has been done on a PNG signature spec, but I'm not clear if it ever went anywhere, and it might be overkill, especially in light of...
• The PNG spec appears to support arbitrary "chunks" of data, which, if marked as "ancillary", will be ignored by software that doesn't know what to do with a particular chunk. This could at least allow for storing a JWS signed badge.
  • I think it might be worth including a second chunk with the signature of the PNG its self, too. Of course, this chunk would have to be added after the signature is generated and removed while the signature is validated (otherwise the hashes wouldn't match), but it would allow a warning to be shown if an image may have been tampered with (e.g. replacing one person's name with another, which wouldn't stand up to scrutiny of the JSON data, but could fool a cursory observer), without invalidating a badge that may have had more innocent changes made (such as resizing, which people should be told not to do, but hey, robustness is good).

[usernamenumber]

Found a Python library that looks like it should be able to manipulate PNG text chunks, but having some problems with it in practice. (see also)

[ottonomy]

Use https://pythonhosted.org/pypng/png.html PyPNG for PNG manipulation. 👍

I disagree with putting multiple chunks into a PNG for verification of a badge. I think the verification information (signature) should live with the information it's signing. Both JWS and the newer JSON-LD "Secure Messaging" spec that we're now considering is able to package these components together in one chunk.

[usernamenumber]

Created a more formal writeup for this project (currently being buried by other priorities) based on what I've learned so far in a post on Tunapanda's discourse forum.