Issuer API is turning 1.0-compliant badges into 0.5 badges

[ottonomy]

Hi, backpack team. I created this assertion and hosted it, built a page to use the Issuer API over JavaScript to bake this badge and put it in my backpack. Here's the hosted assertion:

{
    "uid": "ottonomy-the-swindler-1",
    "recipient": {
        "type": "email",
        "hashed": true,
        "salt": "coarsekosher",
        "identity": "sha256$ff80caeeea3342f16692d99dfe4c0d4c426be3c69d86948c3e91aa5ca52f6208"
    },
    "issuedOn": "2014-01-03T21:42:21.092Z",
    "badge": "http://ottonomy.net/manualbadges/badgeclass-badge-swindler.json",
    "verify": {
        "type": "hosted",
        "url": "http://gator3046.hostgator.com/~ottonomy/manualbadges/assertions/swindler/ottonomy-the-swindler-1.json"
    }
}

Then I downloaded the badge from my backpack collection. The assertion baked into the badge by the Issuer API is this:

{
    "uid": "ottonomy-the-swindler-1",
    "recipient": "sha256$ff80caeeea3342f16692d99dfe4c0d4c426be3c69d86948c3e91aa5ca52f6208",
    "issuedOn": "2014-01-03T21:42:21.092Z",
    "badge": {
        "name": "Master Badge Swindler",
        "description": "This user has created their own properly formed Open Badge by hand, except that reputable upstanding organization ottonomy.net surely wouldn't ever issue such a badge. If you're seeing this badge in someone's backpack, it means they're a master badge swindler. Can you figure out how they did it?",
        "image": "http://ottonomy.net/manualbadges/badge-swindler.png",
        "criteria": "http://ottonomy.net/manualbadges/swindler-badge-criteria.html",
        "issuer": {
            "name": "Nate Otto",
            "url": "http://ottonomy.net",
            "description": "Personal website of Nate Otto",
            "email": "[email protected]",
            "_location": "http://ottonomy.net/manualbadges/issuer.json",
            "origin": "http://ottonomy.net"
        },
        "_location": "http://ottonomy.net/manualbadges/badgeclass-badge-swindler.json"
    },
    "verify": {
        "type": "hosted",
        "url": "http://gator3046.hostgator.com/~ottonomy/manualbadges/assertions/swindler/ottonomy-the-swindler-1.json"
    },
    "_originalRecipient": {
        "type": "email",
        "hashed": true,
        "salt": "coarsekosher",
        "identity": "sha256$ff80caeeea3342f16692d99dfe4c0d4c426be3c69d86948c3e91aa5ca52f6208"
    },
    "salt": "coarsekosher",
    "issued_on": "2014-01-03T21:42:21.092Z"
}

Excepting for a validation error because I used a full timestamp instead of just YYYY-MM-DD this badge passes the Validator, but says that it's passing on the 0.5 spec path, not the 1.0 spec path, as I had originally asserted the badge. You can see some differences: for example, look at the recipient field of the assertion. It has been flattened to 0.5 style.

I find this kind of strange. Had an unrelated error with a baked badge that led me down this path of exploration.

CC: @brianloveswords, @cmcavoy @threeqube

[erickorb]

We are finding that the import of a 1.0 badge is having data added to it. See _location. Not sure why. Once this data is added, the validation JSON is not the same. So, the badge won't validate.

[ottonomy]

For further reference, this issue is only occurring for badges that use the Issuer API to award a badge to a user's Backpack account by passing in the assertion. If a baked badge is passed in via the Issuer API, or if one is uploaded manually by the user, the baked information isn't changed.

IssuerAddBadgeFromAssertion is calling the normalizeAssertion utility after validating the original assertion. It looks like the bulk of this part of the procedure was developed before the Backpack began hosting saveable baked images (an essential feature) or even before the 1.0 release of the standard.

When baking the awarded badges was added onto the awarding procedure, it was implemented as an add-on to the end of this process, using the "normalized" assertion, and further ensuring a verify.url was added even though that wasn't part of the 0.5 standard.

As much sense as the provenance of this feature makes, I don't think the resulting baked badges are compliant with the OBI standard, as it exists. The standard implementation instructions tell us that badge must be a URL. (for the moment ruling out the inlined badge and issuer objects). There aren't any instructions to let implementers know how to deal with cases like this when the hosted and baked assertions differ. It seems, as @erickorb says, that strict validators would be justified in rejecting badges whose baked assertions differ from the hosted copies.

It seems much more appropriate to bake the original assertion into the badge, provided that it has passed validation and Backpack wishes to move forward with awarding the badge to a user's account. Even as old as this issue is, I think this is a pretty high-importance fix. I'd be willing to contribute a little code myself, but I have not done any development on the Backpack yet, and I don't know its testing infrastructure.

[stenington]

Still trying to catch up here a bit, but I agree that baked badges should reflect the assertion as it comes in without any internal mucking about the backpack might do otherwise. The backpack is a bit sloppy right now about intermingling internal representations with passed in data, and I believe that's the origin of any fields with a leading underscore you might be seeing, like _location.

Undoing that is a bit trickier. I feel that the right way to do it is with an abstraction on top of badge versions within the code so that the code doesn't have to care (as much) about spec versions, and handling for future spec versions can be added by building subclasses instead of adding else if () cases. Maybe I can make a start on writing such a module with some tests, we can build it out together, and then try to swap it in to the backpack code so badges are handled more appropriately.

[stenington]

Oh, well I'm also seeing a more direct fix we could try. I think part of the wackiness here is that we used to bake URLs into the image, but now even if we get passed a url, we want to fetch that and then bake the data. The code just wasn't structured to let us do that before normalizing, but I think there might be a quicker fix to pass along the fetched data to where it can be baked. I'll see if I can get something together for testing.

[stenington]

Proposed solution in #1032. Would be good to get it up somewhere and throw a bunch of different assertions at it to make sure everyone's expectations are properly met.

[kayaelle]

We can do some testing from Achievery when you're ready.

On Aug 7, 2014, at 11:48 AM, Mike Larsson [email protected] wrote:

Proposed solution in #1032. Would be good to get it up somewhere and throw a bunch of different assertions at it to make sure everyone's expectations are properly met.

—
Reply to this email directly or view it on GitHub.

[ottonomy]

Thanks, @stenington (and @kayaelle for offer of testing). The code looks good to the eye. Are you going to spin this up on a staging server somewhere that we could point at, or did you need somebody else to give that a try. I could potentially check it out ~around Saturday.

[erickorb]

I'd like to test as well, if you can tell where to do this.

Eric

_"Trust only credentials that are TrueCred_™ verified."

Eric Korb, President/CEO - accreditrust.com
GoogleVoice: 908-248-4252
http://www.linkedin.com/in/erickorb @erickorb @accreditrust

On Thu, Aug 7, 2014 at 1:59 PM, Nate Otto [email protected] wrote:

Thanks, @stenington https://github.com/stenington (and @kayaelle
https://github.com/kayaelle for offer of testing). The code looks good
to the eye. Are you going to spin this up on a staging server somewhere
that we could point at, or did you need somebody else to give that a try. I
could potentially check it out ~around Saturday.

—
Reply to this email directly or view it on GitHub
#1029 (comment).

[stenington]

Try it against http://stenington.org:8888 and see how it works. If that url isn't up, let me know.

[ottonomy]

Works perfectly for me; your code correctly baked the input assertion without modification, which is the safest route I think. I think we might need to make a breaking change at 2.0 to the standard before we can implement modifiable-after-the-fact baked assertions, though I think there are some great possibilities there to investigate.

{
    "uid": "ottonomy-the-swindler-1",
    "recipient": {
        "type": "email",
        "hashed": true,
        "salt": "coarsekosher",
        "identity": "sha256$ff80caeeea3342f16692d99dfe4c0d4c426be3c69d86948c3e91aa5ca52f6208"
    },
    "issuedOn": "2014-01-03T21:42:21.092Z",
    "badge": "http://ottonomy.net/manualbadges/badgeclass-badge-swindler.json",
    "verify": {
        "type": "hosted",
        "url": "http://gator3046.hostgator.com/~ottonomy/manualbadges/assertions/swindler/ottonomy-the-swindler-1.json"
    }
}

That indeed exactly deepEquals my hosted JSON at http://gator3046.hostgator.com/~ottonomy/manualbadges/assertions/swindler/ottonomy-the-swindler-1.json

This was a weird badge for me to use to test on, but it was closest at hand when I created the issue.

👍 Thanks. If @erickorb and @kayaelle can do a little higher-volume testing, that would be great.

[ottonomy]

Did this ever get pulled into the real working backpack?

What should be done about all the baked images that are in the backpack that are not 1.0 compliant despite being baked from 1.0 compliant assertions? I'm building a JSON-schema based validator, and I will probably just make a schema for this legacy format.

Then we can move forward talking about how we should actually embed badgeclass and issuer information into baked assertions (and whether that should be done as hosted as well).

[ottonomy]

Ping @cmcavoy @stenington -- Just tested again -- it looks like http://backpack.openbadges.org is still baking non-compliant badges. Who can fix this?

[smartcodingxx]

Hi ottonomy,
I don't know I have to ask the question here or somewhere else. Sorry in advance. but its related to baking badges.

Do assertion data .json file and verify .json file will have same data ?

here is the detail

• assertion json file
  { "uid" : "85ca1973771769c4b3eef0156b607b58f0651bee", "recipient" : { "identity" : "sha256$094ac2d2c5195904dfdb2511e6d9937b7a871e8b2d339215bc14cb346f43732a", "type" : "email", "hashed" : true }, "badge" : "http://localhost:8888/content/badge.json", "verify" : { "url" : "http://localhost:8888/content/verify.json", "type" : "hosted" }, "issuedOn" : 1466060644 }

• badge json file
  { "name" : "Mozilla Badge", "description" : "description here", "image" : "http://localhost:8888/content/demo-badge.png", "criteria" : "http://localhost:8888/backpack/login", "alignment" : [], "issuer" : "http://localhost:8888/content/issuer.json" }

• issuer json file
  {"name":"My Own Badge System","url":"http://localhost:8081"}

• verify

  json file (Following above commented json data - commented on Aug 8, 2014)
  { "uid" : "85ca1973771769c4b3eef0156b607b58f0651bee", "recipient" : { "identity" : "sha256$094ac2d2c5195904dfdb2511e6d9937b7a871e8b2d339215bc14cb346f43732a", "type" : "email", "hashed" : true }, "badge" : "http://localhost:8888/content/badge.json", "verify" : { "url" : "http://localhost:8888/content/verify.json", "type" : "hosted" }, "issuedOn" : 1466060644 }

By passing assertion to bakerAPI I getting following error

_"name" : "openbadges-backpack",
"hostname" : "MY-MACHINE",
"pid" : 5616,
"level" : 60,
"err"
: {
"message" : "Method Uint8Array.length called on incompatible receiver [object Ob
ject]",
"name" : "TypeError",
"stack" : "TypeError: Method Uint8Array.length called on
incompatible receiver [object Object]\n at BitWriter.get length (native)\n
at BitWriter.makeArrayLike [as _makeArrayLike] (D:_

then I follow the Assertion Information for the Uninitiated link.

As per link the verify object should have only type and URL.
So I change the verify json to as follows...
{ "type": "hosted", "url":"http://localhost:8081/public/assertions/85ca1973771769c4b3eef0156b607b58f0651bee" }
and I am getting following error which indicates that assertion and verify data should match.

{ "message" : "Remote assertion must match local assertion", "stack" : "Error: Remote assertion must match local assertion\n at makeError (D:\\Dharmendra\\11_Published\\badgeBaker\\node_modules\\openbadges-validator\\index.js:495:15)\n at validateHosted (D:\\Dharmendra\\11_Published\\badgeBaker\\node_modules\\openbadges-validator\\index.js:436:25)\n at fn (D:\\Dharmendra\\11_Published\\badgeBaker\\node_modules\\async\\lib\\async.js:582:34)\n at Immediate._onImmediate (D:\\Dharmendra\\11_Published\\badgeBaker\\node_modules\\async\\lib\\async.js:498:34)\n at processImmediate [as _immediateCallback] (timers.js:383:17)", "code" : "verify-hosted", "extra" : { "local" : { "uid" : "85ca1973771769c4b3eef0156b607b58f0651bee", "recipient" : { "identity" : "sha256$094ac2d2c5195904dfdb2511e6d9937b7a871e8b2d339215bc14cb346f43732a", "type" : "email", "hashed" : true }, "badge" : "http://localhost:8888/content/badge.json", "verify" : { "url" : "http://localhost:8888/content/verify.json", "type" : "hosted" }, "issuedOn" : 1466060644 }, "hosted" : { "type" : "hosted", "url" : "http://localhost:8081/public/assertions/85ca1973771769c4b3eef0156b607b58f0651bee" } } }
For your information I have hosted two node js api's

1. http://localhost:8081 - BadgeKit API where I am creating and awarding badges.
2. http://localhost:8888 - openbadges-backpack where I am using baker API to bake images.

OS: Windows 7 pro 64bit

Any hint or suggestion regarding this?
Thank you in advance,
Dharmendra mistry

[smartcodingxx]

I am able to solve baking issue by using compatible node js version.

The app (openbadges-backpack) is using engine 0.10.30 while I am using latest 4.4.5. So I need to downgrade node js version and it works like charm.

Also I found that assertion json file data and verify json file data must be same in case of hosted type.

Hope this help someone.

Thanks

[mattdigitalme]

@auralon @ottonomy This would be one to check with the update and Issuer API - if not, we should definitely look into this

[auralon]

There is certainly further development required in order to support newer badge specs properly.