Skip to content
This repository has been archived by the owner on Aug 22, 2019. It is now read-only.

FAQ

Jump to bottom
prawsthorne edited this page Sep 13, 2012 · 29 revisions

Should the same salt be used for the same earner in successive badge requests or is it on a request basis and it does not matter?

A:The salt value for successive requests for the same specific badge should remain the same, if the earner has earned different badges the salt value should be different or each badge.

Why do I get the error, "{"message":"Unexpected content-type: Response is text/plain, but expectedapplication/json`","name":"ContentTypeError"}"?

A: You need to set the correct content-type. this is well described on the assertions page of the github wiki;

Can we use subdomains and ports within the json message / file?

A: Yes, subdomains and ports are suported by the Open Badges Infrastructure.

Does the OBI support SSL?

A: Soon! https://groups.google.com/d/topic/openbadges/o79yJIKDLps/discussi

How do I not have the earners email as plain text in the json message / file?

A: Hash the email combined with a salt value using SHA256, SHA512 or MD5 encryption;

How do I test whether a user has a specific badge in their backpack?

A: The only way to do this currently is to log the user in through the http://beta.openbadges.org/issuer.js workflow (some documentation here https://github.com/mozilla/openbadges/wiki/Issuer-API), and then issuing a GET with the url of the assertion as the parameter 'url' to http://beta.openbadges.org/issuer/assertion.

You'll get a JSON response that includes an "exists" boolean. If the badge is already in their backpack, it will return True, False otherwise.

Do I need to pre-bake a badge before I submit it via the Issuer API?

A: No, baking (the process of adding badge meta-data to the PNG image) happens as a part of the Issuer API. However, if a badge is meant to be portable, and added to the backpack through the upload interface, then the badge needs to have assertion meta data baked in.

Who is responsible to issue the verification call for a badge? The Displayer?

  • on each viewing? if so, what about server load issues?
  • or only when first displayed? what then about badge revocations?

A: The backpack handles verification. It's also possible/recommended that the displayer independently verify. They shouldn't be verifying on each view, but there should be some TTL on the verification. We don't have an official recommendation for the length of time a badge should live before being reverified, but it probably shouldn't be longer than a week.

When Issuer revokes a badge, does it need to notify OBI, or displayer, or just wait for verification & deny?

A: Revoking badges is still being worked out, but the model we are working towards is verification & deny.

How does signed assertion work?

A: there are a couple of locations you can read more about assertions;

Signed assertions will be available in the second half of 2012. Once implemented the issuer will only need to host the public key at a stable URL, therefore all badges (of the same type) issued can be verified against this one public key. Signing key URL will be from your domain, similar to how we verify hosted assertions.

Introduction

Issuing

Displaying

Tips and Resources

Clone this wiki locally