There is conflicting information in the documentation about whether badges should contain information that enables anyone to verify a badge. If there is to be verification information embedded into the badge (image file) then it is to be an assertion. An assertion is just a URL (eg http://booktype-test.sourcefabric.org/_badge/badge/sharer/awards/8.json). You can paste any assertion URL into your browser and you should see a response like the following
{"issued_on": "2012-04-07", "badge": {"issuer": {"origin": "http://booktype-test.sourcefabric.org/accounts/AdamHyde", "contact": "adam@flossmanuals.net", "name": "AdamHyde"}, "criteria": "http://booktype-test.sourcefabric.org/_badge/badge/sharer", "version": "0.5.0", "name": "Sharer", "description": "Sharer badge description yoyo"}, "recipient": "adam@booki.cc", "evidence": "http://booktype-test.sourcefabric.org/_badge/badge/sharer/awards/8"} This information is verification that the learner (recipient) with the email address 'adam@booki.cc' has earned the badge 'Sharer'.
The reason that this statement is not made in 'human readable' form is because the information is really for other web services (like the Backpack) to retrieve and analyse. However if you enter the 'evidence' URL into a browser (in this case http://booktype-test.sourcefabric.org/_badge/badge/sharer/awards/8) then you should see a webpage formatted in a nice way for humans.
The real core of this entire system is the assertion information that you see displayed above. This is the information that an employer or webservice can use to verify that the badge was infact awarded to the learner.
As mentioned before there is conflicting advice in the Open Badge documentation about the 'baking' strategy. Baking is the process of embedding the assertion into the badge. All image files allow for information to be embedded in them - this is used commonly by digital cameras to store date information etc in the image file. Baking the assertion into a badge is technically easy - but that is actually a problem. It is easy to bake (embed) any assertion into any badge. It is also possible to delete these assertions or change them.
There is some suggestion in the documentation that a better security process is going to be development ("Signed Assertion is on the development roadmap."1 ). However although it is suggested this is in the roadmap it is not2 . This appears to be a simple oversight and I am sure the more secure assertion development will be done, the exclusion in the roadmap is just a sign that this project, while usable in its current state, is very embryonic.
Regardless, the problem of the insecurity of baked assertions highlights that the real value of this system is actually the assertion URL and its use within trusted networks of Issuers, Backpack services, and displayers. The assertion is the currency used between all these parties and it is in essence far more important than the badges (image files) themselves. The badge images are really candy although important since a project which promoted assertion URLs as a method for gaining credentials is probably not going to appear very appealing to learners.
What this also means is that the value of the credential (badge/assertion) is completely reliant on the integrity of all three parties - Issuer, Backpack service, and Displayer. Additionally the further away from the issuer you get the more the trust degrades. Displayers being the weakest link.
There has been error in communication with Booktype server. Not sure right now where is the problem.
You should refresh this page.