-
Notifications
You must be signed in to change notification settings - Fork 263
FAQ
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;
A: Yes, subdomains and ports are suported by the Open Badges Infrastructure.
A: Soon! https://groups.google.com/d/topic/openbadges/o79yJIKDLps/discussi
A: Hash the email combined with a salt value using SHA256, SHA512 or MD5 encryption;
A: Badges only contain a hashed + salted representation of a user's email, so they will be fairly useless to spammers. Also, public badges are only discoverable if you already know the user's email.
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.
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.
- 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.
A: there are a couple of locations you can read more about assertions;
- https://github.com/mozilla/openbadges/wiki/Assertions
- https://wiki.mozilla.org/Badges/Onboarding-Issuer
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.