Assertion:

Along with being on of three required .json objects that define a badge this is the one that is created for every badge you issue since it is specifically pointed at the recipient. While there is a lot of metadata included in this object most of it won't need to be changed for each new badge awarded. The metadata in the Assertion object is what is specifically added to the data stream of the badge image. This process is called baking the badge. A useful mental model is the date, time, and GPS location that is 'baked' into the image file of most pictures we take with digital devices.

Because the Assertion object is unique to each badge awarded one can imagine that eventually this could become a bit of a data management problem. In addition badges present the opportunity to provide specific evidence for the skills being validated for each recipient of the badge. Again, this seems likely to add to data management concerns. Maintaining the assertion object for each badge, for hosted badges, is what ultimately validates the badge when it is shared the badge holder wishing to demonstrate their skills. If the digital chain validating the badge is broken then there is just a pretty picture with nothing to back it up. None of these challenges are unique to badges but they are worth remembering as we enter into using this technology.

Dissecting an Assertion Object:

I would certainly recommend opening the link above to see the formal statement to go with any discussion here. Discussion of the creation of .json files generally is linked here.

"@context":

Like all tools, software or otherwise, there are shared standards for what is expected. In the ecosystem of badge objects the standard that you are using at time that you issue a badge needs to be specified and this is the statement that specifically articulates that. Currently the various generations of badges are forward and backward compatible when using the Open Badge spec but there are outstanding questions about badges and badge objects that are created in the many different badge issuing platforms. This compatibility question is referred to as the 'interoperability question".

"id":

This is the url where the json file (shown above) will be hosted. When you award a badge this url is embedded in the badge telling any viewer of the badge where to look to verify that this badge is indeed superficially valid. If this .json file is moved or deleted the specific recipient of the awarded badge you have issued will be deemed to hold an invalid badge. This is another form of zombie badge.

"type":

This string indentifies which of the required badge objects this .json file represents. This is an example of a Assertion object. The other object types are Issuer and BadgeClass objects.

"uid":

This is a specific identifier of the badge being awarded. In some sense this is much like a serial number. Every badge that is awarded of a specific type (BadgeClass) needs to have a unique identifier. It does not need to be unique in the world because it will only be compared against other badges defined by your BadgeClass object. No need to get fancy or cryptographic here. If someone who is not the person you awarded the badge to seeks to present the this uid is the identifier you will use to revoke the badge.

"recipient":

This is how the recipient of the badge will be identified. I have not personally explored the full range of possibilities here. For now the following strings are required to appropriately identify the recipient.

• "type": - for now I've only seen "email" used as the type of identified
• "hashed": true or false (no quotes) - I have not played with hashed (encrypted) identities, I'm a trusting soul
• "salt": only relevant if you've hashed the identity -- this is an additional security measure prior to hashing
• "identity": the actual email address of the recipient which is what is typically encrypted for those concerned

"badge":

This links the badge directly to the BadgeClass object. As discussed this includes general information about the skills asserted by the badge as well and assessment or evaluation strategies that are common to all holders of this badge. When the metadata for the assertion is validated that process also checks to be sure that the data in the BadgeClass object is legit. Within the BadgeClass object is the identification of the Issuer object which is also checked during the validation process.

"verify":

Describes how the badge can be verified.

• "type": "hosted" or "signed"

Hosted badges require the issuer to maintain a website that 'hosts' the individual assertion objects. A signed badge contains on the information from the assertion object in an encrypted signature that is described in technical specification. While it would seem to make the badge more portable and reduce the data management challenge for the issuer be aware that the issuer still needs to host the BadgeClass, Issuer, images, and criteria files. I haven't found a compelling need for signed badges just yet.

• "url":

For a hosted badge this is just location of the assertion object that is shown above. For a signed badge a link to the public key that permits the encrypted signature to be decrypted and validated.

"issuedOn":

Gives the date the badge was issued in ISO 8601 format. I had no idea this specification existed.

"image": (not required)

This is a link to the baked image of the badge. The baked image (as distinct from the BadgeClass image which looks the same) is the result of 'baking' the Assertion object into the BadgeClass image.

"evidence": (not required)

This url points to a web page where evidence specific to the recipient of the badge is held. This is, in effect, a personal portfolio for the recipient of the badge. Along with it's value it raises significant data management challenges as one considers keeping portfolios for every recipient of every badge through their life. That's a lot of data. On the flip side there is a clear expectation in Europe that every learner will have a life long digital portfolio of their skills development and experiences in the not to distant future so somebody is going to have to figure out this data question. For the terminally curious you might delve into the discussions on the Badge Chain blog.

"expires": (not required)

An interesting feature of badges is that they can have an explicitly stated lifetime. I have used this liberally in my various badge tests so that any monsters that I create will be seen to expire in fairly short order.