From my testing it looks like the open badges specification doesn’t align with the V2 assertion because the badge ID is always set to urn:uuid:example. The open badge validator always rejects my assertions because it doesn’t recognize the badge id as a valid IRI?
Could you share your issuer profile?
https://openbadgespec.org/extensions/applyLinkExtension/context.json
I’m pretty sure the issuer is valid because my credentials have been verifying via the Blockcerts verifier.
Edit: Just noticed that the email on my hosted issuer profile is different than the one inside my BadgeClass, could that be causing the issue?
Getting closer, There are 4 native extensions used to create the certs which are recipientProfile, signature, signatureLines and verification. When I use an open source Open Badges validator they all return errors. I think they all need a @context included as well? Here is what the validator outputs, also it doesn’t seem to like the publicKey attribute of the issuer profile, specifically because the ecdsa-koblitz-pubkey isn’t a valid IRI.
"messages": [
{
"name": "VALIDATE_EXTENSION_NODE",
"messageLevel": "ERROR",
"result": "Could not determine extension type to test",
"success": false
}
Edit: Ok I’m starting to understand this a bit better. I see that the blockcerts context that is linked into credentials includes the obi validation for the native extensions. If I included additional global values and per recipient values then do I need to build obi validation via extensions?
More progress, any help is appreciated!
I have forked the openbadges validator to get down to the bottom if this issue.
one of the node_types that is being parsed through the blockcerts v2 context is “https://w3.org/blockcerts#RecipientProfile”
If I hardcode it to be RecipientProfile instead, I don’t receive any obi:extension errors. Due to this error the openbadges validator cannot determine what type to test for each of the Blockcerts extensions.
Thanks
It would be easy to debug if you could share the json certificate file and issuer. Also testnet public key is safe to share anyway.
Can’t upload JSON files to this forum but here’s the credential json as an image. The issuer json remains unchanged from the previous image.
Changed a couple domains to protect our dev servers.
can’t see much details on this picture. Make sure you hosted issuer json and revocation list with a valid URL and not from the example of blockcerts.
Ok. Any advice on linking my own contexts. Everytime I try to issue a credential with a linked context I get a cors error. The source of the context has cors enabled and access-control-allow-origin: * set.
You can verify the headers if CORS is enabled including Methods.
Chrome → inspect element → network → Response Headers
It should be like this
access-control-allow-methods: GET
access-control-allow-origin: *
Been trying to solve this and I made my way back to the cert-schema IMS Consortium repo that contains some blockcerts openbadges examples. From the v2 open badge compliant blockcerts examples provided by Kim Hamilton, I am still getting the same node extension errors. Does the blockcerts context need to be changed to properly validate credentials as an open badge?
Can anyone provide an example of a Blockcerts credential that is a valid v2 open badge.