{
"schema": "https://example.com/badge/1",
"mustSupport": [],
"title": "School of Webcraft Responder",
"description": "This badge is in recognition of the helpful responses you have provided to fellow members of the School of Webcraft.",
"timestamp": "1288882617",
"expires": "8462729988",
"badgeURL": "https://badger.mozilla.com/badges/asdf1234",
"issuer": "https://badger.mozilla.com/",
"issuerName": "P2PU School of Webcraft",
"imageURL": "https://badger.mozilla.com/badges/asdf1234/badge.jpg",
"issuee": [{"type": "email", "id": "thunder@mozilla.com"},
{"type": "openid", "id": "https://id.sandmill.org/"}],
"onclick": {"action": "iframe", "url": "http://cc.org/embed/blah.html"}
}
- schema identifies this as a badge
- mustSupport is used for versioning. It is an array of opaque strings which specify required support for attributes/concepts by consumers of this badge (if not understood the badge should be ignored)
- issuer is the entity issuing the badge, issuee is who it is being issued to. They could be the same.
- badgeURL attr is a unique URL for this badge instance. It could be shared between multiple issuees--for example, all the members of the winning team of a championship could be issued the same badge
- multiple issuees are possible to allow the badge to still be somewhat usable in the event that a federated id provider goes down. this needs some more thought--that would allow for verification that the issuee exists, but not that he/she was actually issued a badge [fixme]
- expires could be used to implement dynamic badges, by requiring a refresh of the badge. it could also be used to represent time-limited knowledge--e.g. you know html5 really well now, but in 3 years maybe that's not true
- onclick is so we can specify things like "open an iframe to X" or "go to X URL" when clicked. [needs work]