Issuer:

This is one of three required .json objects that define a badge. The Issuer is the JSON object which describes the issuer or the issuing organization. In the open education model of the open badge ecosystem any entity is free to issue badges. While most of the early implementations of badge systems revolve around organizational issuers the potential exists for a broader and more democratic universe of validators of learning experiences. Depending on where you live the educational world you may see this opportunity as ridiculous or completely awesome. It certainly is a fascinating topic for discussion that has drawn in a tremendous range of educational thinkers. Should you ever be struck with the desire to dive down the rabbit hole I can recommend the blogs listed on my main badge page. I am not responsible for the rabbit hole you will find yourself in if you go this way!

In some sense the issuer object is a tool to be open and transparent about the issuer of a given badge class. It may also be used to provide some level of credibility for the skills asserted by the badge along with some sense of the educational lineage of the issuer. Tim F Cook and others have written thoughtfully about the need to develop an endorsement model for badges since they are fundamentally a social trust network. Serge Revet writes extensively about models of trust networks and their relationship to the badges ecosystem. For a while these issues are certain to continue to evolve in interesting ways. Here is the current state of things.

Dissecting an Issuer 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 issue a badge it, the badge, will also contain this information which will provide any viewer of the badge with relevant information about the issuer of this badge. If this .json file is moved or deleted any badges you have issued will have no clear link to an issuer with some level of credibility. 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 Issuer object. The other object types are Assertion and BadgeClass objects.

"name":

This string identifies the issuer of the badge. A given issuer may issue many different badges (badge classes). This .json object may be referenced by a large number of badge classes. There exists no convention that I am aware of for how verbose this name might be.

"url":

This string provides a link to a web object that allows the issuer to describe themselves at any level of detail. This could be the welcome page for your organization or a page designed to establish your individual credibility to issue various badges and badge classes. This is where a badge viewer will land if they want to know more about who issued a badge.

"description": (not required)

This string provides a compact description of the issuer which is presumably less extensive than what can be found at the url. This information is available directly when the badge is 'unbaked'.

"image": (not required)

Most organizations are likely to have a logo which they have worked to attach to their 'brand'. This image link is an opportunity to further that branding model for the issuer.

"email": (not required)

As it would appear this is a contact email for the issuer of the badge. While this could easily be a very general contact point for the institution in the ecosystem of open badges it is ideally the email for the individual who is able to respond to specific questions about the skills being asserted by the badge and the specifics of any holder of such a badge within the privacy rules and expectations that apply.

"revocationList": (not required)

An interesting feature of the open badge specification is the ability to revoke badges. The metadata in a badge is baked into it and travels with the badge. Once issued this metadata can't be modified by the issuer unlike the current databases that underwrite traditional student transcripts. The ability to revoke a badge for articulated reasons seems valuable. The revocation list is itself a .json file which must be maintained. It has made sense to me to keep my revocation list in the same location as the Assertion files which must be created individually for each badge awarded.